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.I expect this bug to cause serious problems on many platforms, especially Unix and Unix-like platforms, because these systems will “run out of time”. Starting at GMT 03:14:07, Tuesday, January 19, 2038, I fully expect to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system interruptions (including 911 emergency services), banking system crashes, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year 2038! Consider the year 2000 just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider that reports of temporal echoes of the 2038 problem are already starting to appear in future date calculations for mortgages and vital statistics! Just wait til January 19, 2008, when 30-year mortgages will start to be calculated.
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 rollover 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”. I have read unconfirmed reports that the rollover could even result in a system time of December 32, 1969 on some legacy systems!<
Embedded systems are most likely to be affected by the 2038 bug. Transportation systems from flight to automobiles increasingly use embedded systems. New airplanes contain advanced avionics such as inertial guidance systems and GPS receivers that also have considerable safety requirements. Another major use of embedded systems is in communications devices, including cellphones and internet appliances (routers, wireless access points, etc) which rely on storing an accurate time and date and are increasingly based on subsets of Unix (Android, Apple iOS, “light” versions of Linux etc).
As of 2010[update], most of these systems use 8/16 bit processors, even as desktop systems are transitioning to 64 bit systems. Despite the modern 18–24-month generational update in computer systems technology, embedded systems are designed to last the life of the machine they are built into. It is easily conceivable that some may still be in use by 2038. It is impractical (or in some cases impossible) to upgrade the software on these systems, so most will simply have to be replaced at significant cost.
The use of 32-bit
time_t has also been encoded into some file formats, which means it can live on for a long time beyond the life of the machines for which such file formats were originally designed.
Data structures with time problems
Many data structures in use today have 32 bit time representations embedded into their structure. A full list of these data structures is impossible to derive but there are well known data structures that have the Unix time problem.
- file systems (like many inode file systems still in use)
- data bases (that have 32 bit time fields)
- COBOL databases from the 1970s, 1980s and 1990s that have not been replaced by 2038 compliant SQL systems
- embedded factory, refinery control and monitoring subsystems
- assorted medical devices
- assorted military devices
Each one of these places where data structures using 32 bit time are in place have their own risks related to failure of the product to perform as designed.
There is no straightforward and general fix for this problem for existing CPU and operating system combinations, existing file systems, or existing binary data formats.
Changing the definition of
time_t data type to a 64-bit type would break some, but not all, binary compatibility for software, data storage, and may affect any code that deals with the binary representation of time.
time_t to an unsigned 32-bit integer, effectively allowing timestamps to be accurate until the year 2106, would affect programs that deal with time differences or dates before 1970, and thus would also break binary compatibility in many cases.
Most operating systems for 64-bit architectures already use 64-bit integers in their
time_t, and these operating systems are becoming more common, particularly in desktop and server environments. Using a (signed) 64-bit value introduces a new wraparound date that is over twenty times greater than the present age of the universe: approximately 292 billion years from now, on Sunday, 4 December 292,277,026,596.
Alternative proposals have been made (some of which are in use) including storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed-64 bit integer, providing a minimum of 300,000 years range. Other proposals for new time representations provide different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds.