n. A computer software bug that will cause programs to cease functioning properly when confronted with dates in the year 2038 and beyond.
2008
So let's quickly examine another doomsday lurking in our not-so-distant future: that in 30 years' time, the internet will stop working. Or at least, the bits of it that run on Unix. (For once, this is a tale where Microsoft comes out looking well-prepared.)
This is down to what's being called the "2038 bug". It arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3.14am on January 19, 2038. (It's a Tuesday. Better make sure your desk is clean on the Monday night.)
This is down to what's being called the "2038 bug". It arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3.14am on January 19, 2038. (It's a Tuesday. Better make sure your desk is clean on the Monday night.)
2008
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.
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.
1999 (earliest)
Assuming, as expected, we survive the Y2K problem, another date-based computer problem is looming on the horizon. They're calling this one the Year 2038 bug.