Tuesday, April 4, 2006

The year 2038 Problem

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.


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 1:2:3 4/5/6 are significant only in that they have
a nice ring to them. Just like the switch from 1999 to 2000: three digits
in the current year changed. In an absolute sense the event has no significance: it's
only a round number relative to the point we designated as time 0.
And let's not forget the historical fudging with the dates... take a look
at the source code for the GregorianCalendar class in java.util for example and
look for October 1582...
Or just cheat.



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!


No comments:

Post a Comment