Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

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

View on HN

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.

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.

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.

There should be at least a checksum (which we also do have, even though many systems sadly don't check it).

Skatteverket (Sweden) puts a plus symbol when you turn 100. "Between the birth date and the birth number is a hyphen (-), which is replaced by a plus sign (+) in the year the person becomes 100 years old."[1]

Whoever processes the Swedish Identity Number, even if they use YYYYMMDD-SSSC _or_ YYMMDD-SSSC, wouldn't break processing with YYYYMMDD+SSSC or YYMMDD+SSSC - as the '+' is a standardised "give away" as to the age of the person (making the 4-digit YYYY less desirable for processing).

[1] - https://www.skatteverket.se/servicelankar/otherlanguages/ine...

I feel like (anecdotally) I have been asked more regularly for the full 12 digit number in most systems in the past at least some number of years instead of the 10 digit number. I wonder if more systems are being designed from the start to require millennium and century? I have not been keeping track or anything. I just feel like I am more often required now to input YYYY rather than YY.

I wonder if that's because there's an assumption that validation has to occur via the Luhn Algorithm (or Modulus 10)[1] on the input-side?

Edit: I'd just let BankID handle the validation and store the two-digit year.[2]

[1] - https://en.wikipedia.org/wiki/Personal_identity_number_(Swed...

[2] - https://www.bankid.com/en/

This is already built into the system though and you can refresh your PESEL in those cases and invalidate the previous one. Which, for handling rare edge cases isn't a bad solution really.

I know several people who went through this process, and it's not pretty. Besides the bureaucratic hassle, some systems, particularly in the medical sector, are just straight up not designed to handle those kinds of changes. Almost everything healthcare-related here is tied to your PESEL and spread through dozens of different databases (and possibly paper files) which are hard to impossible to modify. I've heard of vaccination info being lost, prescription fulfilling issues and the ePatient portal straight up refusing to work with strange errors. Apparently for some banks, the recommendation used to be to close your account and just go to another bank which never saw your old data, although that has now gotten better as far as I know.

Do Polish passports encode gender? I'd expect passports to encode biological sex.

Australian passports are 3 value, M,F,X (for other) as some people are born biologicaly intersex (there are a few hundred such in Australia) and in such cases either M or F are just wrong.

Australian birth certificates do a similar thing .. and Polish birth certificates and passports for those born oversees are supposed (see gov.pl site) to reproduce exactly what is on the foreign birth certificates and passports.

As the GP comment notes, supposedly invarient assumptions can bite programmers in the ass.

Assumptions is also one of the reasons for a long-lasting trend towards reducing the information on passports where it risks misleading. E.g. my first passport had hair colour and eye colour, and a colour photo. The hair colour and eye colour was removed because it was increasingly just confusing and unreliable, and the photo is now black and white. I'd expect gender/sex to eventually be emphasised or removed too, for the same reason - it's not particularly helpful as a means of ID'ing you unless you do a medical examination.

US passports are M, F, X as well. Intersex/NB/GNC individuals like myself aren't accurately represented with only M/F.

The UK is dragging its heels on this kind of thing. https://infosec.exchange/@ryanc/112334233396294602

> I moved to the UK five years ago. My birth certificate and passport list my sex as Nonbinary/X. My application for legal gender recognition was granted two years ago, but then things got weird... I had to take the government to court.

For some reason, the government is refusing to issue the documents they've granted the applications for. Per https://www.leighday.co.uk/news/news/2024-news/nonbinary-us-..., the High Court has ruled that this is discriminatory, but that the government is allowed to discriminate against non-binary people. The case is due before the Court of Appeal at some point in the future.

Up-to-date info can be found at https://enby.org.uk/ (currently a GoFundMe redirect).

No idea what passports do, but the internal documents do encode what English calls gender, which is, admittedly, very difficult to change.

Polish doesn't really have this distinction, there's one word we use for both, and more descriptive terms are needed if you actually need to be specific.

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.

> Dates in passports' machine-readable zones only have two-digit years.

Simultaneously the most and least surprising situation.

Waves fist towards the sky: COBOL!

\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

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!

So it's basically well-known Y2K bug.

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

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

Reply on news.ycombinator.com