I worked on a 2k20 bug just last week. Some of the Perl at work started returning strange values, and tests were failing. Turns out we were using `Time::Local`'s `timelocal/timegm` subs. They use convoluted interpretation of 2-digit years – which we were, of course, passing (and for no good reason):<p>• <a href="https://metacpan.org/pod/Time::Local#Year-Value-Interpretation" rel="nofollow">https://metacpan.org/pod/Time::Local#Year-Value-Interpretati...</a><p>> <i>Years in the range 0..99 are interpreted as shorthand for years in the rolling "current century," defined as 50 years on either side of the current year. Thus, today, in 1999, 0 would refer to 2000, and 45 to 2045, but 55 would refer to 1955. Twenty years from now, 55 would instead refer to 2055. This is messy, but matches the way people currently think about two digit dates</i><p>• <a href="http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.html" rel="nofollow">http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.h...</a>
I know a mainframe dev who worked on y2k across a bunch of systems at the time.<p>Asked him about it, he said that they warned management not to window the code to 2020, and showed alternatives that would take longer to code but would be future proofed.<p>Most agreed with enough convincing. Some did not, usually with the argument of "the systems won't even be around in 2020!".
Speaking of pivot years, there's a similar rollover in 2050 for RFC 5280 style datetimes, eg not-before and not-after times in X.509 certificates. The RFC defines two datetime string formats - "UTCTime" which has a two-digit year, and "GeneralizedTime" which as a four-digit year. The two-digit one is parsed as 0 <= YY < 50 implying 20YY and 50 <= YY < 100 implying 19YY. For not-before and not-after times, certificates are required to use UTCTime for datetimes before 2050 and only use GeneralizedTime for times after that.<p>So there can be applications today that parse ASN.1 datetimes manually (1) but only expect the UTCTime format. They'll break when they encounter a cert with a not-after beyond 2050 because it'll be in the GeneralizedTime format instead.<p>Luckily this one will be detected over a period of time rather than happening at precisely 2050-01-01 00:00:00, so there's more time to fix it in each application that has the bug.<p>(1) if the application wants to parse it into a `struct tm` for manipulation, for example. For that specific case, openssl 1.1.1 added `ASN1_TIME_to_tm`, so it's only a problem for applications that don't use openssl or need to support older versions. One can hope that at least the latter will stop being a requirement as 2050 gets closer.
I'm more worried about the Y2K38 problem.<p>I'll be just over 60 years old when that happens. With any luck, I'll be retired and not have to worry about it... I think having to deal with both Y2K and Y2K38 in one career is too much.
I remember disconnecting my dialup session and checking that nobody is on the phone as the clock ticked midnight just to make sure we don't get billed for a 100 year long call.
It's not clear to me why anyone in 2000 would choose 20 as the pivot year, unless they were working on a system that needed to regard 1921. Why wouldn't a parking meter or subway system pivot at, say 1990?
FWIW, at work we have regular failing tests after new year as the automated tests usually work with the current year.<p>So I can relate that it's easy to write buggy date handling code even today.<p>But at least we have tests. All those poor programmers that worked on Y2K didn't have them. And those that work on Y2k20 bugs probably still don't.
Sounds like a reasonable solution for some systems in 1999. How many of the systems that were fixed properly died the following years anyway, and the millions invested were overkill and unnecessary?<p>In some cases “kicking the ball down the road” makes perfect sense, just fixing what is most urgent.
In 1999, I was fixing Y2K bugs at a company founded in 1997.<p>At least the programmers writing code in the 80s had an excuse. It was the Reagan years. Nobody thought civilization would make it until the year 2000.