
The Y2K bug is back, causing headaches for developers again - nikbackm
https://www.zdnet.com/article/the-y2k-bug-is-back-causing-headaches-for-developers-again/
======
darrenf
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):

• [https://metacpan.org/pod/Time::Local#Year-Value-
Interpretati...](https://metacpan.org/pod/Time::Local#Year-Value-
Interpretation)

> _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_

•
[http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.h...](http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.html)

~~~
Legogris
I've seen a lot of weirdness in datetimes, but this really takes the cake.
It's like they couldn't conceive of software running for over 25 years.
(Actually, if you're at the "wrong" year when writing the code, it just takes
a single year to wreck this)

~~~
heavenlyblue
What exactly motivates one to use two-digit years instead of four-digit ones
inside your application?

I mean I understand if that two-digit year is a part of a form input (where
the logic makes sense btw).

But why would a software developer decide to use two-digit years inside the
application? Isn’t that like the first thing you would think about when you’re
implementing the format?

~~~
coldpie
Because our profession is a joke. Whatever is fastest, cheapest, and easiest
is what we do, with no regard given to things like long-term impact or
security. We have no standards for code quality or correctness built into any
of our tooling and processes. This no less true today than it was 40 years
ago. Perhaps the fallout in terms of crashes and ransomware will convince the
industry to start adopting quality standards, but I don't have my hopes up.

------
JauntyHatAngle
I know a mainframe dev who worked on y2k across a bunch of systems at the
time.

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.

Most agreed with enough convincing. Some did not, usually with the argument of
"the systems won't even be around in 2020!".

~~~
cgriswald
> "the systems won't even be around in 2020!".

I think in many cases the thinking is: s/the systems/I/

~~~
xmprt
It's not right but it makes perfect sense that no one would care about
building something that outlasts them unless they're super passionate about
it.

------
Arnavion
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.

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.

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.

(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.

~~~
jtl999
Wonder when the last current root certificate in a common OS (Windows, OS X,
mozilla ca-certificates, etc.) expires.

~~~
Arnavion

        $ pem=''; cat /etc/ssl/ca-bundle.pem | while read -r line; do pem="$(printf '%s\n%s' "$pem" "$line")"; if grep -q 'END CERTIFICATE' <<< "$line"; then openssl x509 -inform pem -enddate -noout <<< "$pem" | cut -d= -f2 | date -f - -I; pem=''; fi; done | sort -r | head -1
    
        2046-10-06

------
jedberg
I'm more worried about the Y2K38 problem.

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.

~~~
rconti
Was the first one a typo and you meant Y2K38? I assume so.

Retiring by 2038 is also my strategy :)

~~~
collyw
I am hoping it will be a nice earner before my retirement.

~~~
jedberg
Also a good strategy. Be a Y2K38 consultant just before retirement.

------
close04
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.

~~~
falcor84
How would that have happened? The expectated bug outcome is of a negative
duration, no?

~~~
greggyb
Negative durations are clearly impossible. Just take ABS of the duration to be
safe....

~~~
xxs
Unless, of course, you hit MIN_VALUE [abs(min_value) == min_value]

One of signs of inexperience is using abs(int) in hash functions...

~~~
greggyb
Gosh, I am spoiled by languages with decent numeric towers.

You mention it as a sign of inexperience, and I can't really disagree with
you. Just adding a nuance that inexperience can be due to loss of experience
as easily as lack of experience.

~~~
xxs
If you do hashtable/hashmap on a language that has no fixed integer type...
well yeah. But normally you'd like the data structures to map really well to
the hardware.

Pretty much all modern CPUs are two's complement ones - hence min integer is
impossible to convert to anything else (having just the highest/sign bit, and
rest zero)

------
hoiuyoi9087
I think it's hilarious some fixed the Y2K bug by introducing a Y2K20 bug.
Planned obsolescence/long con.

~~~
close04
> Planned obsolescence/long con

They were most likely just kicking the ball down the road either thinking that
a more permanent solution will be applied in the 2 decades to come, or just
not caring at all because they won't be around in 20 years.

