In Ebbel Pieters G6RK-PGD a zero on the wrong place
In the header of https://www.familysearch.org/nl/tree/person/details/G6RK-PGD as birth year 0171 is stated, instead of 1710.
Later a birth year of 1718 is mentioned. Maybe 1710 is meant as approximation, but 0171 is obviously an error.
Best Answer
Answers
-
You can just change that entry. I've done that for you.
1 -
Maybe the resource was locked at the moment I tried to correct it.
0 -
@Wim Zuur In the FamilySearch tree, each date is stored in two formats:
- The date as the user entered it, and
- A standardised date that the system usually correctly derives from the user-entered text. This is formatted in a standard way so, for example, there isn't ambiguity when the user enters something like 7/4/1776 (which might mean 4 July 1776 to a Canadian or an American, or 7 April 1776 to most of the rest of the world). This standardized date is what the system uses when it needs to use it for a calculation or sanity check (e.g. born before died). When a user enters a date, they get to see what the system is proposing to enter as the standardised date (e.g. they can select whether they mean the April or July date). "A calculation" would include figuring out the year so that just the year can be displayed (for example in the header of the profile page as you have observed).
That said, there are apparently some ways that a user can enter a four-digit year without a day or month, and the system chooses a standardised date which is the first two or three digits of what was entered, left-filled with zeros. For example, a user might enter 1905 as a marriage date, and the system might choose a standardised date of 0190 or 0019. Over the last year, I have seen this maybe several hundred times, mostly from a couple of users. I have picked these up from the error message like "Married before born" which would have been visible to the users at the time, but ignored.
In the change log for Ebbel Pieters shows three entries for his birth date. They all show a (user-entered) date of 1718. The first was back in 2022, and the other two are from today. I assume that the original date entry was made in the same way, with the standardised date somehow being set 0171. That should have resulted in an Data Problem error message being visible to you. As @Karin van Ravenzwaaij-Pluijlaar has said, you can fix these cases by editing the date so that the standardised date is set correctly.
3 -
RE:
That said, there are apparently some ways that a user can enter a four-digit year without a day or month, and the system chooses a standardised date which is the first two or three digits of what was entered, left-filled with zeros. For example, a user might enter 1905 as a marriage date, and the system might choose a standardised date of 0190 or 0019. Over the last year, I have seen this maybe several hundred times, mostly from a couple of users.
Unfortunately the Change Log does not display the standard version of date or place data to confirm the above, but that is certain to be what happened. I have not seen this personally for quite a while, but years ago the standardization system had a bit of a lag to it and if you were a really fast typist, could enter "1718 return" quickly enough for the data to be saved while the standardization dropdown was still at "171."
It seems late for this to have happened in 2022. Since it is only being seen with a few users, maybe those users have really old, slow computers or very unstable internet connections that make the communication between the data servers and their computers difficult.
5