4 ms·

Dates in passports' machine-readable zones only have two-digit years. Another victim: https://theguardian.com/uk-news/2020/feb/12/home-office-tells-man-101-his-

Dates in passports' machine-readable zones only have two-digit years. Another victim: https://theguardian.com/uk-news/2020/feb/12/home-office-tells-man-101-his-parents-must-confirm-id https://theguardian.com/uk-news/2020/feb/12/home-office-tell....

suyash 2y ago
dumb programmer who wrote that code and dumber qa who failed to test it
deepsun 2y ago
So it's basically well-known Y2K bug.
robertlagrant 2y ago
> Dates in passports' machine-readable zones only have two-digit years. Simultaneously the most and least surprising situation.
cedilla 2y ago
I was about to write that surely, that only applies to the OCR section printed on the physical passport, but if I read ICAO 9303 correctly, it's the other way round - the OCR section can include either a four-digit year or a two-digit year, but the chip has only six bytes for the date of birth, representing YYMMDD in digits (plus special characters for an unknown or partially known date of birth). Edit: apparently there's an optional section in the chip (data group 11 or DG11) that allows for longer-form data than the ancient machine-readable format, including non-latin letters in the name and a birthdate including the century. I don't know how widely used that is though.
sedatk 2y ago
Waves fist towards the sky: COBOL!
- tapland 2y ago
  \o/ Deal with this all the time working with an old system written in COBOL. Current system was patched with a db column for century. The problem that really flies under the radar though: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
miki123211 2y ago
The Polish PESEL system, which encodes your birth date in your national identification number, found a nice way around this. We just add 20 to your birth month if you were born in the 21st century or 80 if you were born in the 19th. This exploits the fact that a month is always in the range 1-12, and so using a two-digit number for it wastes a large part of the possible space of dates. We still have the 41-52 and 61-72 ranges unused for the 22rd and 23rd centuries, and then we can re-use 80 (since it's extremely unlikely for anybody from the 19th century to survive that long). Now that's some long-term planning. However, it's often said that no plan survives contact with reality, and that's also unfortunately true for this system. All that future proofing, and now it turns out that some assumptions thought inviolable, namely that people are either strictly male or strictly female and never change their gender, aren't so inviolable after all. We use a single bit to encode gender (it's the evenness or oddness of a particular digit in the number), and we also assume that PESEL numbers never change, to the point of using them as primary keys in some databases. The latter is causing trouble right now, and the former is inevitably going to.
- Freak_NL 2y ago
  Not even the date of birth is necessarily stable. The exact date is of course, but in some cases it was registered wrongly; this happens sometimes with immigration. National identification numbers should be opaque; just a number unique in its own domain, but encoding nothing¹. 1: An exception is to have a certain ranges of those numbers designated for testing, so you can test stuff without ever accidentally using a real one.
  - vidarh 2y ago
    It doesn't really matter if it's stable if the value used in the national id number is just seeded with the best option at the time it is assigned, though, and in that case it can still be convenient to use a value that for most people will be easy to remember. E.g. it's easier for me to remember the 5 digits on top of my birth date than to remember the full 11 digits of my Norwegian id number. That a small proportion of people have leading 6 digits that aren't a perfect match for their birth dates may be a minor nuisance for them but no more *as long as people don't assume the leading digits can be relied on.
yonatan8070 2y ago
If only there was some way to densely print computer readable data onto paper
julian_t 2y ago
I did a contract in the run-up to Y2K to help with some code that used two-digit year fields. In their defence, it was originally written in Fortran II sometime in the early 60s, and I think they can be forgiven for not thinking it might still be in use nearly 40 years later!

suyash 2y ago

dumb programmer who wrote that code and dumber qa who failed to test it

deepsun 2y ago

So it's basically well-known Y2K bug.

robertlagrant 2y ago

> Dates in passports' machine-readable zones only have two-digit years. Simultaneously the most and least surprising situation.

cedilla 2y ago

I was about to write that surely, that only applies to the OCR section printed on the physical passport, but if I read ICAO 9303 correctly, it's the other way round - the OCR section can include either a four-digit year or a two-digit year, but the chip has only six bytes for the date of birth, representing YYMMDD in digits (plus special characters for an unknown or partially known date of birth). Edit: apparently there's an optional section in the chip (data group 11 or DG11) that allows for longer-form data than the ancient machine-readable format, including non-latin letters in the name and a birthdate including the century. I don't know how widely used that is though.

sedatk 2y ago

Waves fist towards the sky: COBOL!

tapland 2y ago
\o/ Deal with this all the time working with an old system written in COBOL. Current system was patched with a db column for century. The problem that really flies under the radar though: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem

miki123211 2y ago

The Polish PESEL system, which encodes your birth date in your national identification number, found a nice way around this. We just add 20 to your birth month if you were born in the 21st century or 80 if you were born in the 19th. This exploits the fact that a month is always in the range 1-12, and so using a two-digit number for it wastes a large part of the possible space of dates. We still have the 41-52 and 61-72 ranges unused for the 22rd and 23rd centuries, and then we can re-use 80 (since it's extremely unlikely for anybody from the 19th century to survive that long). Now that's some long-term planning. However, it's often said that no plan survives contact with reality, and that's also unfortunately true for this system. All that future proofing, and now it turns out that some assumptions thought inviolable, namely that people are either strictly male or strictly female and never change their gender, aren't so inviolable after all. We use a single bit to encode gender (it's the evenness or oddness of a particular digit in the number), and we also assume that PESEL numbers never change, to the point of using them as primary keys in some databases. The latter is causing trouble right now, and the former is inevitably going to.

Freak_NL 2y ago
Not even the date of birth is necessarily stable. The exact date is of course, but in some cases it was registered wrongly; this happens sometimes with immigration. National identification numbers should be opaque; just a number unique in its own domain, but encoding nothing¹. 1: An exception is to have a certain ranges of those numbers designated for testing, so you can test stuff without ever accidentally using a real one.
- vidarh 2y ago
  It doesn't really matter if it's stable if the value used in the national id number is just seeded with the best option at the time it is assigned, though, and in that case it can still be convenient to use a value that for most people will be easy to remember. E.g. it's easier for me to remember the 5 digits on top of my birth date than to remember the full 11 digits of my Norwegian id number. That a small proportion of people have leading 6 digits that aren't a perfect match for their birth dates may be a minor nuisance for them but no more *as long as people don't assume the leading digits can be relied on.

yonatan8070 2y ago

If only there was some way to densely print computer readable data onto paper

julian_t 2y ago

I did a contract in the run-up to Y2K to help with some code that used two-digit year fields. In their defence, it was originally written in Fortran II sometime in the early 60s, and I think they can be forgiven for not thinking it might still be in use nearly 40 years later!