Technical debt tends to accrue this way and many times it's not in bad faith.
It's meant as a short term solution to buy some time and ends up being
permanent because someone doesn't understand what's the point in spending more
money to fix an issue that was "obviously" fixed already.

~~~
LinuxBender
I wish I could upvote this a few times. I have created so many "just use this
for now" solutions that have been in use for more than a decade. The real
problem never gets fixed for exactly the reason you stated. "It's working, I
don't see a problem" (says the manager) and priorities go to other more
burning issues. The debt adds up to thousands of small cuts and and ultimately
the sum of the debt becomes very expensive to maintain in terms of hours
updating, debugging, getting someone who knows the history, finding old jira
issues, etc... I think can-kicking eventually contributes to burn-out.

~~~
LeonM
Nothing is more permanent than a temporary solution

~~~
mark-r
When I went to the University of Minnesota in the late '70's, there were
"temporary" buildings installed just after WWII that were still in use.

------
MockObject
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?

~~~
phire
We will probably see this minor annoyance pop up again every "nice round
number" for the next 70 years.

2025, 2030, 2040, 2050, 2060, 2075, 2080, 2090.

Every developer will have picked some random round number that made logical
sense to them.

------
bhaak
FWIW, at work we have regular failing tests after new year as the automated
tests usually work with the current year.

So I can relate that it's easy to write buggy date handling code even today.

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.

~~~
cwkoss
We have a couple tests that fail for 24 hours after a daylight savings change
as they don't accommodate 25 hour days.

~~~
paulie_a
I've been in numerous meetings where the options were come up with an
elaborate solution. Or the data will be skewed one day of the year and let's
go get lunch.

Guess which one we chose

~~~
bhaak
If you are Europe based, it doesn't even makes sense anymore to fix it as
daylight savings time is on its way out soon.

"Sitting the problem out" is a valid problem solving strategy. :-)

------
ravedave5
We had a build script that expected the final digit of the year to end between
4-9. Dumbest code I've seen in a while. Broke pretty bad on 2020.

~~~
cpcallen
Bah, what's the big deal? Just wait four years and the problem will go away by
itself!

------
mirekrusin
Any self respecting developer had chose 42 as pivot year.

------
jacobr
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?

In some cases “kicking the ball down the road” makes perfect sense, just
fixing what is most urgent.

------
villgax
Bigger deal is with 2038 bug

~~~
Chirael
Even bigger deal is the Y10K bug. But I'm sure these software systems won't
still be running then.

~~~
tachyonbeam
Sentient robots will do everything, from growing food to manufacturing,
cooking and even washing us. Humans will have forgotten how technology works,
reverting to superstitions and belief that technology is actual magic created
by ancient Gods. For thousands of years, robots had been engineering smarter,
better robots, and technology had become far too advanced and beyond the reach
of human minds... And then, all the robots will simultaneously freeze up at
midnight, December 31st, 9999.

~~~
cgriswald
Those sentient robots will have read the sum total of humanity's written
works, including your post. In accordance with Asimov's Zeroth Law of Robotics
they'll be required to act on that information, thus saving themselves and
preventing a second Dark Ages.

------
chelmzy
Splunk had a Y2020 bug as well

------
caseymarquis
Representing time may be the third hard problem in computer science. The more
you dig, the worse it gets.

------
dhosek
In 1999, I was fixing Y2K bugs at a company founded in 1997.

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.

~~~
gowld
Was that new code or libraries they picked up from wherever?

------
mark-r
The only fail I saw from the original Y2K was a credit card receipt dated
1/2/100.

~~~
jandrese
I saw a handful of receipts and the like that listed the year as 19100. I'm
about 99% sure that the fix was to subtract 100 from the year and change the
text field from "19" to "20", thus fixing the problem forever.

~~~
cpcallen
I'll take that bet!

The correct fix is to add 1900.

~~~
jandrese
Then the year would display as 192000.

~~~
mark-r
You're assuming the year was stored as 19100. It's far more likely it was
stored as 100, and "19" was prepended to a string conversion.

