Slashdot Mirror
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.)"
The bug effects older unix systems. So if your still using UnixWare, you may be in trouble.
Hi there
GNU/Linux prior to 2.2 series.
perl -e 'print "seconds left: ", ((2**30) - time), "\n"'
Sex - Find It
If this is a problem, then developers should start making ``patches'' for the year 2038.
... all I hope is that my body gets frozen so I can see that year ;)
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
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.
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
A deep unwavering belief is a sure sign you're missing something...
in mainframes and other "big iron" in finance shops.
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 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!
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.
Linux 2.0.x and 2.2.x use 31-bit time_t struct's.
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.
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.
> 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.
http://maul.deepsky.com/%7Emerovech/2038.html
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.
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?
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
Programming can be fun again. Film at 11.
Uh, you mean Tue Jan 19 03:14:08 GMT 2038, doncha?
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.
$ ./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
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...
int func(int a);
func((b += 3, b));
time() doesn't return a 32-bit value, it returns a time_t. The nature of a time_t is is implementation dependent.
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
Fellowship 9/11
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...
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.
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.
who's moderating the meta-moderators?
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).
now we need to go OSS in diesel cars
Firstly, every so often a leap second 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...
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
...hence the use of "365.242199days/year" as opposed to 365.
Short version, it simplified leap-year calculations.
Mea navis aericumbens anguillis abundat
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.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Actually, there are approximately 86,400.002 seconds in a day (see here). 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.
typedef __kernel_time_t time_t;
http://lxr.linux.no/source/include/asm-i386/posix_ types.h?v=2.0.39, 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.
This sig under construction. Please check back later.
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:Output:
4000000000.000000 4.300000 4000000000.000000
With doubles (64-bit floating point numbers) this example would work:gives 4000000000.000000 4.300000 4000000004.300000
This sig under construction. Please check back later.
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.
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 (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.
Recycle PCs and build a wireless community network www.hillsborough.org.nz
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.