If you use the TO_DATE function with the YY datetime format element, then the year returned always has the same first 2 digits as the current year. If you use the RR datetime format element instead, then the century of the return value varies according to the specified two-digit year and the last two digits of the current year.
That is:
If the specified two-digit year is 00 to 49, then:
* If the last two digits of the current year are 00 to 49, then the returned year has the same first two digits as the current year.
* If the last two digits of the current year are 50 to 99, then the first 2 digits of the returned year are 1 greater than the first 2 digits of the current year.
If the specified two-digit year is 50 to 99, then:
* If the last two digits of the current year are 00 to 49, then the first 2 digits of the returned year are 1 less than the first 2 digits of the current year.
* If the last two digits of the current year are 50 to 99, then the returned year has the same first two digits as the current year.
Is the switch date for RR fixed? Seems like there will be some weird breakage around 2050 as random places that have been skating by on using RR for old 2 digit years will be in trouble.
An almost poetic irony
Once you get to the general public it's another matter entirely; for instance, look at how 538 was pilloried for their "30% chance to win the presidency for the current head of state," and how many times they've put out detailed information on how 30% =/= 0%. Your general person running review of the data (not the engineer hiding in the back office tuning the results, who should have access to the information) is going to treat most things above 50% as inherently true and anything below 50% as inherently false (within some margin of error, i.e. 50% +/- 5 points).
It would be better to go the 'dumb' machine route of setting up some standard escalation flags; which looks like it may be what happened with this (albeit in a bad way), "person self filing and < 18 years of age; raise flag." The system being bad at differentiating 1919 & 2019 and then sending out an automated response seems more like a bad UX problem at this juncture, since it's something that could have been avoided with a quiet internal flagging instead of a loud external one.
handing their own papers to an employer of UK home office?
I don't think so...
So I don't really understand how it can misinterpret the birth date unless someone really stupidly coded the system to keep only the last 2 digits of year and then try to guess what it really was later...