The Y2K38 Bug by Shalynn Ho Abstract

Military, medical, telecommunication, and transportation systems failures, large-scale power outages, and banking system crashes are just a few examples from a long list of things that can and will go wrong if we don't prepare for Y2K38, which will occur when the internal data type keeping track of time overflows and becomes a negative number. Luckily, we know exactly when and why disaster plans to strike, which means that by taking the appropriate precautions, we can minimize the damage. If we approach this situation seriously and prepare for it fully, we may even be able to prevent it.

Y2K38, also known as the "Year 2038 Problem" or the "Unix Millennium Bug" refers to an issue that exists due to limitations of the way time is fundamentally represented in most computer systems. This problem is set to occur on January 19, 2038 at 03:14:07 UTC (Coordinated Universal Time)¹, when the internal data type keeping track of time (think of this as a variable), time_t, essentially "runs out of space." Try setting the date on your phone to a day beyond this. iPhones will only allow you to reach January 1, 2038, and the rest of the dates are grayed out. In the past, some Android devices have been reported to crash and fail to reboot when set to this date [1]. Unless this issue is addressed, the value representing time will "wrap around," producing drastically inaccurate time readings and potentially dangerous consequences. At this point, every program or machine that uses time_t for time or date calculations will think that the year has become 1901. Although the wraparound date is a good 25 years away, this is not a sufficient reason to delay action by assuming that programs will only be affected in or around 2038. Programs dealing with future dates, such as loan or mortgage calculations, will face this problem much sooner. Fully implementing a solution to Y2K38 will take many years, so it is important that we begin now.

There have already been cases of problems caused by the Y2K38 bug. In 2006, AOLserver software was built with a workaround to handle a request that would "never" timeout. To simulate this, the design specified a timeout date one billion seconds (approximately 32 years) in the future. On May 12, 2006, one billion seconds past 9:28:26 PM exceeded the 2038 overflow date, returning a timeout limit value that was actually in the past, which caused the AOLserver software to crash [3]. Another early manifestation of the Y2K38 bug revealed itself when the Mars rover Opportunity had a software crash: "The rover was babbling, doing things like sending nonsensical communications that it date-stamped as being from the year 2038 [4]."

time_t is a data type used by C and C++ programs to represent dates and times internally. It is almost universally implemented as a single 32-bit signed (positive or negative) integer, which represents the total number of seconds (not including leap seconds) since January 1, 1970 at 00:00:00 UTC. This date is commonly referred to as "the Unix epoch" or sometimes just "the epoch." [5]

Unlike the odometer on your car, a signed integer will not reset to zero when it overflows. Instead, it wraps around to the lowest possible negative number. In this case, the second time_t tries to increment past its upper limit, its numerical representation will "wrap around" and become negative: time_t = - 2,147,483,648, which represents December 13, 1901 at 20:45:52 UTC. In just one second, Tuesday, January 19, 2038 will suddenly become Friday, December 13, 1901 in every computer in the world (that can handle negative time values). It's not difficult to predict a few of the more obvious problems this will cause. In addition, many programs do not know how to deal with negative time values at all – they will simply fail and return an error code. Unless this particular error is specifically checked for, in many cases, the program will simply crash.

