Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Time's Up: 2^30 Seconds Since 1970

michael posted more than 10 years ago | from the bzzzzzt dept.

Programming 675

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

cancel ×

675 comments

Sorry! There are no comments related to the filter you selected.

these peoples try to fade me (-1)

(TK)Max (668795) | more than 10 years ago | (#7782360)

SLASHTREK, THE NEXT MASTURBATION
a screenplay from the library of Trollkore.

SCENE 1: ABOARD THE STARSHIP ENTERPRISE - A worried L.T. Commander Data addresses Captain Picard.

Data: Captain, sensors indicate a de-cloaking Slashdot ship one hundred meters off the starboard bow.

Picard: On screen!

Worf: Captain! We are dealing with a highly idiotic, ignorant and Linux-using species. They have been known to attack those who have superior social skills and official Microsoft qualifications in computer literacy out of fear and confusion - I recommend we attack them before they do us!

Picard: That is not the way the federation do things, Mr. Worf. When dealing with such mindless slashbots there is only one course of action to take. Ensign Wheaton hail the Slashdot ship.

Wheaton: Yes sir... but are these slashbots really so bad, according to my knowledge the open source community is a highly developed and sophisticated race of people - it would be unfair to discriminate against them just because of their foul stench and greasy complexion.

Picard: Shut up Wesley!!!

Data: The Slashdot ship has responded to our hail.

Picard: On screen.

--- Cut to a dark and lifeless ship, featuring posters of Kathleen Fent engaging in all manner of sexual acts upon the walls, with a barely visible silhouette of Michel Simms vigorously beating his cock in the background.

CMDRTACO: Captain, you are encroaching on our space, leave our territory at once and never return.

Picard: We are on an important scientific mission, studying a collapsing star - I can offer you goods in exchange for passage through your space.

CMDRTACO: -1, Redundant. You have nothing you can offer us... End Trans...

Picard: WAIT! I have... Goatse. [goatse.cx]

CMDRTACO: Then it is agreed, your safe passage through our space in exchange for the image. End Transmission.

--- The view screen turns off and TACO looks over to his first mate, CowboyNeal.

CMDRTACO: Put the image on main screen.... I wish to ejaculate.

Re:these peoples try to fade me (-1)

handybundler (232934) | more than 10 years ago | (#7782366)

nice werk!!!

Yay! (5, Funny)

jargoone (166102) | more than 10 years ago | (#7782362)

This is the biggest computer-related time event since Y2K, which begun on January 1, 19100!

The Grinch (0)

Anonymous Coward | more than 10 years ago | (#7782574)

Alternative headline:
PTC Steals Christmas for many in IT.

Some systems... (4, Interesting)

NightSpots (682462) | more than 10 years ago | (#7782367)

And which systems are those?

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

Re:Some systems... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7782391)

Where'd you get 29 from fool!

Re:Some systems... (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7782415)

can you fucking read?

Re:Some systems... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7782487)

can you fucking have some dignity and respect for my anonymous peer, you horribly untidy sack of maggot infested bladders. i mean, jesus christ.

Re:Some systems... (0, Informative)

Anonymous Coward | more than 10 years ago | (#7782408)

GNU/Linux prior to 2.2 series.

Re:Some systems... (4, Informative)

be-fan (61476) | more than 10 years ago | (#7782444)

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 :)

Re:Some systems... (5, Insightful)

Anonymous Coward | more than 10 years ago | (#7782545)

Well, they wouldn't just have the sense to use a bignum - they'd have the sense not to override the default behaviour of the damn language, which would be to go to bignum if necessary. It would take effort to write a declaration to actually deliberately override the behaviour, and would be A Seriously Stupid Thing To Do. Doesn't mean that somebody, somewhere wouldn't do it, of course, but it wouldn't be the "common case" that there would be a problem waiting to happen, like in C.

Re:Some systems... (0)

Anonymous Coward | more than 10 years ago | (#7782581)

uh, but what about the people that matter, the people with well paying jobs, the people that contribute to society, the people the use Excel?

Family Guy (-1, Offtopic)

tizen (697161) | more than 10 years ago | (#7782368)

Y2K?
Woah, since when did slashdot start posting stories about sex jelly?
Bonus: What would the icon be?
-tiz

OH NO! (5, Funny)

elite lamer (533654) | more than 10 years ago | (#7782371)

SOCIETY AS WE KNOW IT WILL COLLAPSE!!!! I have to get bottled water and batteries ready! This will be a complete disaster--just like Y2K!

Re:OH NO! (5, Funny)

HillBilly (120575) | more than 10 years ago | (#7782414)

You forgot the plastic sheets and duct tape. Don't forget to seal yourself in an airtight room.

Re:OH NO! (0, Redundant)

SpaceLifeForm (228190) | more than 10 years ago | (#7782564)

No, plastic sheets are the more modern stuff (Y2k+2).
Back in Y2k days, it was just duct tape and WD-40.

I am not worried! (5, Funny)

twoslice (457793) | more than 10 years ago | (#7782469)

I plenty left over from Y2K. For those who did not prepare for Y2K and laughed at all the suckers who stockpiled and hid in bunkers, Ha! I will finally have the last laugh! - going into my bunker now....

so in other words.. (3, Funny)

digital bath (650895) | more than 10 years ago | (#7782372)

y2.003k?

...Run for the hills!

Re:so in other words.. (1)

jargoone (166102) | more than 10 years ago | (#7782398)

Nah, more like "s1b".

Re:so in other words.. (1)

NeoThermic (732100) | more than 10 years ago | (#7782431)

Well, actualy, it would be y2.004k...

2^30 seconds --> years + 1970 = 2004.0481298833079654997463216641

Im just more worried about the 0.0481298833079654997463216641 seconds after 2004...

NeoThermic

Re:so in other words.. (1)

pjotrb123 (685993) | more than 10 years ago | (#7782449)

no, y2.004k!

Yeah well... (4, Funny)

twoslice (457793) | more than 10 years ago | (#7782377)

My two-bit computer ran out of time the moment it was turned on...

Re:Yeah well... (5, Funny)

Roofus (15591) | more than 10 years ago | (#7782627)

You bought a Packard Bell too then huh?

it's later than you think? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7782379)

never too late to fraternize dough?

secrets to online dating finally revealed? (Score:0)
by Anonymous Coward on Sunday December 21, @06:42PM (#7782274)
turns out the folks in the jump-you ads aren't really lonely, or geekIE, or members of robbIE's gnu dating 'service' at all?

robbIE serves US, right? (Score:mynuts won, you need a date buddIE?)
by Anonymous Coward on Sunday December 21, @08:53AM (#7778654)
after allowing/encouraging our owned domestic terrorist/payper liesense stock markup FraUD corepirate nazi softwar gangsters to attempt to take the whole wwworld as information/commerce hostages, to finance their greed/fear/ego based megalomania, it's not surprising that/how the wwworld is reacting.

BusinessWeak(tm) should have been reporting the fleecing of america, as well as the poteNTshill for wwworld reaction, at least 5 years ago.

lookout bullow. the ?pr? ?firms? are also preparing to 'outsource' the growing need for MiSleading hypenosys.

consult with/trust in yOUR creator... get ready to lighten up.

has anywon tried robbIE's gnu 'dating' service yet?

subject (1)

after (669640) | more than 10 years ago | (#7782381)

This seems interesting, but what systems do not use the FULL 32 bits to sore these numbers?

I would bet that if those systems did malfunction because of this, it would not do tons of harm - and upgrading wouldn't cost a cent.

Re:subject (3, Informative)

after (669640) | more than 10 years ago | (#7782432)

If this is a problem, then developers should start making ``patches'' for the year 2038 [deepsky.com] .

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 ... all I hope is that my body gets frozen so I can see that year ;)

Re:subject (3, Interesting)

DarkOx (621550) | more than 10 years ago | (#7782521)

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.

Re:subject (1, Informative)

Anonymous Coward | more than 10 years ago | (#7782520)

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 thought we already rolled back to 1970's (5, Funny)

Anonymous Coward | more than 10 years ago | (#7782384)

With some of the fashion's today (bell bottems, et al.)

yawn (5, Funny)

Anonymous Coward | more than 10 years ago | (#7782386)

this has been a problem since 1970. is it news that c-net realizes it?

RTFA (3, Informative)

g-to-the-o-to-the-g (705721) | more than 10 years ago | (#7782387)

The bug effects older unix systems. So if your still using UnixWare, you may be in trouble.

Re:RTFA (4, Informative)

cbiffle (211614) | more than 10 years ago | (#7782421)

Okay, I read TFA. Wrong.

The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.

It's fun to bash SCO and all, but come on.

Re:RTFA (4, Informative)

oGMo (379) | more than 10 years ago | (#7782554)

The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.

Actually, it's wrong in that POSIX states this value is signed, which is what causes it to be a problem we have to worry about before the next century. (If time_t was unsigned, various functions, such as time(2) could not return an error code. Similar deal happened with other types, such as size_t, which lead to the 2GB file problem for awhile.)

Re:RTFA (0)

Anonymous Coward | more than 10 years ago | (#7782612)

Not that it much matters, but were time_t unsigned, an error could still be signalled with -1; this would just be the largest value that a time_t could hold. That would reduce by one second the number of valid values a time_t could hold which isn't a huge deal.

But then, with an unsigned time_t, we couldn't store values before 1970.. :)

Re:RTFA (2, Informative)

drinkypoo (153816) | more than 10 years ago | (#7782580)

Also, UnixWare is a relatively new Unix featuring many newer concepts missing in SCO Unix, the actual product which geeks love to hate.

Re:RTFA (5, Funny)

Anonymous Coward | more than 10 years ago | (#7782451)

So if your still using UnixWare, you may be in trouble.

So that means Linux is affected also, since its mostly copied from Unixware, right?

Re:RTFA (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7782468)

So if your still using UnixWare, you may be in trouble.

Repeat after me 10 times:
  1. "your" should be "you're"
  2. "your" should be "you're"
  3. "your" should be "you're"
  4. "your" should be "you're"
  5. "your" should be "you're"
  6. "your" should be "you're"
  7. "your" should be "you're"
  8. "your" should be "you're"
  9. "your" should be "you're"
  10. "your" should be "you're"

Re:RTFA (4, Funny)

Anonymous Coward | more than 10 years ago | (#7782557)

Thanks for you're advice, which I will follow from now on.

Re:RTFA (0)

Anonymous Coward | more than 10 years ago | (#7782542)

affects! AFFECTS!!!

"Effect" means "to cause"; "affect" means "to influence".

Re:RTFA (0)

Anonymous Coward | more than 10 years ago | (#7782601)

Most people using SCO Unix are already in trouble, what with imminent bankruptcy of SCO and all.

Yeah, but most of us are fine... (1)

Anonymous Coward | more than 10 years ago | (#7782389)

Until, what, 2032, when the 32 bit unix timestamp hits the wall.

I don't think there are 31-bit architectures (4, Insightful)

lkaos (187507) | more than 10 years ago | (#7782396)

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.

What I believe this article is referring to is that some software may have been coded to use a bit in integers to store extra info. This seems like a pretty bad idea though as it would have all sorts of interesting effects on overflow and such. It would seem like it would only be useful to a very very very tiny portion of software since the overhead in using this method as a general purpose solution would be terribly difficult.

Sounds like it's just the story of yet another software bug...

Re:I don't think there are 31-bit architectures (1)

the_2nd_coming (444906) | more than 10 years ago | (#7782439)

yeah...like car computers and stuff like that :-)

31 bit architecture is very common (3, Informative)

rdunnell (313839) | more than 10 years ago | (#7782445)

in mainframes and other "big iron" in finance shops.

Re:31 bit architecture is very common (1)

lkaos (187507) | more than 10 years ago | (#7782477)

Do you have examples?

36 bit architectures are common. Of the mainframes I know of none are 31 bits...

Re:I don't think there are 31-bit architectures (5, Interesting)

cbiffle (211614) | more than 10 years ago | (#7782475)

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.

Re:I don't think there are 31-bit architectures (5, Informative)

Anonymous Coward | more than 10 years ago | (#7782490)

Linux 2.0.x and 2.2.x use 31-bit time_t struct's.

Re:I don't think there are 31-bit architectures (2, Interesting)

belarm314 (663118) | more than 10 years ago | (#7782593)

Fortunately, it would be rather trivial to convert those to 32-bit structs in the next
perl -e 'print ((2**31) - time)/(3600*24*365),"\n"'

34.102266457382
years.

Re:I don't think there are 31-bit architectures (4, Informative)

Tom7 (102298) | more than 10 years ago | (#7782500)

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.

Re:I don't think there are 31-bit architectures (5, Informative)

boa (96754) | more than 10 years ago | (#7782538)

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

But Y2K hasn't even come yet... (5, Funny)

Anonymous Coward | more than 10 years ago | (#7782401)

If 1K = 1024 then Y2K is 2048. We still have a ways to go on that one! :)

Re:But Y2K hasn't even come yet... (1)

nossid (652717) | more than 10 years ago | (#7782626)

Sorry, you are 4 years late [userfriendly.org] to really annoy people with that one.

I fear to look... (4, Funny)

Dreadlord (671979) | more than 10 years ago | (#7782407)

...is 2.6 affected by the bug??

Re:I fear to look... (1)

captaink (589612) | more than 10 years ago | (#7782458)

..you have got to be kidding. I seriously doubt it.

Re:I fear to look... (1)

Dreadlord (671979) | more than 10 years ago | (#7782483)

well, duh, of course I'm kidding...

Re:I fear to look... (1)

KrispyKringle (672903) | more than 10 years ago | (#7782471)

Um. Is this a joke? Did you RTFA?

Why do I even bother?

I WAS BORN IN 1973 (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7782419)

So, why the fuck would I care?

Those nasty 30-bit integers... (1)

bartwol (117819) | more than 10 years ago | (#7782420)

"Many systems that do not need full 32 bit integers may reserve some bits for other uses..."

NOT!

There are stories, there are non-stories, and finally, there are Slashdot stories.

Cool, I'll be five years old again. (0)

Anonymous Coward | more than 10 years ago | (#7782422)

This time I'll know all the answers on those darned school tests.

How many seconds you have left: (5, Informative)

dagg (153577) | more than 10 years ago | (#7782423)

perl -e 'print "seconds left: ", ((2**30) - time), "\n"'

Re:How many seconds you have left: (0)

Anonymous Coward | more than 10 years ago | (#7782595)

(Score:1, Troll)

What kind of retard moderator would call this post a troll?

OMG (5, Funny)

Kludge (13653) | more than 10 years ago | (#7782429)

I was born just before 1970.
I'm a billion seconds old.

Holy shit.

Re:OMG (1)

tomstdenis (446163) | more than 10 years ago | (#7782452)

Just think how many nanoseconds that is!!!

Tom

Re:OMG (3, Funny)

Kludge (13653) | more than 10 years ago | (#7782474)

That's 1 quintillion nanoseconds!

Are you a dog? (4, Funny)

A nonymous Coward (7548) | more than 10 years ago | (#7782571)

Can you roll over?

Prepare for the Y10K Bug! (5, Funny)

Anonymous Coward | more than 10 years ago | (#7782430)

How many of you programmers are storing your years using 4 digits? Yeah, that's what I thought, all of you. What happens when it's January 1, 10000? Hmmm? Yes, that's right, your software will fail. It will roll back to 0, which wasn't even a year!

Now, I know what you're thinking. "There's no way someone will be using software I'm writing 8000 years from now." Yeah, and that's what programmers said 30 years ago about the year 2000. Be smart, and play it safe. Use a 5, or better yet, 10 digit year. What's a few bytes?

Re:Prepare for the Y10K Bug! (1)

calyxa (618266) | more than 10 years ago | (#7782540)

The Long Now [longnow.org]

-calyxa

Re:Prepare for the Y10K Bug! (1)

Kirill Lokshin (727524) | more than 10 years ago | (#7782547)

Well, there has already been a solution proposed in RFC 2550 [faqs.org] , so there's nothing to worry about. On the other hand, 8000 years from now, changes in hardware (not only the actual machines, but also infrastructure like the power grid, preventing legacy hardware from being used) would probably have made most of today's software inoperable anyways.

Re:Prepare for the Y10K Bug! (1)

ChaoticLimbs (597275) | more than 10 years ago | (#7782573)

OH MY GOD I forgot about that!
Good thing I don't write programs that other people use!

Re:Prepare for the Y10K Bug! (1)

Trejkaz (615352) | more than 10 years ago | (#7782606)

If you're keen on storing a year as a separate integer you're fine anyway. 8 bits isn't enough even for 2003, and 16 bits is enough for 65,535.

Of course you'd be nuts to store dates as text.

Re:Prepare for the Y10K Bug! (5, Insightful)

Mr. Slippery (47854) | more than 10 years ago | (#7782614)

Be smart, and play it safe. Use a 5, or better yet, 10 digit year. What's a few bytes?
I wrote the following in the RISKS forum a few years ago [ncl.ac.uk] :
So maybe I'm an April Fool, but it seems to me that the Y10K issue is worth a little serious thought.

There are areas of human endeavor in which 8000 years is not an extreme time span. At present, we deal with these long time spans only in modeling things like geological and cosmological events. But it is not unreasonable that within the next century, we may begin to build very high technology systems with mission durations of thousands of years - for example, a system to contain radioactive wastes, or a probe to another star system.

Y2K issues have raised our consciousness about timer overflows, but it's quite possible that this may fade in succeeding generations. There's no reason not to start setting standards now.

Perhaps all time counters should be bignums?

deja vu? (5, Funny)

fatgraham (307614) | more than 10 years ago | (#7782437)

IIRC, bugger all went wrong. No nuclear weapons randomly fired off in any direction, no computers melted (well, none of mine)

Y2K (4, Funny)

KrispyKringle (672903) | more than 10 years ago | (#7782441)

I remember this. Talk about hype. I stumbled across a preparedness website a year or two later (one like this [qouest.net] ) and laughed my ass off. Talk about a throwback to 1999 (notice the animated gifs and scolling text in the status-bar that lend a real air of authority). I think I even e-mailed the writer and asked if he did't feel stupid now.

There was no reply, though. His computer probably thought my letter was from a century ago.

Re:Y2K (2, Insightful)

Anonymous Coward | more than 10 years ago | (#7782493)

If people hadn't worked to prepare for Y2K, it wouldn't have gone smoothly. There was a problem but it was largely fixed before it happened.

Re:Y2K (0)

Anonymous Coward | more than 10 years ago | (#7782567)

If you hadn't posted anon, you'd have been modded up.

No sympathy for these guys (3, Informative)

lurker412 (706164) | more than 10 years ago | (#7782442)

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.

Oooohhh... (0)

Anonymous Coward | more than 10 years ago | (#7782443)

So this is why John Titor traveled back in time!

John Titor [johntitor.com]

Did the math. (4, Informative)

Yaztromo (655250) | more than 10 years ago | (#7782446)

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.

Looks like they've got 19 days (1)

rubypossum (693765) | more than 10 years ago | (#7782453)

They've got about 19 days by my system clock.

jonathan@perl:~/dev/interface/lib$ perl -le 'print time();'
1072051517
jonathan@perl:~/dev/interface/lib$ perl -le 'print 2 ** 30;'
1073741824
jonathan@perl:~/dev/interface/lib$ perl -le 'print 2 ** 30 - time();'
1690288
jonathan@perl:~/dev/interface/lib$ perl -le 'print 1690288 / 60;'
28171.4666666667
jonathan@perl:~/dev/interface/lib$ perl -le 'print 1690288 / 60 / 60;'
469.524444444444
jonathan@perl:~/dev/interface/lib$ perl -le 'print 1690288 / 60 / 60 / 24;'
19.5635185185185

Heh, lots of ways of doing the same thing in Perl (0)

Anonymous Coward | more than 10 years ago | (#7782502)

For the less insane amongst us:

> perl -le 'print ((2 ** 30 - time()) / 60 / 60 / 24);';
19.5553587962963

Phew, my Newton's Safe! (5, Funny)

scdeimos (632778) | more than 10 years ago | (#7782454)

Its epoch is midnight 01-Jan-1904 and it uses an unsigned 32-bit integer to count seconds since then. That means it will run out at 06:28:15 09-Feb-2040.

But, I'm sure Apple will have released a new Newton by then! :P

(I don't suppose anyone's ported the Rosetta writing recognition system to other PDA's, just in case?)

i doubt much unix software is affected (1, Informative)

Anonymous Coward | more than 10 years ago | (#7782461)

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!

Wrong writeup. (4, Interesting)

crapulent (598941) | more than 10 years ago | (#7782470)

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. [slashdot.org]

does anybody else think... (3, Interesting)

teridon (139550) | more than 10 years ago | (#7782472)

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.

Re:does anybody else think... (2)

KrispyKringle (672903) | more than 10 years ago | (#7782516)

What would this solve? First, why would you want to store it as floating point? Floating point numbers incur a loss of precision that you don't want (because once the date gets pretty big, you won't be able to measure small time intervals--try it in C; if you add, say, 4.3 to four billion, you'll get four billion), and in fact instead of rolling over, floating point numbers reach ``infinity''. Second, this still limits the size to whatever your maximum is here (I'm not sure I understand your resolution thing--why measure in less than optimal resolution?). Third, there's no reason to make it, say, 33 bits. You may as well use the entire word, since the rest will probably be wasted, anyway.

what can we.. (0)

fabio (78385) | more than 10 years ago | (#7782476)

Possibly use this information for? as far as i understand, this only affects very old systems, and you oughta be just a little up to date!

i once read that UNIX would get troubles around 2038?

1 billion != 2^30 (2, Informative)

terremoto (679350) | more than 10 years ago | (#7782484)

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.

1000000000 second bug (1)

crow (16139) | more than 10 years ago | (#7782486)

A different, but related problem:

It was a while ago when we hit one billion seconds. There was some concern that this would cause bugs in programs that printed the time in seconds using only nine digits. Much like Y2K, I don't remember anyone talking about it afterwords as having caused real problems.

Re:1000000000 second bug (1)

DASHSL0T (634167) | more than 10 years ago | (#7782551)

[i]Much like Y2K, I don't remember anyone talking about it afterwords as having caused real problems.[/i]

Much like you didn't hear about people talking about their Y2K problems...because those that did have problems were [i]killed by the apocolyptic consequences[/i]! Their bodies are hidden in Roswell.

Kerching (1)

sgbaug (683688) | more than 10 years ago | (#7782488)

Hey isn't this another opportunity for outrageous consultants fees and inflated IT salaries? Imagine the repercussions if your CEO got stuck in the lift 'cause of a 29 bit integer. Not to mention all the Java toasters out there that'll need upgrading. Get out there and start billing!

Gee that's small potatoes (3, Interesting)

Rosco P. Coltrane (209368) | more than 10 years ago | (#7782491)

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

Great, now MS is going to start getting bitchy.. (1)

Lord Bitman (95493) | more than 10 years ago | (#7782503)

"our systems only have a Y2K bug every few thousand years!"

ObCalculation (4, Interesting)

LaCosaNostradamus (630659) | more than 10 years ago | (#7782505)

2^30 = 1073741824s ~= 34y 9d 97m

1970JAN01 0000hr + (34y 9d 97m) ~= 2004JAN10 0137hr

January 10th should be an interesting day for somebody.

Re:ObCalculation (2, Insightful)

Rick Richardson (87058) | more than 10 years ago | (#7782570)

$ date -d "1/1/70 `dc -e '2 30 ^p'` secs"
Sat Jan 10 13:37:04 CST 2004

A note about the "funnies" (5, Interesting)

fireman sam (662213) | more than 10 years ago | (#7782514)

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 ]

Water stock? (0)

Uplore (706578) | more than 10 years ago | (#7782532)

I'd better go stock up on water again in case everything falls apart then...

reserved bits? More probably... (1)

chtephan (460303) | more than 10 years ago | (#7782546)

More probably there will be problems with bit arithmetics like time 1 or something.

Seriously, why can't we fix this damn thing now? (5, Insightful)

Anonymous Coward | more than 10 years ago | (#7782569)

Seriously, could we please get started fixing this 2038 bug now? I don't know if it's practical to change time_t to "long long"; if not, could we at least officially define the successor to time_t?

I know that the emergence of 64-bit chips will alleviate this somewhat, but it wouldn't surprise me if at least embedded systems are still running 32-bits in 2038.

I know that "long long" is common, but it's not part of the official C++ standard yet. Shouldn't we be putting this in the standard now? It's not too much to require language libraries to have 64-bit integer support (if necessary). This doesn't have to be painful.

I'll feel a lot better the day that I know what I'm officially supposed to use instead of time_t -- or if I can be given a guarantee that time_t will be upgraded to 64 bits within the next few years.

For Example (3, Funny)

Anonymous Coward | more than 10 years ago | (#7782579)

Parametric Technologies has this problem [ptc.com] . Seems they were trying to insert the year 2038 bug into their code, but the messed up and got the year 2004 bug instead.

OT, but... what do you expect from CNet? (1, Offtopic)

Artifex (18308) | more than 10 years ago | (#7782609)

One of the headlines on the news.com.com home page is "Lost? Hiding? Your sell phone is keeping tabs."

If CNet doesn't even correct glaring spelling errors, how can anyone expect anything reliable from it?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?