Date Changing Routine Broken
When using the source linker, the "date correction" routine which previously changed numerical dates to the format where the month was a word seems to be broken.
It now changes a date presented as Number Word Number into Number Number Number and then spawns a "Non-Standarsized Date" Error.
The example I chose had the date presented as 4 January 1908 which is clear and cannot be misconstrued.
When I selected the event to be attached, Source linker then changed this to 4 1 1908 and threw the warning.
Why ?
The original date was fine. The altered date was unnecessary and led to possible confusion between date forms where the month and year are interchanged.
The whole idea of making alterations to data that is already indexed is questionable to say the least, but to make changes that then create errors and warnings is a clear indication that the tool is not helping to progress towards improving data quality and reducing workload.
Comments
-
I made a post about this and about the general assumptions made about numeric dates getting changed from dd mm yyyy to mm dd yyyy (as it is in the rest of the world). I cannot find that post anymore. Thanks for posting this. I often need to fix the dates being suggested as unrecognizable.
0 -
This was reported to the engineers for review. It would be helpful to have the URL or the Person ID of the error.
0 -
@ScottSeegmiller Any source where the day of the date is lower than 12 will cause it to happen. The date changer flips the word of the month to a numerical value, and then having altered it can't work out what the correct format is for the result, i.e. whether it's DDMMYYYY or MMDDYYYY so it can't work out which bit to change back to a month. If the routine did a simple precursory check to validate the original information, it could simply leave the date alone.
Note: For the error to occur the source being attached must be one that is not a duplicate of one that is already attached with the same date.
0 -
-
I see it, thank you for submitting the url.
0 -
@ScottSeegmiller Can you please report to the engineers who are working on this issue that the search results from a general search have now started producing corrupted results where the date has the month and day swapped.
Example: A burial that took place on 8 December 1869, is shown in search results as 12 August 1869
Also, a burial that took place on 5 December 1868 is shown as 12 May 1868
Example Search Parameters: William Atkinson, birth 1810 to 1812, death Lancashire, England, 1868 to 1869.
F.Y.I: Because these dates can't be attached using source linker, I now have to enter the data into the person record manually, but it is worth noting that when I paste the date, it is accepted immediately as a standarized date without any issue.
0 -
Continuing the same theme: A record entry being linked in the source Linker appears as "Different" when the dates and places are identical. Maybe due to the date standarisation routine doing a background comparison and messing up the date.
Example:
0 -
Huh. I wonder if my 1827-versus-November 1827 example is the other extreme of the same problem?
0 -
@Re Searching The two burial places are not completely identical, even though what is shown in the source linker is identical. When you look at this person's profile, you see that the display value for the burial place is "Mottram in Longdendale, Cheshire" (no country listed) with a standardized value of "Mottram in Longdendale, Cheshire, England, United Kingdom". The display value is shown on the profile page, but the standardized value is shown in the source linker. It's odd that those two features made different choices as to how to show a place. And of course it is confusing for the two burial places to be identified as different when what you are shown is identical.
1
