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.)"
And which systems are those?
Any of the common architectures use 29 bits instead of 31?
--
Use Vobbo for Video Blogs
Could you be any MORE confusing? 2^30 is not 1 billion. It's 1,073,741,824. And the date as of right now is:
$ date +%s
1072051722
So, yes, there is an issue with the date overflowing a 30 bit space. I'd hardly say it's relevant, any software that made such a braindead choice (why 30 and not 32 bits?) deserves to break. But it has nothing to do with a billion or anything else related to base 10. It hit 1 billion a long time ago, and it was covered then.
that time should be stored as self-describing format, such as:
header containing:
2-bits (E) for # of bits for Epoch
1-bit for whether the time is a floating point format
if not floating, then:
2-bits (N) for # of bits for the time
2-bits (n) for # of bits for the resolution (1/2^n) (e.g. n=8 would mean 1/256 second resolution)
if floating, then follow some IEEE standard representation.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
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'm bracing for the 2034 Y2K (or is it Y2KATF) bug, the one that'll overflow the Unix time() function.
...
You think I'm trying to be funny ? well let's see : people were worried that systems built in the 80s and before would display the 99 Cobol date bug, and/or the 2-digit date bug in 2000. 1980 and before is 20+ years ago, and there weren't that many computers/microcontroller around during those 20 years compared to what's to come, and operating systems weren't very unified. Today in 2004, we have kajillions of Unix machines around : how much do you bet a lot of these will still be running 30 years from now ?
This said, I'm not bracing quite yet to tell the truth
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
2^30 = 1073741824s ~= 34y 9d 97m
1970JAN01 0000hr + (34y 9d 97m) ~= 2004JAN10 0137hr
January 10th should be an interesting day for somebody.
[You have a stable society when some nut guns down a schoolyard and the law doesn't change.]
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.
People did think this would happen eventually, iff thoses systems were still in operation. Nobody thought they would be still in operation. So it was thought safe to save on the memory. Remember that lots of these big old mainframes that sometimes have hundreds of terminals have less then 16megs of memory. I think it was not till 1960 that a computer was even build with that much ram and and it was common into the late 70's to have much less on big iron. Disk/tape capacitys were just as limited. Memory was EXPENSIVE and LIMITED that is why it was done the way it was.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
years.
When moderating, assume I have not yet had my coffee.
It seems like we will probably all be using 64bit computing by 2038 which will fix the problem itself. By then we won't have to worry for at least a few thousand years (I think).
I could of course be wrong but I'm pretty sure there aren't 31-bit architectures.
Right, but that doesn't necessarily dictate how the 32 bits of 32-bit architectures should work. I ran into a problem in a programming system that used 30-bit numbers when I tried to represent time as an int. The programming system wanted two bits of the int for itself (or maybe it was just one and the sign, can't remember).
-- The world is watching America, and America is watching TV.
[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.
Yes, you are the first person ever to understand this.
Try explaining to a manager, in 1978, why he should spend twice as much on a system so that it wouldn't fail sixty years hence.
http://maul.deepsky.com/~merovech/2038.html
mikebabu% 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
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
> 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
The point is that time() still returns a 32-bit value in both C and C++. That's the problem we're trying to solve here.
No, time() returns a time_t value. The C standard defines time_t as an arithmetic type capable of representing times; there's nothing in the standard that says it has to be 32 bits, or that it counts seconds from 1970-01-01, or even that it counts seconds. (I think POSIX imposes some more specific requirements, but it still allows a 64-bit type.)
I've worked on several systems that already use a 64-bit type for time_t. I suspect that all systems will do so well before 2038.
If the problem hasn't taken care of itself in 20 or 30 years, then we can start worrying about it.
(Switching to an unsigned 32-bit type would buy us another 68 years, but it would make it impossible to represent dates before 1970.)
What are the chances that we'll still be using the Gregorian calendar in Y10K?
Don't know about the Gregorian calendar, but there are other calendars like the Chinese and Hebrew calendars that are already in year 4000+. These probably will be around for Y10K relative to their starting dates.
One of the fun tricks you can do is use the bottom 2 bits for tagged data type, and then reserve two of those for immediate integers: one for even ints, and one for odd. That way, you get 3 tag types, with 30 bits of pointer, but you still get 31 bit integers instead instead of 30 bit. So the tags might look like:
01: even int
10: pointer to object header
11: pointer to array/string header
Then you convert raw data to an int with >>1, and to a pointer with &~3 (you only need 30 bits of pointer if all objects are word-aligned in a 32 bit address space.)
Lucid Common Lisp used this kind of system, and Lucid Emacs/XEmacs do something similar.
Im just more worried about the 0.0481298833079654997463216641 seconds after 2004...
Not to nitpick, but that would be 0.0481298833079654997463216641 years. And besides, your calculation is a little off because you appear to have used 365 days per year :).
How 'bout this:
2^30seconds / 60seconds/minute / 60minutes/hour / 24hours/day / 365.242199days/year = 34.025551925361years
34.025551925361years + 1970 = 2004.0255519254
0.0255519254years * 365.242199days/year = 9.3326414074074days
0.3326414074074days * 24hours/day = 7.9833937777782hours
0.9833937777782hours * 60minutes/hour = 59.003626666694
0.003626666694minutes * 60seconds/minute = 0.21760000161308seconds
OR, on January 9, 2004 at 07:59:00.21760000161308, the world will come to an end.
Approximately.
Yes you can. You can define a binary system with however many bits you like. It may not look pretty in a hexadecimal representation, but there's no reason you can't do it.
In fact, I work on a processor in which one engine has 20 bit words, another has 18 bit words, and another does multiplies out to 29 bits (15 bit x 14 bit).
Tim
UTC is a mess. I'd rather see all computer clocks use TAI (International Atomic Time) internally.
Mea navis aericumbens anguillis abundat
Recompiling everything is no big deal to Gentoo and *BSD people.
That's pretty much right. Just out of curiosity I tried recompiling everything on my FreeBSD system after changing the definition of time_t from int32_t to int64_t.
Surprisingly, everything works. I guess this is probably because it's already sometimes compiled for 64-bit architectures anyway.
Bah, you amateurs... the only proper way to represent a date/time is as an unsigned long long, signifying microseconds-since-epoch.
What do you do when you need to represent a date before the epoch?
Taking into account leap seconds:
env TZ=/usr/share/zoneinfo/right/GMT date -r 1073741823
Sat Jan 10 13:36:41 GMT 2004
Ignoring leap seconds:
env TZ=/usr/share/zoneinfo/posix/GMT date -r 1073741823
Sat Jan 10 13:37:03 GMT 2004
(BSD date's -r option is useful sometimes)