Why are thousands of Danish 1921 Census dates of birth indexed wrongly?

LY4

No one who appears in the 1921 Denmark Census can possibly be born AFTER the census was recorded but page after page has dates of birth indexed as being a century later. Either AI is not intelligent and cannot figure this out when indexing, or a human being is intellectually challenged and hasn't realised that all years mentioned as higher than the number 21, must be born in the 1800s. Can someone in iT please address this issue as it affects so many records and would be impossible to manually plough through them all correcting them.

Maile L

Can you please provide a link to an example? Thanks

LY4

There are 314456 records for the Danish 1921 Census which have a recorded date of birth between the years 1922 and 1999. Just do a search , no names needed, just select country Denmark years 1921-1921, with birth year 1922-1999 in the search boxes and you'll get a the huge list of them. The reason is that the Danish census records the year of birth as just 2 numbers. ie 19 could be 1819 or 1919, which is one issue, but where the year is 21 or a higher number, the default seems to be recording them automatically at 1928 or 1972 instead of 1828 or 1872, or whatever year it may be, but a century later than it should be.

LY4

https://www.familysearch.org/ark:/61903/3:1:3Q9M-CSLM-Q9DF-W?i=225&cc=2721601 gives you a sample page of the hundreds of thousands of them. Infact on that page you have someone indexed as born 2019, when they may have been born 1919 or even 1819 ! But definitely will NOT have been born in 2019.

LY4

Another issue is several are indexed with the year 0025 for example, as the year of birth.

But you can pick any number between zero and 99, and find years of birth indexed as 0001 of 0034 or whatever year it may actually be.

This has to be an Ai Issue. Digitally scanning the 2 digit "year of birth" box on the census form, and assigning the wrong century to the reading, and in many cases defaulting to the century 00.

TheoDarwin

I'm not the OP, but I just ran a query with Collection = "Denmark Census, 1921", birth year from 1922 to 2023, and first name Jan, and came back with 36,000+ results. That query is here:

https://www.familysearch.org/search/record/results?f.collectionId=2721601&q.birthLikeDate.from=1922&q.birthLikeDate.to=2023&q.givenName=Jan

A specific record is Jan Pasternak https://www.familysearch.org/ark:/61903/1:1:QLGJ-DHQN and several other people on this page: https://www.familysearch.org/ark:/61903/3:1:3Q9M-CSLM-Q6VV

LY4

TheoDarwin - It''s quite a major issue isn't it ? When an entire nation's census is affected. I just hope someone among the LDS boffins can raise this issue with the people that are in charge of it , and get it looked at and hopefully remedied in the weeks to come.

Paul W

This is not a new, or unusual problem - except inasmuch as this specific instance affects every record in the collection.

I have raised a question at https://community.familysearch.org/en/discussion/153517/could-familysearch-do-anything-to-prevent-incorrectly-formatted-dates-appearing-in-indexed-records/p1?new=1, because it seems strange to me that programmers can't create a piece of coding that would expose any such errors appearing in a collection, before researchers are forced to face this problem when the records are put online.

LY4

E.g. Is the date string four numbers starting 00 ? If yes then replace the first 00 with 19.

Is the date string now 1922 or greater? If yes , then replace the first two digits 19 with 18

Is the date string starting with 20? if yes replace the first two digits 20 with 19

Is the date string just two digits? if yes AND the number is less than or equal to 21 then add 1900 to the number. if yes AND the date string is greater than or equal to 22 the add 1800 to the number.

Or something to that effect. This won't solve the issue for centenarians, but there will be very few of them compared to the hundreds of thousands of others. It is certainly codable, with a few more safety nets built in, depending on the year of the census. And perhaps have a dump queue to send all entries which do not match these scenarios , so they can be individually checked out by a human set of eyes.

Maile L

Thanks for letting us know, I have asked for this issue to be reviewed. I will let you know when I hear something.