The Y2K problem threatened to bring down computers worldwide twenty-one years ago. In another seventeen years, the Year 2038 problem may do the same.
Today I had a conversation with someone too young to remember the Y2K problem. Apart from being yet another reminder of how old I am, it was a surprise that something so well known has begun its long drift into civilisation’s memory hole. So, first, a brief recap.
Many computer systems last millennium recorded the year in two digits: 1997 registered as 97 and 1982 as 82, for example. This was a bad idea, because it meant those systems were not well equipped to handle the transition out of the 1990s. The year 2000 might register as 1900, or 19100, or the programme / database / essential system may just grind to a complete halt.
Doomsayers predicted anarchy: airplanes falling out of the sky, pacemakers switching off and people dropping dead in the street, nuclear power plants melting down… none of which ended up happening. Mainly due to the concerted efforts of a lot of computer programmers to go through all this faulty code and weed out potential date errors one by one. Governments and private companies worldwide spent around three hundred billion dollars fixing all of this faulty code.
You would hope that we learned something from the Y2K problem. But, as it turns out, safely and accurately incorporating time into computer code is a common and thorny challenge. And it may be a problem that we have to face again in a few years.
Many modern computer systems use Unix. Unix is an operating system that has been around since the late 1960s, and it records time in a very specific way: the number of seconds since the start of 1970. This “Unix time” is really convenient, because a computer can use a single number to represent a date and time without fussing with time zones, leap days, and other calendar idiosyncrasies. But it also introduces a new problem.
Many older Unix systems store the number representing Unix time in a container with limited space. (In technical terms, it is stored as a 32-bit integer.) And, at some point in the future, that container is going to run out of space. Just before a quarter past three in the morning, January 19, 2038, Unix time exceeds the 32-bit container. What happens then is anyone’s guess.
Hopefully, nothing. We have many years to clear out any old code, and for most computers 2038 will sail by without issue. But there will always be systems that don’t or can’t get updated in a timely fashion, and those systems are vulnerable.
And if you think that’s unlikely, consider MOCAS. This programme tracks contracts for the U.S. Department of Defense. It has been running since 1958. Fortunately MOCAS is not running on Unix (it predates Unix by a decade), but it’s a good illustration of just how long computer code can stick around. And in 2038, we’ll find out just how much ancient code is still out there.
The Generalist Academy 
One Reply to “The Year 2038 problem”