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

RTFA

[g-to-the-o-to-the-g]

The bug effects older unix systems. So if your still using UnixWare, you may be in trouble.

Re:Some systems...

[Anonymous Coward]

GNU/Linux prior to 2.2 series.

Re:RTFA

[cbiffle]

Okay, I read TFA. Wrong.

The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.

It's fun to bash SCO and all, but come on.

How many seconds you have left:

[dagg]

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

Re:subject

[after]

If this is a problem, then developers should start making ``patches'' for the year 2038 [deepsky.com].

Its interesting, how no one considered this would happen eventually and just started to use 64 bit ints to store this from the long run.

Someday, we will hit a very high year, and these sort of problems will hit us as well ... all I hope is that my body gets frozen so I can see that year ;)

No sympathy for these guys

[lurker412]

The program in question was revised in 1997. Most companies already had kicked off their Y2K programs by then. The popular press was already starting to run end of the world warnings. OK, so it wasn't a Y2K problem as such, but how this company managed to ignore the problem at that time is truly baffling.

Re:Some systems...

[be-fan]

On many dynamically typed languages (notably Lisp) some of the bits of an integer are used as 'tag bits' that distinguish integers from pointers from cons cells, etc. Some bits are also sometimes used to help out the GC.

So maybe a Lisp Machine might have this problem? Of course, Lispers will tell you that they'd always have the sense to use a bignum :)

31 bit architecture is very common

[rdunnell]

in mainframes and other "big iron" in finance shops.

Did the math.

[Yaztromo]

Okay -- I did the math, and 2^29 seconds since January 1st 1970 would have been up on January 4th, 1987.

2^30 seconds since the epoch puts us into January 9th, 2004.

Yaz.

i doubt much unix software is affected

[Anonymous Coward]

I saw one minor problem with time()==10^9 where some logging put the time_t in a 9-digit area. That rollover happened in 2001.

The 2**30 rollover in January strikes me as pretty unlikely to affect much. Are there any commonly used 31-bit archs? (I think IBM s390 is but only for addressing, not data - please correct me if I'm wrong) In 18 years of working on UNIX software I don't think I've ever seen code to "cleverly" re-use the high bits on a time_t variable for something else.

Oh well, back to waiting for 2038. I should be retired by then, have fun kids!

1 billion != 2^30

[terremoto]

It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic).

My arithmetic says that 1 billion = 1,000,000,000 whereas 2^30 is 1,073,741,824.

The 1 billion rollover happened back in September 2001. The 2^30 rollover is in a few weeks time.

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

[Tom7]

It's not uncommon to use some extra bits for tags in implementations of some high-level languages. For instance, in SML/NJ the 'int' type is 31-bits long and signed; all integers are represented shifted up one bit and with a 1 in the new ones place. This is to distinguish them from pointers, which (since they are aligned) always end in two 0 bits. The arithmetic primops account for this extra bit, usually with very little overhead since the instructions are simple and can be paired. (Other SML compilers do it in different, sometimes better ways.) Anyway, fortunately they are not dumb enough to use 'int' to represent time, so there's no problem there! I expect there are lisp implementations that do similar things.

Re:subject

[Anonymous Coward]

well, lisp implementations sometimes have funny sized small integer word sizes, like 29 or 31 bits. But the way lisp works, it's not an issue, since such small ints are considered just "hardware acceleration" of commonly used numbers - lisps just go to bignums (arbitrary sized, implemented in software) when you exceed the size possible for a "tagged unboxed" representation. A programmer would have to try REALLY HARD to make a lisp implementation fail in this way, and even then it would be immediately apparent since he'd have had to make a declaration to override lisp default behaviour.

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:RTFA

[oGMo]

The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.

Actually, it's wrong in that POSIX states this value is signed, which is what causes it to be a problem we have to worry about before the next century. (If time_t was unsigned, various functions, such as time(2) could not return an error code. Similar deal happened with other types, such as size_t, which lead to the 2GB file problem for awhile.)

Re:RTFA

[drinkypoo]

Also, UnixWare is a relatively new Unix featuring many newer concepts missing in SCO Unix, the actual product which geeks love to hate.

yup...

[AntiTuX]

http://maul.deepsky.com/%7Emerovech/2038.html [deepsky.com]

antitux@TuX0r:~$ perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
antitux@TuX0r:~$

hrm..
Looks like we're fucked too.

Re:yup...

[AntiTuX]

Oh, and for those who care:

antitux@TuX0r:~$ uname -a
Linux TuX0r 2.6.0 #4 Sat Dec 20 18:38:44 MST 2003 i686 unknown unknown GNU/Linux
antitux@TuX0r:~$

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

Re:31 bit architecture is very common

[Meowing]

36 bit architectures are common. Of the mainframes I know of none are 31 bits...

36 bits was fairly common once upon a time, but no longer. Unisys still have a 36-bit series, but they're the last of the breed. See here. [36bit.org]

Big scary IBM boxes are where you see the 31 bit weirdness.

Re:Some systems...

[__past__]

