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.)"
Chances are pretty good that you interact with 31-bit machines every day -- namely, older (pre-64-bit) IBM mainframes. Even the new zSeries machines frequently run apps in 31-bit mode for compatibility with older systems.
Using a couple of bits in an integer for data type is usually (in my experience) called 'tagged data.' I use it in Smalltalk VMs as an optimization -- the "objects" representing Integers are really just 31-bit integers with an extra zero-bit stuck on the LSB. (Object pointers have an LSB of 1, so you mask that to zero before using them and keep everything 16-bit aligned.)
Essentially what you wind up with there is a tradeoff: you can perform simple arithmetic and logic on the Integer "references" without actually having to allocate an object to hold an Integer, but you lose a bit of dynamic range. In my experience, it's an acceptable tradeoff, and it lets you have all the advantages of a true OO system without the performance penalty of having to use an object for, say, every loop variable.
So there's an example of why you do that. The aforementioned Smalltalk systems wouldn't be vulnerable to this date issue, however, as their integers will automatically convert themselves to arbitrary-precision numeric types as needed.
I've seen some comments about hey, another Y2K waste of time... blah blah blah. But think of it this way:
1 - What if all the money that was spent to "fix" the Y2K bug actually fixed the bug.
2 - Most people say that all the money spent "fixing" the Y2K bug was a waste because nothing happened.
3 - How many people have insurance of some sort, and have never needed it (I am). Yet every year, you renew your policies.
There are two things we can do about these "time" bombs. The first is to do nothing and hope that all is well. Or we could audit the code that may fail. A bit like paying insurance.
[ PS: it is SCO's code, so they should pay ]
it is only after a long journey that you know the strength of the horse.
[daleg@lithium]~>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
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
[daleg@lithium]~>uname -rs
SunOS 5.8
Interesting, it stays at the limit rather than rolling over.
2038 will be a big mess.
For the first programming job I had (at an insurance agency) they were using 9/9/99 as infinity. So, if your benefits mysteriously stopped a few years ago...hey, it wasn't my fault!
The most interesting time related bug I came across was with a RDBMS called Advanced Revelation. The program counted days from 1/1/1970. In May 1997 the sequence counter went from 4 to 5 digits. It was interesting, the database was stable, but there were quite a few reports and add ons that were designed to expect a 4 digit number.
BTW, I built a 3/3/3333 into a program that I wrote for a company.
> Okay -- I did the math, and 2^29 seconds since January 1st 1970 would have been up on January 4th, 1987. I remember that day - the Common Lisp system I was using (on a Sun) all of a sudden stopped recognizing when files were out of date and needed recompiling. Yup, they used a couple bits for a tag and then interpreted the rest as signed...
If we use Plank-Time and 256bit integers, we can handle 1.981384141637854Year*E+26. We should handle time as 256bit integer based on placktime and convert to local human time-standards as needed. We should support for a second 256bit imaginary integer and conversion to two floating point-math-units (one real and one imaginary) because some calculations in Physics involving time occur on the complex plain. I propose that zero-time be zero Julian Date.
Impeach Bush