Slashdot Mirror

← Back to Stories (view on slashdot.org)

Time's Up: 2^30 Seconds Since 1970

Posted by michael on 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.)"

104 of 675 comments (clear)

  1. Yay! by jargoone · · Score: 5, Funny

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

  2. Some systems... by NightSpots · · 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 be-fan · · Score: 4, Informative

      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...
    2. Re:Some systems... by Anonymous Coward · · Score: 5, Insightful

      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.

    3. Re:Some systems... by __past__ · · Score: 4, Informative
      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
      Indeed, someone did, sort of. Namely the implementors of the SBCL compiler (and they probably inherited it from CMUCL) who, generally, definitely do not qualify as stupid.
      "... and of course, CL transparently uses bignums when a numeric quantity exceeds the range of machine words, so we don't get overflow problems"
      * (decode-universal-time (+ (* 86400 365 50) (get-universal-time)))
      debugger invoked on condition of type TYPE-ERROR:
      The value 2635786389 is not of type (SIGNED-BYTE 32).

      This is because I didn't specify a timezone, so it asks unix for the default timezone and DST settings, and unix needs a time_t, which is 32 bits on this box.
      Dan Barlow, SBCL and the Y2038 problem

      So even if Lisp tends to not have overflow problems, Unix and C will come back and bite you if you give them a chance...
      --
      Programming can be fun again. Film at 11.
    4. Re:Some systems... by Anonymous Coward · · Score: 3, Funny

      People who use Excel on purpose need to be sterilized.

    5. Re:Some systems... by JamesOfTheDesert · · Score: 4, Funny
      Now, if you can explain why Excel users, and not Word or outLook users need to be sterlized, then go right ahead.

      Um, not to be quarrelsome or anything, but I'm not sure sure you'll find anyone here willing to make that distinction.

      Present company execpted, of course. :)

      --

      Java is the blue pill
      Choose the red pill
    6. Re:Some systems... by Piquan · · 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.

    7. Re:Some systems... by fucksl4shd0t · · Score: 3, Funny

      It was flame bait and I just wanted to post an educated rebuttal.

      Translation:

      It was flame bait, and I got baited.
      --
      Like what I said? You might like my music
  3. OH NO! by elite+lamer · · Score: 5, Funny

    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!

    --
    Oops!
    1. Re:OH NO! by HillBilly · · Score: 5, Funny

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

      --
      "Go into the hall of mirrors and have a bloody hard look at yourself" - HG Nelson
    2. Re:OH NO! by kurosawdust · · Score: 5, Funny
      I have to get bottled water and batteries ready!

      Calm down, man! Look, society might collapse or it might not - either way, that's no reason to down some kind of odd suicide cocktail.

    3. Re:OH NO! by operagost · · Score: 5, Funny

      Duct tape and WD-40... sounds like a redneck toolbox. Duct tape makes things stick, WD-40 makes them come apart. What else do you need?

      --

      Gamingmuseum.com: Give your 3D accelerator a rest.
    4. Re:OH NO! by JanusFury · · Score: 4, Funny
      What else do you need?
      A girlfriend?
      --
      using namespace slashdot;
      troll::post();
    5. Re:OH NO! by Feztaa · · Score: 4, Funny

      Duct tape makes things stick, WD-40 makes them come apart. What else do you need?

      Ok, you asked for it :)

      The only two tools a handyman will ever need are duct tape and WD40. If it moves but it shouldn't, use the duct tape; if it doesn't move but it should, use the WD40.

  4. so in other words.. by digital+bath · · Score: 3, Funny

    y2.003k?

    ...Run for the hills!

    --
    find / -name "*.sig" | xargs rm
    1. Re:so in other words.. by optikSmoke · · 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.

    2. Re:so in other words.. by Anonymous Coward · · Score: 4, Funny

      I love you. Seriously, and not the "I won't get it in your eye" type of love, this is the real thing.

  5. Yeah well... by twoslice · · Score: 4, Funny

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

    --

    From excellent karma to terible karma with a single +5 funny post...
    1. Re:Yeah well... by Roofus · · Score: 5, Funny

      You bought a Packard Bell too then huh?

  6. I thought we already rolled back to 1970's by Anonymous Coward · · Score: 5, Funny

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

  7. yawn by Anonymous Coward · · Score: 5, Funny

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

  8. RTFA by g-to-the-o-to-the-g · · Score: 3, Informative

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

    --

    Hi there

    1. Re:RTFA by cbiffle · · Score: 4, Informative

      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.

    2. Re:RTFA by Anonymous Coward · · Score: 5, Funny

      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?

    3. Re:RTFA by oGMo · · Score: 4, Informative
      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.)

      --

      Don't think of it as a flame---it's more like an argument that does 3d6 fire damage

    4. Re:RTFA by Anonymous Coward · · Score: 4, Funny

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

    5. Re:RTFA by Blkdeath · · Score: 3, Funny
      And you managed to spell "grammar" incorrectly...

      It's a long-standing rule of Fight-O-Net / UselessNet / Slice'n'DiceDot that when one attempts to correct the grammer or speling of another, invariably they themselves will make a misteak.

      If for no other reason, of course, than the fact it doubles the fun of language police.

      --
      BD Phone Home!

      Shameless plug. Like you weren't expecting it.

    6. Re:RTFA by Theatetus · · Score: 3, Funny
      misteak

      mmmm.... misteak....

      --
      All's true that is mistrusted
  9. I don't think there are 31-bit architectures by lkaos · · Score: 4, Insightful

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

    --
    int func(int a);
    func((b += 3, b));
    1. Re:I don't think there are 31-bit architectures by cbiffle · · 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.

    2. Re:I don't think there are 31-bit architectures by Anonymous Coward · · Score: 5, Informative

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

    3. Re:I don't think there are 31-bit architectures by Tom7 · · Score: 4, Informative

      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.

    4. Re:I don't think there are 31-bit architectures by boa · · Score: 5, Informative

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

    5. Re:I don't think there are 31-bit architectures by lkaos · · Score: 3, Informative

      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));
    6. Re:I don't think there are 31-bit architectures by Jamie+Zawinski · · Score: 3, Interesting

      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:

      • 00: odd int

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

  10. But Y2K hasn't even come yet... by Anonymous Coward · · Score: 5, Funny

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

  11. I fear to look... by Dreadlord · · Score: 4, Funny

    ...is 2.6 affected by the bug??

    --
    The IT section color scheme sucks.
  12. How many seconds you have left: by dagg · · Score: 5, Informative

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

    --
    Sex - Find It
    1. Re:How many seconds you have left: by Dahan · · Score: 4, Informative
      Isn't perl kinda big for that?

      $ echo seconds left: $(((1 << 30) - `date +%s`))

      (assuming your date(1) supports the %s extension)

    2. Re:How many seconds you have left: by Dahan · · Score: 3, Funny
      You don't find it unusual that no matter when you run your version that uses localtime, the answer is always 1073741824, which just happens to be 2**30?

      perl -we 'print "seconds left: ", ((2**30) - localtime), "\n"'
      Argument "Mon Dec 22 01:44:41 2003" isn't numeric in subtraction (-) at -e line 1.
      seconds left: 1073741824

      Not too Informative, if you ask me...

  13. OMG by Kludge · · Score: 5, Funny

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

    Holy shit.

    1. Re:OMG by Kludge · · Score: 3, Funny

      That's 1 quintillion nanoseconds!

    2. Re:OMG by tomstdenis · · Score: 3, Funny

      That wasn't very polite. Take it back or we're not friends anymore.

      Tom

      --
      Someday, I'll have a real sig.
    3. Re:OMG by fucksl4shd0t · · Score: 4, Funny

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

      Worse yet, you're in your 30s. Sorry, dude.

      --
      Like what I said? You might like my music
  14. Prepare for the Y10K Bug! by Anonymous Coward · · Score: 5, Funny

    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?

    1. Re:Prepare for the Y10K Bug! by Mr.+Slippery · · Score: 5, Insightful
      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:
      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?

      --
      Tom Swiss | the infamous tms | my blog
      You cannot wash away blood with blood
    2. Re:Prepare for the Y10K Bug! by Kohath · · Score: 5, Funny

      I don't know about you, but after 1/1/2000, I went back to using 2 digits.

  15. Re:subject by after · · Score: 3, Informative

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

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

  16. deja vu? by fatgraham · · Score: 5, Funny

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

  17. Y2K by KrispyKringle · · Score: 4, Funny
    I remember this. Talk about hype. I stumbled across a preparedness website a year or two later (one like this) 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.

  18. No sympathy for these guys by lurker412 · · Score: 3, Informative

    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.

  19. 31 bit architecture is very common by rdunnell · · Score: 3, Informative

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

  20. Did the math. by Yaztromo · · Score: 4, Informative

    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.

    1. Re:Did the math. by happyduckworks · · 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...

  21. Phew, my Newton's Safe! by scdeimos · · Score: 5, Funny

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

  22. I am not worried! by twoslice · · Score: 5, Funny

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

    --

    From excellent karma to terible karma with a single +5 funny post...
  23. Wrong writeup. by crapulent · · 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.

  24. does anybody else think... by teridon · · Score: 3, Interesting

    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
    1. Re:does anybody else think... by be-fan · · Score: 3, Insightful

      Argh! God I hate XML culture! How is this in any way better than a 64-bit integer???

      --
      A deep unwavering belief is a sure sign you're missing something...
  25. Gee that's small potatoes by Rosco+P.+Coltrane · · Score: 3, Interesting

    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
  26. ObCalculation by LaCosaNostradamus · · 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.]
    1. Re:ObCalculation by Bombcar · · Score: 4, Informative

      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
  27. A note about the "funnies" by fireman+sam · · 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.
    1. Re:A note about the "funnies" by lurker412 · · Score: 5, Informative
      I worked on a large Y2K program for a hospital chain. From what I observed, I can tell you this:

      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?

    2. Re:A note about the "funnies" by Kenja · · Score: 3, Insightful

      This is true of IT work in general. If you do your job, nothing happens and people think you're wsting time.

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
  28. Re:subject by DarkOx · · Score: 3, Interesting

    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
  29. Seriously, why can't we fix this damn thing now? by Anonymous Coward · · Score: 5, Insightful

    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.

  30. Are you a dog? by A+nonymous+Coward · · Score: 4, Funny

    Can you roll over?

    --
    Infuriate left and right
  31. For Example by Anonymous Coward · · Score: 3, Funny

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

  32. yup... by AntiTuX · · Score: 4, Informative

    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.

  33. Re:Seriously, why can't we fix this damn thing now by Yaa+101 · · Score: 3, Funny

    Nah, why take away the thrill and jobs of our childrens,childrens,childrens,childrens,childrens, childrens,childrens,childrens,childrens,childrens, childrens,childrens,childrens,childrens,childrens, childrens,childrens,childrens,childrens,children?

  34. different response on solaris 8 by E-Lad · · 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.

  35. rash of naughty dates coming by iggymanz · · Score: 5, Informative

    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

    1. Re:rash of naughty dates coming by Yaztromo · · Score: 4, Informative

      I'd like to add to that January 1st, 2032, which is when the date structure in older Macs and PalmOS devices will overflow.

      Yaz.

    2. Re:rash of naughty dates coming by chickenwing · · Score: 5, Funny

      Hmm, it seems that the date that a system's clock overflows is inversely proportional to the date that the system has outlived its usefulness

  36. mid life bug by Anonymous Coward · · Score: 5, Funny

    maybe a midlife crisis is just our internal clocks rolling over.

  37. Party Like Its 2037 by yintercept · · 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.

    1. Re:Party Like Its 2037 by grazzy · · Score: 5, Funny
      BTW, I built a 3/3/3333 into a program that I wrote for a company.

      That does NOT count as a sufficient documentation of the above feature!
    2. Re:Party Like Its 2037 by Reziac · · Score: 3, Funny

      At noon on December 31st, 2001, the Y2K fix for BlueWave (my offline BBS mail reader) stopped working. But only for one version. The Y2K fix still works with a slightly later version. Someone speculated that it was due to the older version being exactly n-many seconds old (from compile date) and at that point, some poorly coded function ran out of date space.

      Back in 1999, some BBS door functions stopped working, apparently due to running out of single-digit dates. *sigh*

      In the Closet I have a P90 that ever since Y2K, firmly believes the year is 2094. Oddly enough, NWDOS7 thinks this is a perfectly acceptable date!

      --
      ~REZ~ #43301. Who'd fake being me anyway?
  38. Ob COBOL Y2K joke by Anonymous Coward · · Score: 3, Funny

    There was once a COBOL programmer in the mid to late 1990s. He became a private consultant specializing in Year 2000 conversions. He was working 70 and 80 and even 90 hour weeks and travelled through 20 different countries, but it was worth it.

    Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. He must have suffered some sort of breakdown. Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. This was very expensive process and totally automated. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life.

    He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "It is over?" he asked. "Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?"

    The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. But the spokesman told Jack that he shouldn't get excited; someone important wanted to speak to him.

    Suddenly a wall-sized projection screen displayed the image of a man that remarcably looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That this was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reinstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.

    "That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in *me*?"

    "Well," said the Prime Minister. "The year 10000 is just around the corner, and it says in your files that you know COBOL...."

  39. This Only Hits 1 Company! Who Cares? by klausner · · Score: 3, Informative

    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.

  40. Re:subject by Anonymous Coward · · 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.

  41. Embedded systems by tepples · · Score: 3, Insightful

    Perhaps all time counters should be bignums?

    Bad idea. A "system to contain radioactive wastes" will usually be an embedded system with a fixed memory. Fixed-memory machines need fixed-size data structures, and a 64-bit count of seconds should hold even over lifetime-of-the-Universe or lifetime-of-copyright time scales.

  42. Oh no! Groundhog day! by meowsqueak · · Score: 3, Funny

    Nooooooo!!

  43. Use Planck-Time and 256Bit Integers by Walabio · · 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 · · Score: 4, Interesting

      This is a response to the first two replies

      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
    2. Re:Use Planck-Time and 256Bit Integers by Cl1mh4224rd · · Score: 3, Funny
      Planck-Time
      Plank-Time
      placktime
      Apparently there are some flaws with this method... Data degradation being the most obvious.
      --
      People will pass up steak once a week, for crap every day.
  44. Re:Seriously, why can't we fix this damn thing now by mabu · · Score: 3, Funny

    In case you haven't figured out, we are now a reactive society as opposed to proactive. We fix things, or usually replace them, when they break, not before. Americans don't think much about the future beyond what's on television later that day.

    Yes, we could fix the bug now. Likewise, we could also address world hunger, the deficit, the exploding crime problem, terrorism and a host of other issues with such cautious, preventative measures, but doing so wouldn't give us the instant gratification we desire now, so we'll let your children deal with the deficit, crime, terrorism, poverty, hunger and the time bug. We have better things to do. I'd write more, but I think "Friends" is coming on.

  45. 20 generations by 2034? by wackybrit · · Score: 4, Funny

    You expect to have twenty generations of descendents by 2034? Ooh ooh I got it! You're from Alabama, right?

    --
    mogorific carpentry experiments
  46. Actual figures here (in case you wanted to know) by RouterSlayer · · Score: 5, Informative

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

  47. I have one! by soloport · · Score: 5, Funny

    I shorted A31 to ground with a screwdriver on my Motorola MC68060 board. It blew a pullup resistor on an open collector output driver. Now A31 is always low -- and I'm too lazy to replace the tiny little 100 ohm surface mount. It runs just fine as long as I don't address high memory.

    I just want to know: Does that count?

  48. Salvation For Loveless Geeks? by shadowcabbit · · Score: 3, Funny

    A girl once told me she wouldn't go out with me until the end of time.

    Sally Roberts, pucker up.

    --
    "Why Subscribe?" Good question...
  49. Re:Umm, none? by tjb · · Score: 3, Interesting

    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

  50. When becometh Friday the Thirteenth by Skapare · · Score: 4, Informative

    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
  51. You, sir, are incorrect by siskbc · · Score: 5, Funny
    This is the biggest computer-related time event since Y2K, which begun on January 1, 19100!

    In standard /. fashion, I will overlook factual inaccuracies in the interest of pursuing my goal of correcting everyone's grammar. As such, I must tell you that Y2K *began* on January 1, 19100.

    --

    -Looking for a job as a materials chemist or multivariat

  52. Time is complex... by Goonie · · Score: 4, Informative
    Recording times accurately can get very complex in some cases, and longer time_t's aren't the whole solution.

    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?)
  53. Duh, it can! by multipartmixed · · Score: 4, Funny

    > I think it'd be much nicer if the language could handle Perl-style returning of arrays.

    The guy who posted above you 8 minutes earlier already understood the solution: return a damned pointer!

    Why, oh why, is this so hard to understand? Here, I will provide a contrived, stupid example.

    #define MIN_CHEST 25 /* waif, indeed! */
    #define MAX_CHEST 55 /* no jogging allowed */
    #define MIN_WAIST 19 /* guiness record */
    #define MAX_WAIST 65 /* doorway limitation */

    typedef enum { brown, blue, red, blonde, blue, cmax } colour_t;

    typedef struct
    {
    char *name; /* name of girl */
    size_t waist; /* diameter of waist */
    size_t chest; /* diameter of chest at most interesting offset */
    size_t hips; /* measure are the hips, don't get distracted, you naughty tailor */
    colour_t hair; /* it's good to hold on to! */
    colour_t eyes; /* if they can't see it, they can't suck it */
    } girl_t;

    typedef struct
    {
    size_t count;
    girl_t *girls;
    } girl_array_t;

    void mempanic()
    {
    write(STDOUT_FILENO, "oh oh\n", 6);
    _exit(1);
    }

    girl_t *createAllGirls()
    {
    girl_array_t *girlArr = calloc(sizeof(*girlArr), 1);
    char name[64];
    size_t waist, chest, hips;
    colour_t hair, eyes;

    if (!girlArr)
    mempanic();

    for (waist = MIN_WAIST; waist girls = realloc(girlArr->girls, sizeof(*(girlArr->girls)) * (girlArr->count + 1));
    if (!girlArr->girls)
    mempanic();
    sprintf(name, "chick #%i", girlArr->count + 1);
    girlArr->girls[girlArr->count].waist = waist;
    girlArr->girls[girlArr->count].chest = chest;
    girlArr->girls[girlArr->count].hips = hips;
    girlArr->girls[girlArr->count].eyes = eyes;
    girlArr->girls[girlArr->count].hair = hair;
    girlArray->count++
    }
    return girlArray;
    }

    There. Everything you need. A single return value, a dynamic sized array of structs. And girls.

    Of course, I didn't test it. But if you really need girls that bad, let me know and I'll make sure it builds.

    Now, this is just some text to avoid the lameness filter. Doo dah. Tobacco use during pregnancy increases the risk of preterm birth. abies born preterm are at an increased risk of infant death, illness and disability. Health Canada.

    L'usage du tabac pendant la grossesse accroit le risque d'un accouchement premature. Les bebes prematures font face a des risques plus grands de mort infantile, de maladies et d'incapacites. Sante Canada.

    Okay. Maybe I'll de-indent my code. Stupid piece of shit.Meta-control-Q should fix that.. Oh great! Now I need more characters per line. Comments, here I come...

    --

    Do daemons dream of electric sleep()?
  54. Re:Umm, none? by haxorest · · Score: 3, Funny
    Though a 2 bit computer would be rather limited.

    So just what kind of a two-bit operation are you running here?

  55. My Y2K Story (A little offtopic) by LouisvilleDebugger · · Score: 4, Funny

    The Y2K preparedness team at my company went crazy over the hype. They set up a big "Y2K Command Center" (commandeered a big teleconferencing room) with PCs full of nothing but Excel spreadsheets with all the functionality metrics for our whole enterprise painstakingly listed. Every ten minutes, all of us in the trenches were supposed to telephone this "command center" so they could update their spreadsheets (yes, web site "foobar" is still responding, yes, this database still works.)

    About 30 minutes before Y2K hit our time zone, I noticed the maintenance guys firing up the big diesel backup generators in our rear parking lot. I asked my boss about it. "Oh yeah," he said, "They're going to take us off the power grid just in case." No big deal to us: we have UPS's on all our PCs, and the power fails over all the time in the always-spectacular Kentucky summer thunderstorm season. (Half of the building's lighting turns off to conserve power, everyone slightly gasps, but keeps working...we're used to it.)

    But not so for the "Y2K Command Center." The "suits" had plugged all their spreadsheet-running PCs straight into the wall, and when we changed over to the generators (on their command) the momentary power drop caused *every single one* of their machines to go down....

    We laughed in their faces openly. If that's not being hoist by one's own petard I don't know what is. It almost made it worth it not to be kissing my sweetie on New Year's Eve.

  56. Orange Alert by Entropy_ajb · · Score: 5, Funny

    Maybe this is what the Orange Alert is about.....

  57. Are you sure about that? by vrt3 · · Score: 3, Informative
    http://lxr.linux.no/source/include/linux/types.h?v =2.0.39, line 57:
    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.
  58. Re:Not quite accurate by Dahan · · Score: 3, Interesting
    I'm just sayin', if you're going to try and be ultra accurate, then don't half-ass it.

    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)

  59. Already commercial failures on 1 billion seconds by waynemcdougall · · Score: 4, Informative
    Network Associate's (McAfee) Webshield product has already failed on the 1,000,000,000 second test. (In decimal - not a power of 2).

    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