Forget Y2K, DST and Time Zones: this weekend, it’s the Y2.038K bug

This weekend will mark another interesting milestone in Time and Date, oone that actually doesn’t occur for thirty more years, in 2038.  

Also known as the ‘Friday the 13th’ bug, the 2038 issue is due to the way 32-bit systems note time in seconds rather than by an actual coded date.  The full impact will be felt on January 19, 2038, when systems many not work accurately, or even crash.  The initial wave of the challenge would likely impact customers in the financial sector, particularly those with (pardon the pun) an interest in long term products (mortgages, investments, bonds) with maturity dates post Jan 19, 2038.  But those with longer maturity instruments would’ve seen an impact years ago.

As this involves dates and times, Wyn asked today about this impact, as this smacked of an issue similar to what we saw last year with the various DST and time zone changes around the world… 

“I have not found too much on this and I am not sure if anything is know or being done to avoid the problem…”

Good question.  I asked several of our product groups if any of our products will be impacted by the date.

A nod of thanks to Geoff for noting this MSDN article from way back in 1998, “All Ready for 2000 and the Euro? What About 2038?” (September 7, 1998).  If Y2K did anything for the industry, it was to spur an analysis of any date and time issues that could impact the operating system and software products…

First it was Y2K. Then the Euro conversion. And now, as if the Y2K and Euro problems weren’t bad enough, there’s the year 2038 bug. Dr. GUI got a letter from Mahmoud Saleh alerting him (reminding him, actually) of a similar problem that will face C and C++ programmers in coming years: we can call it the Y2.038K bug.

The problem stems from the common definition of the time_t as an integer containing the number of seconds since midnight, January 1, 1970. Most C/C++ runtime libraries define time_t as a long int. On most systems, long int is 32 bits, which means that we’ve got a range of 2^31-1 (2,147,483,647) seconds—until sometime on January 18, 2038. (Assuming Dr. GUI’s Windows CE Palm-size PC has it right, that’s a Monday. Figures.) When the clock rolls over, it’ll be back to the ’70s for everyone. Get your leisure suits ready ‘cuz you’ll be catching Boogie Fever and Nixon will be President again. Four more years indeed!

Anything that uses time_t is also in trouble. That includes the time_b structure (not commonly used, anyway) and, very unfortunately, the MFC CTime class. Code that uses time_t, directly or indirectly, will need to be changed sometime before you start dealing with dates after 1/18/2038. (Note that if your program deals with, say, 40-year bonds, you’re in trouble today.)

As Geoff pointed out, SYSTEMTIME has no problems and can go until the year 30,827, and FILETIME, a 64-bit integer (two DWORDs representing LOW and HIGH values) since January 1, 1601 (Julian).  It too can represent a 30,000 (or 60,000 unsigned) year interval.  From the MSDN article:

…the Win32 SYSTEMTIME structure… stores the year part of the date as a 16-bit integer, and the Win32 FILETIME structure, which stores the date as the number of 100-nanosecond intervals since 1601. The problem is that neither of these structures have many supporting functions.

Better yet is to use the automation DATE object. DATE is typedef’ed as double, so there are 53 bits of precision—enough for your program’s lifetime. The whole part of the double number represents the number of days since midnight, December 30, 1899. (Negative numbers are before 12/30/1899.) The absolute value of the fractional part represents the time in the day: midnight is zero, noon is 0.5, etc. You can convert the automation DATE objects to other formats with various variant API functions.

Overall, the advice is that if you have custom applications you might want to check to see if they are using C/C++ time_t, which will run out in 2038.  Just as I noted previously on how Windows handles historical events, you might want to check any custom or ‘home-grown’ line of business applications that use time_t.  Looking quickly at Windows, the core OS appears to run just fine with dates far into the future. 

I will have to check one of my old Apple systems at home running (quite reliably, I might add) System 9, which according to Apple, is good up until February 6, 2040; the current Mac OS up until 29,940… Windows will be accurate for an additional 887 years after the latest Mac release fails, but I’m sure Apple will have an update long before 29,940 rolls around. 😉 

(Interesting factoid that stuck in my mind: in the H. G. Wells classic novella, The Time Machine, the hero of the story travels to the year 802,701 A.D.  I’m hopeful in that future, the downfall of mankind will have nothing to do with the failure of the modern OS to cope with dates past the 301st century.)

For more information, please see these articles courtesy of a quick MSDN search. 

Tags: Apple, Microsoft, Vista, Windows, Time, 2038.