Georg Lukas, 2017-07-13 19:11

The Bill-and-a-half-ennium

Tonight (2017-07-14), at or around 02:40:00 GMT, the Unix time will have a value of 1 500 000 000 seconds, counting from January 1st, 1970. The last event of this kind, when Unix time reached 1 000 000 000 seconds, has been on September 9th, 2001, when the world still was a nice and good place. Because that was a billion seconds, some people incorrectly called it the "Billennium". Yours truly actually stayed up late enough (01:46 GMT) to celebrate the event with a hacker friend.

If you want to celebrate this special decimal representation of an arcane time measure, there is a nice countdown page!

The next one of this kind, 2 000 000 000, will be in 2033, so you better party hard this time!

The Year 2038 Problem (Y2K38)

This is also a good reminder of the many systems that are still using Unix time internally, and the legacy and embedded ones that store it in a 32-bit signed integer. Because this kind of integer overflows at 2 147 483 647, which will happen in 2038, all kinds of problems are expected.

There is already a great writeup on the current state of affairs regarding Y2K38 support, so instead of an in-depth technical analysis I'm going to provide a personal anecdote.

My first encounter with Y2K38 was in 2002 - a phone call from a relative who had trouble logging into an SSH server using PuTTY. It took some time to figure out the root cause - a dead CMOS battery in the PC led to incorrect clock values, bringing the machine far into the future, some time into the 2040ies.

Being a good citizen, I reported the bug to the developers (with a detailed explanation of the setup and a stack trace), and got a rather laconic answer:

Date: 11 Feb 2002 22:54:52
Subject: putty crashing on time() overflow

Georg Lukas writes:

putty is crashin with an access violation when you try to connect to a host and it is after time() goes over 232 (i.e. after Tue, 19 Jan 2038 04:14:07 +0100).

Thanks for the timely bug report. With a bit of luck we'll fix this one before it becomes a problem for too many users.


I haven't quite followed up, but recent versions of PuTTY, on a recent 64-bit Windows, don't exhibit this problem any more, so it looks like we are safe!


While we still have a bit more than 20 years to fix Y2K38, I'm sure that there will be plenty of legacy 32-bit systems running when the date approaches. As with Y2K, there will be denial, anger, bargaining, depression and acceptance. And maybe a big boom that brings down the whole IT, however it might look in 20 years.

One way or the other, I will be a professional Y2K38 consultant with 36 years of working experience! Please contact me soon so I can ensure a timely retirement to some far-away island before day X! ;-)