The Year 2038 Problem

I came across this and found it very interesting,

by Roger M. Wilcox
last updated 23-October-2003

What’s so special about 2038?
Early UNIX programmers had quite a sense of humor.  In their documentation for the tunefs utility, a command-line program that fine-tuned the file system on the machine’s hard disk, a note at the end reads “You can tune a file system, but you can’t tune a fish.”  A later generation of UNIX authors, fearful that stuffy, humorless corporate drones would remove this cherished pun, added a programmer’s comment inside the documentation’s source code that read, “Take this out and a UNIX demon will dog your steps until the time_t’s wrap around!”

On January 19, 2038, that is precisely what’s going to happen.

For the uninitiated, time_t is a data type used by C and C++ programs to represent dates and times internally.  (You Windows programmers out there might also recognize it as the basis for the CTime and CTimeSpan classes in MFC.)  time_t is actually just an integer, a whole number, that counts the number of seconds since January 1, 1970 at 12:00 AM Greenwich Mean Time.  A time_t value of 0 would be 12:00:00 AM (exactly midnight) 1-Jan-1970, a time_t value of 1 would be 12:00:01 AM (one second after midnight) 1-Jan-1970, etc..  Since one year lasts for a little over 31 000 000 seconds, the time_t representation of January 1, 1971 is about 31 000 000, the time_t representation for January 1, 1972 is about 62 000 000, et cetera.

If you’re confused, here are some example times and their exact time_t representations:

Date & time                                time_t representation

---

1-Jan-1970, 12:00:00 AM GMT    0
1-Jan-1970, 12:00:01 AM GMT    1
1-Jan-1970, 12:01:00 AM GMT    60
1-Jan-1970, 01:00:00 AM GMT    3 600
2-Jan-1970, 12:00:00 AM GMT    86 400
3-Jan-1970, 12:00:00 AM GMT    172 800
1-Feb-1970, 12:00:00 AM GMT    2 678 400
1-Mar-1970, 12:00:00 AM GMT    5 097 600
1-Jan-1971, 12:00:00 AM GMT    31 536 000
1-Jan-1972, 12:00:00 AM GMT    63 072 000
1-Jan-2003, 12:00:00 AM GMT    1 041 379 200
1-Jan-2038, 12:00:00 AM GMT    2 145 916 800
19-Jan-2038, 03:14:07 AM GMT    2 147 483 647

By the year 2038, the time_t representation for the current time will be over 2 140 000 000.  And that’s the problem.  A modern 32-bit computer stores a “signed integer” data type, such as time_t, in 32 bits.  The first of these bits is used for the positive/negative sign of the integer, while the remaining 31 bits are used to store the number itself.  The highest number these 31 data bits can store works out to exactly 2 147 483 647.  A time_t value of  this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time.  So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program will reach its upper limit.

One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes.

---

What will the time_t’s do when this happens?

Signed integers stored in a computer don’t behave exactly like an automobile’s odometer.  When a 5-digit odometer reaches 99 999 miles, and then the driver goes one extra mile, the digits all “turn over” to 00000.  But when a signed integer reaches its maximum value and then gets incremented, it wraps around to its lowest possible negative value.  (The reasons for this have to do with a binary notation called “two’s complement”; I won’t bore you with the details here.)  This means a 32-bit signed integer, such as a time_t, set to its maximum value of 2 147 483 647 and then incremented by 1, will become -2 147 483 648.  Note that “-” sign at the beginning of this large number.  A time_t value of -2 147 483 648 would represent December 13, 1901 at 8:45:52 PM GMT.

So, if all goes normally, 19-January-2038 will suddenly become 13-December-1901 in every time_t across the globe, and every date calculation based on this figure will go haywire.  And it gets worse.  Most of the support functions that use the time_t data type cannot handle negative time_t values at all.  They simply fail and return an error code.  Now, most “good” C and C++ programmers know that they are supposed to write their programs in such a way that each function call is checked for an error return, so that the program will still behave nicely even when things don’t go as planned.  But all too often, the simple, basic, everyday functions they call will “almost never” return an error code, so an error condition simply isn’t checked for.  It would be too tedious to check everywhere; and besides, the extremely rare conditions that result in the function’s failure would “hardly ever” happen in the real world.  (Programmers: when was the last time you checked the return value from printf() or malloc()?)  When one of the time_t support functions fails, the failure might not even be detected by the program calling it, and more often than not this means the calling program will crash.  Spectacularly.

I don’t know, but I’m betting that every Microsoft operating system since Windows 95 uses this same scheme. Looks like people are going to be forced to upgrade from Windows 2000, Windows XP, and probably Vista, too.

I wonder if Linus  T. coded around this? Doubtful, because the whole idea was to be similar to the point of cloning.

This is definitely worse than the Y2K bug, that was taken care of by a BIOS or motherboard update, this one is a bit more pervasive.

-