The epochalypse is coming

Nobody knows when the world will end for sure, but UNIX systems have a guess: January 19, 2038.

This is a problem, of course, because UNIX systems power huge swaths of the Internet, including the site you’re reading this piece on, most routing and switching equipment needed for the network to work, your iPhone, and possibly even your smartwatch or car. The way that most UNIX systems keep track of time is in a 32-bit signed integer that counts the number of seconds since an arbitrary point (the epoch) of January 1, 1970 at 00:00:00 UTC.

The maximum value that a 32-bit signed integer can have is 2,147,483,647 (bonus points if you can figure out why that’s the maximum without being a computer scientist and/or nerd,) which, if you do the math, works out to be January 19, 2038, at 03:14:07 UTC. One second past that is a time counter overflow, which results in the time flying 137 years into the past, because the time counter becomes -2,147,483,648.

The reason it was designed this way was due to memory efficiency reasons. (If you’re thinking that that sounds like why the Y2K bug happened, you’re right!) Additionally, it was important to be able to represent times before 1970, so the decision was made to use a signed integer (meaning it can be negative, to reflect times before the epoch.) A 32-bit version was used because “Hey, surely we’ll have come up with something better than UNIX before 2038.” Using a 64-bit version would have extended the range of timestamps up until about the heat death of the universe, but it would also make all time storage take twice as much space – and memory was a precious commodity when UNIX was being designed. Now, of course, even your iPhone uses 64-bit data structures for everything.

You may wonder why we’re talking about this now, given that 2038 is 21 years away. The reason is because of a discussion on LWN that circulated on a popular tech news site a few weeks ago, reminding us all that this is coming.

UNIX’s time issue has already caused some problems, including the famous incident where House Rep. Paul Ryan suggested that the Congressional Budget Office couldn’t “conceive of any way in which the economy can continue past the year 2037 because of debt burdens.” (emphasis added). The real cause of the CBO’s failure was more likely time counter overflow. Picture this scenario: You’re trying to evaluate the long-term effect of a bill, so you want to run a model that looks 40 years in the future. You know how UNIX stores time (again, as a number of seconds,) so you decide to just add 40 years worth of seconds (1.2 billion or so) to the start time of your analysis. This makes the time variable overflow and your analysis doesn’t work. A time variable overflowing also appears to be the cause of the loss of a spacecraft, and I’m sure we’ll discover more things that fail as they try to do calculations involving dates in the future.

Back to the problem at hand – what exactly happens when the time counter exceeds the magic 2 billion number? Because the variable in question is a signed integer, it actually becomes negative. So, one second after the magic moment in early 2038, the UNIX time counter will be negative 2,147,483,648, causing apps to jump ahead to the past – specifically to think the time is actually December 13, 1901 at 20:45:52 UTC. As you might imagine, time suddenly going back 137 years may cause some problems in various things that need to keep track of what time it is, but luckily, the people who maintain Linux and other UNIX-based systems are actively working on fixing the “Year 2038 problem,” as Wikipedia calls it.

Besides, they still have 21 years, so surely we won’t wait until the last minute like a certain other time-related bug… right?