July 30, 2007

The Next Y2K is coming.

Ok, everyone who's been in IT for more than 7 years should remember the mass scramble to patch all of your systems by Jan 1, 2000. Dates stored with two-digit years prior to 2000 had a rollover effect as the years went from '99' to '00', possibly affecting math operations. History tells us that this created a few small problems in 2000, but for the most part, IT folks got ready for it and did a bang-up job making sure code was compliant and in working order by the millenium.
Only one problem - not all date/time is stored in plaintext in our systems. Nope, in fact, one heavily used storage mechanism for storing dates and times is storing the information in a rather larger unsigned integer that counts the number of seconds since January 1, 1970. Anyone who programs for Unix/Linux or other variants should instantly recognize this marker. Well, the timer is ticking, folks. That integer won't last forever. We're going to have some rollover in 2038 (early AM on January 19th). And that's only 21 years away.
Sure, you may not be a programmer 21 years from now, but you have a duty to save yourself from this coming catastrophe for your code. And if you're reading this, consider yourself warned.
If you're coding for a 64-bit system, perhaps the solution will be to write some helper methods that use a 64-bit counter that can be recoded once libraries are available for the date methods. This will save the maintenance time of looking through all of your code for the smaller integers later. Of course, using proper typing for your code is important too; using int when you meant to use time_t for example.
If you code, or support code that uses time functions based on the January date, take a look at your code now to ensure that it is ready to switch over to new methods or new sizes. 21 years may sound like a lot now, but the years will tick off sooner than you think.

No comments: