Time's Up: 2^30 Seconds Since 1970

← Back to Stories (view on slashdot.org)

Time's Up: 2^30 Seconds Since 1970

Posted by michael on Sunday December 21, 2003 @11:59AM from the bzzzzzt dept.

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

13 of 675 comments (clear)

Min score:

Reason:

Sort:

Some systems... by NightSpots · 2003-12-21 12:00 · Score: 4, Interesting

And which systems are those?

Any of the common architectures use 29 bits instead of 31?

--

--
Use Vobbo for Video Blogs
1. Re:Some systems... by Piquan · 2003-12-21 18:40 · Score: 4, Interesting
  
  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 :)
  The Symbolics Lispms had wider words than PCs today. They used 36-bit words on the 3600s, with 4 bits of tag and 32 bits of data for numbers (or 8 bits of tag and 28 bits of data for pointers). They used 40-bit words on the Ivory, with 8 bits of tag and 32 bits of data for all types. So either way, the number is a 32-bit value. (This is why Lispms traditionally spec RAM in megawords, not megabytes.)
  That aside, like I mentioned in my other post, they said that all the date code is bignum-friendly anyway.
Wrong writeup. by crapulent · 2003-12-21 12:14 · Score: 4, Interesting

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.
Re:I don't think there are 31-bit architectures by cbiffle · 2003-12-21 12:15 · Score: 5, Interesting

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.
ObCalculation by LaCosaNostradamus · 2003-12-21 12:20 · Score: 4, Interesting

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.]
A note about the "funnies" by fireman+sam · 2003-12-21 12:22 · Score: 5, Interesting

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.
different response on solaris 8 by E-Lad · 2003-12-21 12:58 · Score: 5, Interesting

[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.
Party Like Its 2037 by yintercept · 2003-12-21 13:10 · Score: 5, Interesting

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.
Re:subject by Anonymous Coward · 2003-12-21 13:24 · Score: 4, Interesting

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.
Re:Did the math. by happyduckworks · 2003-12-21 13:31 · Score: 5, Interesting

> 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...
Use Planck-Time and 256Bit Integers by Walabio · 2003-12-21 13:33 · Score: 5, Interesting

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
1. Re:Use Planck-Time and 256Bit Integers by Walabio · 2003-12-21 16:51 · Score: 4, Interesting
  This is a response to the first two replies
  
  (#7783259) -- John Hasler
  
  (#7783200) -- Anonymous Coward
  
  John Hasler:
  
  Zero-time should be the instant of the Big Bang. By the time 256 bit cpus are standard we should know that accurately.
  
  I thought about zero-time being the big bang. I figured that since the big is not known very accurately, it would not be a good idea. On second thought, if we revise the time and the conversion-tables (something which is necessary anyway as the value of the Planck-Time-Unit (5.4*E-44)) with revision of the time of the big bang, it will work. If we use the time of the big bang, we will have to include the version of the revision along with the time stamp or else the text file from one year ago will show as from one billion years ago while the spreadsheet from 2000 AD, will not exist for two billion years.
  
  Anonymous Coward:
  
  (BTW, too bad I don't have some mod points to spend -- Planck units are the perfect rebuttal to those that claim the metric system is the best around)
  
  Natural units (Planck-Units) are best. After them, Metric Units are second best. One must remember that the metric system predates the discovery of Planck-Constants. The metric system has definite advantages over other previous systems:
  
  All units are interrelated
  
  The names of the prefixes are powers of ten
  
  It is an international standard
  
  Natural units are too small for practical everyday use. Metric units are in the convenient range for everyday use. Still, it is important to remember that metric units are arbitrary.
  
  Among my favorite arbitrary units is the byte, system for measuring memory:
  
  2^10
  
  This way, the amount of memory a computer can handle is always a round number (because the algorithms used for memory allocation, use binary mathematics). As an example, my filesystem can support files of upto 16 exobytes in size.
  --
  Impeach Bush
Re:so in other words.. by optikSmoke · 2003-12-21 14:51 · Score: 4, Interesting

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.