they'd have the sense not to override the default behaviour of the damn language, which would be to go to bignum if necessary. It would take effort to write a declaration to actually deliberately override the behaviour, and would be A Seriously Stupid Thing To Do. Doesn't mean that somebody, somewhere wouldn't do it, of course

Indeed, someone did, sort of. Namely the implementors of the SBCL [sourceforge.net] compiler (and they probably inherited it from CMUCL [cons.org]) who, generally, definitely do not qualify as stupid.

"... and of course, CL transparently uses bignums when a numeric quantity exceeds the range of machine words, so we don't get overflow problems"

* (decode-universal-time (+ (* 86400 365 50) (get-universal-time)))
debugger invoked on condition of type TYPE-ERROR:
The value 2635786389 is not of type (SIGNED-BYTE 32).

This is because I didn't specify a timezone, so it asks unix for the default timezone and DST settings, and unix needs a time_t, which is 32 bits on this box.
Dan Barlow, SBCL and the Y2038 problem [gmane.org]

So even if Lisp tends to not have overflow problems, Unix and C will come back and bite you if you give them a chance...

Re:Yeah, but most of us are fine...

[dmobrien_2001]

Uh, you mean Tue Jan 19 03:14:08 GMT 2038, doncha?

Re:rash of naughty dates coming

[Yaztromo]

I'd like to add to that January 1st, 2032, which is when the date structure in older Macs and PalmOS devices will overflow.

Yaz.

This Only Hits 1 Company! Who Cares?

[klausner]

If you read the Cnet artlcle, this only affects software from a single company, and they are supposed to be "product lifecycle management" specialists. Why would anyone else care? The rest of us have until 2038 before there is a problem. Probably will get fixed in the 4.2 kernel.

Not if you have a 64 bit machine :)

[Anonymous Coward]

$ ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038
$ uname -mrs
Linux 2.4.9-40smp alpha
$ perl -v

This is perl, v5.6.0 built for alpha-linux

Copyright 1987-2000, Larry Wall

Re:How many seconds you have left:

[Dahan]

Isn't perl kinda big for that?

$ echo seconds left: $(((1 << 30) - `date +%s`))

(assuming your date(1) supports the %s extension)

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

[lkaos]

The IBM OS/390 and Z/OS operating systems, which run on most IBM mainframes, are both 31-bit.

They're actually 32-bit platforms but only are addressable by 31 bits. I believe they do arthimetic on 32 bits...

Re:Seriously, why can't we fix this damn thing now

[Anonymous Coward]

time() doesn't return a 32-bit value, it returns a time_t. The nature of a time_t is is implementation dependent.

Re:ObCalculation

[Bombcar]

Get the timezone right!

date -u -d "1/1/70 `dc -e '2 30 ^p'` secs"
Sat Jan 10 13:37:04 UTC 2004

See man date

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

Re:How many seconds you have left:

[Dahan]

No, it assumes a POSIX shell.

Re:RTFA

[Anonymous Coward]

Not a failure of C as such.. it could be avoided by using pointers instead of values and use the return value for success/failure reporting. It's all about the design.

Re:How many seconds you have left:

[naelurec]

Hmm.. no... you forgot a /60 (60 minutes in an hour)

so the correct answer would be ..

~0.0533 years ... which is ~19.45 days ..

Re:It's already happened.

[Helios292]

Reset your power manager (you can find out how for your specific model on Apple's site), and then leave your 'book to charge fully overnight. Probably just a corrupted pmu setting. It's happened before on mine and many of the ones I worked on back when doing Apple service.

the arithmetic?

[jqh1]

It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic).

It's not a billion seconds, it's 1,073,741,824 seconds -- right?

and we are close:

perl -e "print time();"
1072061932

1 365 day year is 60*60*24*365 = 31,536,000
seconds.

there are 8 leap years in there, and probably a few leap seconds, sure, but:

1,000,000,000 / 31,536,000 = 31.70979 years to hit 1 billion seconds.

1970 + 31.7 years puts us in September 2001. Randall Schwartz called this event U1E9 (unsigned 10 to the 9th power?) - there were a few glitches (mostly sorting related), but I've still got all my canned goods and batteries.

When becometh Friday the Thirteenth

[Skapare]

Actually UNIX is really using an effective 31 bits because of the fact that it defaults to a signed quantity, and hence the highest order bit is really a sign bit. So when the clock finally increments 0x7FFFFFFF (19 January 2038 03:14:07) to 0x80000000 the time will wrap back to 2,147,483,648 seconds before 1970, e.g. instead of being Tuesday 19 January 2038 03:14:08, it suddenly becomes Friday the Thirteenth (specifically Friday 13 December 1901 20:45:52).

Those systems that are using an unsigned 32 bit time value can go on until Sunday 7 February 2106 06:28:15.

If we were to switch to 64 bits, we could use a resolution of nanoseconds with all that extra space and still represent time until Friday 11 April 2262 23:47:16.854775807 before the sign bit becomes an issue (and negative values can represent time back to Tuesday 21 September 1677 00:12:43.145224192).

Re:How many seconds you have left:

