Time's Up: 2^30 Seconds Since 1970

An anonymous reader writes: "In Software glitch brings Y2K deja vu, CNET points out a small wave of Y2K-like bugs may soon hit, though it gets the explanation wrong. It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic). Systems that use only 29 bits of a word for unsigned/positive integers, or store time as seconds since 1970 in this format, may roll back to 1970. (Many systems that do not need full 32 bit integers may reserve some bits for other uses, such as boolean flags, or for type information to distinguish integers from booleans and pointers.)"

Comments

How many seconds you have left:

[dagg]

perl -e 'print "seconds left: ", ((2**30) - time), "\n"'

Re:I don't think there are 31-bit architectures

[Anonymous Coward]

Linux 2.0.x and 2.2.x use 31-bit time_t struct's.

Re:I don't think there are 31-bit architectures

[boa]

> I could of course be wrong but I'm pretty sure there aren't 31-bit architectures. At least, these architectures are exceedingly rare if they do indeed exist.

Of course you're wrong :-)
The IBM OS/390 and Z/OS operating systems, which run on most IBM mainframes, are both 31-bit.

Re:A note about the "funnies"

[lurker412]

I worked on a large Y2K program for a hospital chain. From what I observed, I can tell you this:

There were, in fact, many problems that were found and fixed before they did any harm.

A lot of infrastructure was upgraded on somewhat dubious claims of Y2K problems. In some cases, resetting the system clock once on 1/1/00 would have sufficed.

Consulting firms and contractors had a feeding frenzy. Some added value, others did not.

Many corporations were frightened by the prospect of lawsuits that might occur if they had Y2K problems. Lawfirms were licking their chops with anticipation.

As a result of all of the above, for the only time in recorded history CIOs could get whatever they wanted. Naturally, they played it safe. Wouldn't you?

rash of naughty dates coming

[iggymanz]

These might be a problem for many slashdot readers down the road, I for one plan on being likely dead, what with being old fart already. So here's those "overflow" dates, mm/dd/yyyy U.S.A. format:
02/06/2036 - systems which use unsigned 32-bit seconds since 01/01/1900
01/01/2037 - NTP time rolls over
01/19/2038 - Unix 32 bit time, signed 32 bit seconds (that's to say, 2^31) since 01/01/1970
02/06/2040 - Older Macintosh
09/17/2042 - IBM 370 family mainframe time ends, 2^32 "update intervals, a kind of 'long second'" since 01/01/1900
01/01/2044 - MS DOS clock overflows, 2^6 years since 01/01/1980
01/01/2046 - Amiga time overflows
01/01/2100 - many PC BIOS become useless
11/28/4338 - ANSI 85 COBOL date overflow, 10^6 days since epoch of 01/01/1601

and my personal favorite,
07/31/31086 - DEC VMS time overflows

Actual figures here (in case you wanted to know)

[RouterSlayer]

If you want to know what the real values are, this article and the one on cnet is wrong in so many ways... ugh, but here are the real ones that will really affect people:

FreeBSD 2.2.7 will start having this clock problem on January 18th, 2038 at 20:14 (8:14PM) EST when the unix clock on FreeBSD will read: 2147483640,
20:15 (8:15PM) EST will cause FreeBSDs clock timer to claim an invalid date... joy !

That's not 2^30 folks, that's 2^31 (2147483648) or about 8 seconds after the time I quoted above.

I know because we still have one box running 2.2.7 here (and what a fun box it is too!) can't handle more than 128megs of ram. What is this - the dark ages? that was rhetorical... :)