The year 2038 Problem
By Tor Norbye on Apr 04, 2006
I usually never care about post dates, but the time event tonight is too symmetrical to miss:
01:02:03 04/05/06(This is assuming the American format where the month number is listed before the day number: hh:mm:ss mm/dd/yy.)
Remember back six years ago, when "millenium babies" were all the rage? People were trying to time it such that their babies would be born right at the turn of the millenium (and please don't post comments about millenium starting 1/1/2001, not 1/1/2000).
We didn't schedule our kids by desired birthdates, but my middle son ended up with an interesting birthdate anyway: 101000. Okay, I admit that the date is interesting in a very nerdy sense...
Time events like
Many unix systems use a millisecond counter to represent time. The designated begin time, zero on this counter, is January 1, 1970. Unfortunately, when older systems that still use 32 bit integers to hold this counter reach the magical moment when the bits all roll over, there's the potential for Bad StuffTM to happen. Which brings me back to another millenium craze: y2k. It was a giant flop - or a resounding success, depending on your perspective.
When we reach the millisecond timer limit in January of 2038, however, we've got a whole new set of challenges to look forward to: the y2.038k problem. And perhaps, lots of IT spending and OS upgrades. (64-bit Solaris uses 64 bits for time_t and has no year 2038 problem.) Here's more on the year 2038 problem.
And of course, year 2038 will bring a chance for truly nerdy parents to have a child with a birthdate of 0, when expressed in unix milliseconds, truncated to 32 bits. Take that, millenium babies!