January 22nd, 2008 
admin Ahhh, remember the glory days of Y2K? I was all set to see the moon explode, power blackouts, and money flying out of ATMs. To say that Y2K was overstated is an understatement. Sorry, had to. Anyway, there is also a date issue in unix. And we’re just getting cranked up!
You see, dates after January 18, 2038 are going to present a challenge for the 32 bit time variable in Unix. Yeah, I know, your eyes are probably glazing over. Here’s Project 2038 to take the baton:
“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!”
Okay, so I can hear you saying already: “Paul, why in the world would I care? That year is a long time away!” Well, sorry to rain on your parade, but what about 30 year mortgage calculations? In fact, what about any type of time calculation that is 30 years from now? Yep, that date will fail. In fact, I just tested this on a Fedora Core system and it did in fact fail with Mon Jan 18 22:14:07 2038 – and ValueError: timestamp out of range for platform time_t. Run for your lives – it’s Y2K+38. The moon is going to explode!
Posted in 
