Year 2038 bug

The Year 2038 bug is a predicted problem in some computer systems that might cause problems at that time.

What is the year 2038 bug?

In the first month of the year 2038 C.E. many computers will encounter a date-related bug in their operating systems and/or in the applications they run. This can result in incorrect and grossly inaccurate dates being reported by the operating system and/or applications. The effect of this bug is hard to predict, because many applications are not prepared for the resulting "skip" in reported time - anywhere from 1901 to a "broken record" repeat of the reported time at the second the bug occurs. Also, leap seconds may make some small adjustment to the actual time the bug expresses itself.

Some technologists have predicted this bug will cause serious problems on many platforms, especially Unix and platforms that count time in Unix-like manners (which includes Windows), because these systems will "run out of time". Some commentators have even predicted that starting at GMT 03:14:07, Tuesday, January 19, 2038, satellites will start falling out of orbit, massive power outages (like the 2003 North American blackout) will occur, hospital life support systems will experience failures, phone systems (including 911 emergency services) will be interrupted, and various banking systems will crash, etc. The reasoning behind this is that one second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences.

What causes the Year 2038 Bug?

Example showing how the date would reset (at 03:14:08 UTC on 19 January 2038).

What makes January 19, 2038 a special day? Unix and Unix-like operating systems do not calculate time in the Gregorian calendar, they simply count time in seconds since their arbitrary "birthday", GMT 00:00:00, Thursday, January 1, 1970 C.E. The industry-wide practice is to use a 32-bit variable for this number (32-bit signed time_t). Imagine an odometer with 32 wheels, each marked to count from 0 and 1 (for base-2 counting), with the end wheel used to indicate a positive or negative integer. The largest possible value for this integer is 2**31-1 = 2,147,483,647 (over two billion). 2,147,483,647 seconds after Unix's birthday corresponds to GMT 03:14:07, Tuesday, January 19, 2038. One second later, many Unix systems will revert to their birth date (like an odometer roll-over from 999999 to 000000). Because the end bit indicating positive/negative integer may flip over, some systems may revert the date to 20:45:52, Friday, December 13, 1901 (which corresponds to GMT 00:00:00 Thursday, January 1, 1970 minus 2**31 seconds). Hence the media may nickname this the "Friday the Thirteenth Bug". Unconfirmed reports suggest that the roll-over could even result in a system time of December 32, 1969 on some legacy systems!

What operating systems, platforms, and applications are affected by it?

By and large, most modern desktop and server operating systems appear to exhibit the year 2038 bug. Only a mere handful of operating systems appear be unaffected by it. Most modern operating systems that are 32-bit (and some which are 64-bit) exhibit the bug.

A quick check with the following Perl script may help determine if a computer will have problems (this requires Perl to be installed on your system, of course):

#!/usr/bin/perl
#
# There are a few versions of this algorithm
# online, so it's difficult to know who to credit.
# This code is assumed to be GPL unless proven otherwise.
# Comments provided by William Porquet, August 2007.
# You may need to change the line above to
# reflect the location of your Perl binary
# (e.g. "#!/usr/local/bin/perl").
# Also change this file's name to '2038.pl'.
# Don't forget to make this file +x with "chmod".
# On Linux, you can run this from a command line like this:
# ./2038.pl
use POSIX;
# Use POSIX (Portable Operating System Interface),
# a set of standard operating system interfaces.
$ENV{'TZ'} = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
for ($clock = 2147483641; $clock < 2147483651; $clock++)
{
    print ctime($clock);
}
# Count up in seconds of Epoch time just before and after the critical event.
# Print out the corresponding date in Gregorian calendar for each result.
# Are the date and time outputs correct after the critical event second?

This source code can be downloaded as a text file here.

For example, the output of the Perl test script on Debian Linux (kernel 2.4.22):

# ./2038.pl
Tue Jan 19 0 3:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901

Here's the output of the Perl test script on Windows 2000 Professional with ActivePerl 5.8.3.809 - note that it fails in such a manner that it stops displaying the date at all after the critical second:

C:\>perl 2038.pl
Mon Jan 18 22:14:01 2038
Mon Jan 18 22:14:02 2038
Mon Jan 18 22:14:03 2038
Mon Jan 18 22:14:04 2038
Mon Jan 18 22:14:05 2038
Mon Jan 18 22:14:06 2038
Mon Jan 18 22:14:07 2038

MPE, an operating system from Hewlett-Packard, reacts in an entirely different manner, reverting to the year 2003 for some reason:

Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Mon Dec 29 10:20:48 2003
Mon Dec 29 10:20:48 2003
Mon Dec 29 10:20:48 2003

MPE script results are provided by "MPEDonna", a.k.a. Donna Garverick. She's reported to the present author that there exists, at the time of her correspondence in 2004, a fair number of 911 systems around America running on MPE. However, she expects the hardware to fail long before 2038, forcing integration of a new platform. Additionally, she notes that several very large, well-known insurance companies depend heavily on MPE. They are likely all in the process of migrating off that platform, but their progress and ultimate migration plans are unknown.

So far, the few operating systems that haven't been found susceptible to the 2038 bug include very new versions of Unix and Linux ported to 64-bit platforms. Recent versions of QNX seems to take the temporal transition in stride.

For a recent relevant example of the wide-spread and far-reaching extent of the 2038 problem, consider that the Mars rover Opportunity that had a software crash which resulted in it "phoning home" whilst reporting the year as 2038 (see paragraph under heading "Condition Red").

Some Unix vendors have already started to use a 64-bit signed time_t in their operating systems to count the number of seconds since GMT 00:00:00, Thursday, January 1, 1970 C.E. Programs or databases with a fixed field width should probably allocate at least 48 bits to storing time values. 64-bit Unix time would be safe for the indefinite future, as this variable won't overflow until 2**63 or 9,223,372,036,854,775,808 (over nine quintillion) seconds after the beginning of the Unix epoch - corresponding to GMT 15:30:08, Sunday, December 4, 292,277,026,596 C.E. This is a rather artificial and arbitrary date, considering that it is several times the average lifespan of a sun like our solar system's, the very same celestial body by which we measure time. The sun is estimated at present to be about four and a half billion years old, and it may last another five billion years before running out of hydrogen and turning into a white dwarf star.

Applications may inherit the underlying operating system's inability to deal with date calculation, and they can have their own problems with the year 2038 too. To properly test an application, you may need to use a piece of software like the FakeTime Preload Library to intercept various system calls which applications use to retrieve the current date and time.

Detractors and critics

Some critics charge that the year 2038 will, at best, be a non-issue. At worst, it may be called a hoax perpetrated to cause a run on technical consulting in another 20 years or so. Some compare the 2038 bug to the year 2000 (or Y2K) bug, saying that the year 2000 turned out to be a non-event. The opinion of Y2K being a "non-event" is often hotly debated by those who claim to have worked feverishly to fix those bugs in the years leading up to 2000.

A counter-argument to this "what, me worry?" attitude might include reports of temporal echoes of the 2038 problem which are already starting to appear in future date calculations for Web server software (e.g. AOLServer), 30-year mortgages, insurance policies, and vital statistics. The watershed for such look-ahead problems may happen as soon as January 19, 2008, when 30-year mortgages will start to be calculated by the financial industry.