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
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.
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.
> 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.
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.
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));
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...
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?)
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.
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