[Anonymous Coward]

You should use "localtime" as time will always return the seconds left since 1970.

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

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

Time is complex...

[Goonie]

Recording times accurately can get very complex in some cases, and longer time_t's aren't the whole solution.

Firstly, every so often a leap second [wikipedia.org] is added to UTC. For this reason, over timescales of years it is impossible to exactly map unix time_t and calendar times.

Another issue is determining when a transaction happened that occurred across multiple time zones...

Re:so in other words..

[OwnedByTheMan]

...hence the use of "365.242199days/year" as opposed to 365.

Re:Phew, my Newton's Safe!

[Detritus]

The official explanation [apple.com].

Short version, it simplified leap-year calculations.

Re: Tag bits in integers

[some guy I know]

Not to be too pedantic or anything, but to use your shift right scheme for extracting integers, the second-to-LSB must be zero (naught) for even numbers, and 1 for odd numbers (in a two's comp machine).
So the tag bits have to be 00 or 01 for even integers and 10 or 11 for odd integers.

Some implementations of LISP go even further, using additional bits in the non-integer case.
For example:
0 - Upper 31 bits are signed integer (even or odd).
001 - Mask to get pointer to object, 8-byte aligned.
011 - Upper 29 bits are index into cons table.
101 - Upper 29 bits are index into string table.
111 - etc.

I seem to recall that Scheme, a LISP dialect, uses this type of tortuous mechanism to extreme extent.

Not quite accurate

[SoupaFly]

2^30seconds / 60seconds/minute / 60minutes/hour / 24hours/day / 365.242199days/year = 34.025551925361years

Actually, there are approximately 86,400.002 seconds in a day (see here [navy.mil]). In addition, you neglected to add the leap seconds that may or may not be required.

I'm just sayin', if you're going to try and be ultra accurate, then don't half-ass it.

Are you sure about that?

[vrt3]

http://lxr.linux.no/source/include/linux/types.h?v =2.0.39 [linux.no], line 57:
typedef __kernel_time_t time_t;

http://lxr.linux.no/source/include/asm-i386/posix_ types.h?v=2.0.39 [linux.no], line 21:
typedef long __kernel_time_t;

It's defined as a long for the other architectures as well. AFAIK a long is 32 bits on all platforms Linux 2.0.39 runs on.

Re:does anybody else think...

[vrt3]

I'm sorry but you're wrong. Floating point numbers have such a large range because the fact that their point is floating gives them dynamic precision. That means that small numbers are very precise, while large numbers have much less precision.

Think about it: a 32-bit floating point number can not possible have more different states than a 32-bit integer, yet it spans a much much larger range. It does so by sacrificing precision for large numbers.

Just try it:

#include <stdio.h>
int main(void)
{
float a = 4e9;
float b = 4.3;
printf("%f\t%f\t%f\n", a, b, a+b);
return 0;
}

Output:
4000000000.000000 4.300000 4000000000.000000

With doubles (64-bit floating point numbers) this example would work:

#include <stdio.h>
int main(void)
{
double a = 4e9;
double b = 4.3;
printf("%f\t%f\t%f\n", a, b, a+b);
return 0;
}

gives 4000000000.000000 4.300000 4000000004.300000

Re:ObCalculation

[Anonymous Coward]

Take 34 years from 1/1/1970 as an example. 34*365.25 = 12418.5 days. But that's wrong. We know the exact number of days which is: 34*365 + 8 = 12418. There are 8 leap years between 1970 and 2004. Notice that it is off by exactly 1/2 day. Oh, and It should be 365.2422 days per year. There are also 22 leap seconds in that time period.

Already commercial failures on 1 billion seconds

[waynemcdougall]

Network Associate's (McAfee) Webshield product has already failed on the 1,000,000,000 second test. (In decimal - not a power of 2).

This SMTP server stores the time to next retry sending a message but only the last 9 digits. So come mid 2001 Webshield would no longer retry sending a mail if the first attempt didn't work. Because it concluded it had been about 30 years since it last tried and it should give up about now.

There is a hot fix available, but this insidious problem only manifests itself if there is a problem at the receiving end so few people know they should upgrade and blame the recipient for mail that bounces immediately. Network Associates still provide software unpatched - hot fixes are only to be applied if you report he specific problem to be fixed.

If you use tempfailing [slashdot.org] (greylisting) as I do, then this immediately stuffs up any Webshield user trying to communciate with you because they will not retry after being given a temporary failure SMTP error code.

So if this example is anything to go by, then yeah, there'll be recent, modern commercial software that will fail (perhaps in non-obvious ways), with no fix available until after the event.

Re:Mod parent up

[dan_b]

Most systems are moving or have moved to 64 bit time_t, but that doesn't actually help because the compiled timezone data files which they're still using for timezone and DST lookup are still based on 32 bit quantities. At least, that was the case on my Linux Alpha box (until it died this morning. Need PSU)

The workaround we have in SBCL sucks more than slightly, to be honest. What we'll probably do at some point is get the source Olsen data ourselves and parse it into a form that doesn't throw useful information away quite as freely.