Hey, Don’t despair cuz you don’t know Cobol.
Well C/C++ Programmers have something to look forward to now.
This week I got this email from my Manager.
After digging thru my C Manuals, I suspect what the email reads is more than true. Here goes :
Daniel Bossa
02/08/99 11:10 AM
To: Y2K - Administrators, Y2K - Authors, Y2K - Executives, Y2K - Internal
Systems, Y2K - Owners, Y2K - Readers, Y2K - Team MPower, Y2K - Team
Multipath, Y2K - Team Ops/Network/Service, Y2K - Team SMS,
cc:
Subject: Year 2038 bug ???
All Ready for 2000 and the Euro?
What About 2038?
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. Bafil 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. Bafil’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!)