A Diversion from elections: 2038 and the time_t problem

[Occulus]

First, the detailed explanation:

http://home.netcom.com/~rogermw/Y2038.html

Signed integers stored in a computer don't behave exactly like an automobile's odometer. When a 5-digit odometer reaches 99 999 miles, and then the driver goes one extra mile, the digits all "turn over" to 00000. But when a signed integer reaches its maximum value and then gets incremented, it wraps around to its lowest possible negative value. (The reasons for this have to do with a binary notation called "two's complement"; I won't bore you with the details here.) This means a 32-bit signed integer, such as a time_t, set to its maximum value of 2 147 483 647 and then incremented by 1, will become -2 147 483 648. Note that "-" sign at the beginning of this large number. A time_t value of -2 147 483 648 would represent December 13, 1901 at 8:45:52 PM GMT.

So, if all goes normally, 19-January-2038 will suddenly become 13-December-1901 in every time_t across the globe, and every date calculation based on this figure will go haywire.

And then the Wiki on the subject:

http://en.wikipedia.org/wiki/Year_2038_problem

Most operating systems for 64-bit architectures already use 64-bit integers in their time_t. The move to these architectures is already underway and many expect it to be complete before 2038. Using a (signed) 64-bit value introduces a new wraparound date in about 290 billion years. However, as of 2007, hundreds of millions of 32-bit systems are deployed, many in embedded systems, and it is far from certain they will all be replaced by 2038. Despite the modern 18- to 24-month generational update in computer systems technology, embedded computers may operate unchanged for the life of the system they control. The use of 32-bit time_t has also been encoded into some file formats, which means it can live on for a long time beyond the life of the machines involved.

I know this is an esoteric subject at this point, but- is this the REAL bug that the Y2K fiasco wasn't?

I've heard about this for several years, but have never seen it actually discussed. Consider this your golden opportunity. :D What do you think- will we all be using 64- or 128-bit software by that point (thus making this a nonissue for most), will something else have come along that eliminates this problem, or are nits just being picked here?

[RC]

1. I'll be 94 and if I'm still sucking air on my own then I probably won't care.

With all the Y2K B.S. about planes falling from the sky and coffee pots and microwaves not working and digital clocks running backwards and cars stopping in the middle of the street, I ain't gonna worry about something that is scheduled to happen in 30 more years.
2000 came and went and all the unpatched machinery with embedded computers, etc. still worked just fine because their internal clock was used to flip the flops, not keep track of time. The scare mongers will confuse the two yet again and rake in bazillions from the ignorant.

[DaveJ]

2. Interesting -- time_t never seemed 'right' to me, now I know why.

Turns out 32 bit time_t is depreciated though, so no more software or firmware should be written using it. (http://en.wikipedia.org/wiki/Time_t) We'll still be able to use 32 bit processors after 2038 that use the current double precision 64 bit value to represent time_t.

[CK_John]

3. Maybe our outsource partners will outsource some code work to us in 2037. It's

the software stupid. Can't get too far from the election.