Y2.038K bug

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.)

Since the number is signed, when the clock rolls over the time will be
a very large negative number, giving us a time warp of a little over
136 years-we'll flip back to sometime late in December, 1901. (Good
thing that time_t isn't a 31-bit unsigned number, or it would have
been back to the '70s for everyone. You'd have had to get your leisure
suits ready 'cuz you'd be catching Boogie Fever and Nixon would 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
18/1/2038. (Note that if your program deals with, say, 40-year bonds,
you're in trouble today.)