(An animated image illustrating the rollover can be viewed here: http://commons.wikimedia.org/wiki/File:Year_2038_problem.gif)

For those of you who don't remember, the Y2K bug was a computer flaw that had to do with the common practice of abbreviating four-digit years with only the last two digits. Back in the 1960s – 1980s, dates were stored in YYMMDD format, where each character took one whole byte (8 bits) of computer storage. Two bytes (16 bits) saved per date entry was a significant amount, especially considering that just about every record in a computer has a timestamp. As a result, the "19" was omitted. For example, the year 1980 would simply be stored as "80." This posed a serious problem as the year 2000 approached. Instead of 2000, it would simply read "00" and most programs would interpret this as 1900, causing a multitude of problems – primarily, calculations being off by negative 99 years [6]. In hindsight, it's easy to say that programmers should have anticipated Y2K, but computers were a new technology in the 1960s and programmers did not expect their code to still be in use over 50 years later.

In the end, over 300 billion US Dollars were spent to correct problems that might occur because of the Y2K bug. The number of actual failures due to Y2K is unknown. However, the number of reported incidents was much less than the hype predicted, leading many to question whether this was a result of excellent preparation or if the problem had been grossly exaggerated [7].

While the Y2K bug and the Y2K38 bug are both time/date-related issues, they occur on completely different scales. Everything that Y2K was supposed to affect (or did affect) will also be affected by the Y2K38 bug. But Y2K38 happens on a much more fundamental level, the actual representation of time itself – which is a problem because it affects just about any program or device that needs to know about time. While Y2K was relatively easy to understand, Y2K38 is a little more difficult in that it requires a deeper understanding of how time is digitally managed in computers, which may contribute to its obscurity. In addition, because of the perception of overhype and unnecessary alarm associated with Y2K since "nothing happened" and "the world didn't end," it's easy to see why Y2K38 is being so easily dismissed as a problem that will fix itself. However, this optimism may not be enough to get through to 2038 unscathed. It is likely that the overwhelming media attention toward Y2K forced businesses to proactively address it, mitigating the issue almost fully prior to the start of the millennium [8].

There are fundamental differences between the problems that faced Y2K and those currently facing Y2K38; however, the primary concern for both is the same: legacy code – a base set of old code that has been recycled and revamped over years, even decades. The reason Y2K was so expensive is that almost every piece of software uses past code that followed the two-digit year convention, meaning that programmers had to manually go in and modify the base code for every program that uses time. Developing entirely new software is extremely expensive and time-consuming, not to mention fraught with headaches. For the most part, it makes much more economical sense to improve and develop existing programs, which we know work, than to build our own from scratch. It is important to note that software developers and computer designers must maintain backward compatibility even with the newest programs and devices – a computer that can't run anything older than itself is pretty much useless.

Now, the problem with Y2K38 is that it affects both software and hardware. Simply going into the code and adding more digits will not solve this problem, because all of the hardware that wasn't physically built for the time variable to hold more than 32 bits of data must be redesigned and replaced. On the software side, it's not just the code that has to be modified, but the programming languages themselves. The problems facing Y2K38 are much more daunting than Y2K, not to mention expensive.

The horror of complacency can be witnessed in many who know of the problem but are not concerned, perhaps thinking that switching to 64-bit hardware will completely mitigate the problem. Even in 2038, it is likely that every PC will have a 64-bit CPU, but will still be running a fair number of 32-bit programs which may not be year 2038 compliant. And as Wilcox states, "the larger, more complex, and more important any program is, the better are its chances that it'll be one of these old 32-bit programs [9]." This doesn't even touch on the problem of embedded systems that use time for computation, safety, or diagnostic logging purposes, including automobiles, anti-lock braking system (ABS), traction control (TCS), advanced avionics, and communications devices including Internet and mobile electronics (smart phones and tablets.)

One of the biggest problems to overcoming Y2K38 is the significant lack of awareness about the problem itself. Unlike the very visible Y2K bug for which one could simply look at a digital watch to understand the general idea, Y2K38 lurks beneath the surface and the problem itself is much more obscure. There are managers of software development departments who may have little or no programming experience. It is quite possible that testing products for dates beyond 2038 may simply not occur to them. In addition, software fixes for Y2K contributed nothing to fixing the Y2K38 problem, which concerns both software and hardware, as they are completely independent problems [9].

Many people have suggested changing time_t from a signed integer into an unsigned integer, which will buy time until 2106. This change would only be possible on some systems as it would break time comparisons prior to Unix epoch (during which time_t is negative), and may affect how some programs compute time differences [8].

There is no universal solution, as each solution is dependent on the function of the software or hardware involved. However, the simplest, and most talked-about, solution is to move to year 2038 compliant 64-bit platforms, as this will provide a new wraparound date over 22 times the estimated age of the universe, approximately 292 billion years from now. Problems with this include legacy code, and backwards compatibility with older platforms, which may still be running 32-bit code [9]. Although this may sound like an easy fix, the costs of a major worldwide upgrade such as this will be tremendous; estimates are upward of 10 times the cost of Y2K, one site even suggesting that, taking inflation into account, costs of preparing for Y2K38 will easily exceed 10 trillion USD [8].

It is important that engineers are made aware of Y2K38 and the severity of the consequences that could result if the problem isn't addressed seriously. While it may be cool to see the date skip back to 1901 (if you're lucky and the device doesn't just break) and 2038 might seem very far away, the time it will take to slowly and fully upgrade our systems, integrating new code and new hardware while remaining up and running, will take many years so we must begin now.

[1] "Issue 16899: Year 2038 problem," Android, 16 May 2011. [Online]. Available: http://code.google.com/p/android/issues/detail?id=16899. [Accessed 6 February 2013].

[2] J. L. Smoot and P. J. Meyer, "What is UTC?," NASA - Marshall Flight Space Center, 29 March 1995. [Online]. Available: http://wwwghcc.msfc.nasa.gov/utc.html. [Accessed 6 February 2013].

[3] "Year 2038 Problem," Wikipedia, 8 February 2013. [Online]. Available: http://en.wikipedia.org/wiki/Year_2038_problem. [Accessed 9 February 2013].

[4] Jet Propulsion Laboratory, "Mission Fantastic to Mars (Part 4)," California Institute of Technology, [Online]. Available: http://marsrovers.jpl.nasa.gov/spotlight/20040831.html. [Accessed 6 February 2013].

[5] The Open Group and IEEE, "The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition (definition of epoch)," The Open Group; IEEE;, 2004. [Online]. Available: http://pubs.opengroup.org/onlinepubs/000095399/. [Accessed 6 February 2013].

[6] "Y2K Bug," National Geographic Society 1996-2013, [Online]. Available: http://education.nationalgeographic.com/education/encyclopedia/Y2K-bug/?ar_a=1. [Accessed 6 February 2013].

[7] "Year 2000 Problem," Wikipedia, 6 February 2013. [Online]. Available: http://en.wikipedia.org/wiki/Year_2000_problem. [Accessed 6 February 2013].

[8] "Y2038 Frequently Asked Questions (FAQ)," Y2038.com, [Online]. Available: http://www.y2038.com/. [Accessed 6 February 2013].

[9] R. M. Wilcox, "The Year 2038 Problem," 23 October 2003. [Online]. Available: http://www.rogermwilcox.com/Y2038.html. [Accessed 6 February 2013].