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

159 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 lightsaber1 · · Score: 2
      you're not George W. Bush are you?

      I swear, that guy...every time the U.S. economy looks as if it might start going again and get back on track, he decides to scare the shit out of his people...something wrong with that boy.

      That said, this might be a serious problem, but more likely not. It could actually be worse than Y2K since it didn't get as much focus and there could be some critical system chugging away somewhere and nobody knows about its troubles. But again, more likely not.

    5. Re:OH NO! by JanusFury · · Score: 4, Funny
      What else do you need?
      A girlfriend?
      --
      using namespace slashdot;
      troll::post();
    6. 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.

    7. Re:OH NO! by LordKronos · · Score: 2, Funny

      >Duct tape and WD-40...What else do you need?
      A girlfriend?

      What for? He's already got lubricant.

  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.

    3. Re:so in other words.. by OwnedByTheMan · · Score: 2, Informative

      ...hence the use of "365.242199days/year" as opposed to 365.

    4. Re:so in other words.. by HTH+NE1 · · Score: 2, Funny

      y1.957k.
      It's still 1024 for me no matter what SI says.

      Then go take a 1 km walk off a 1000 m pier.

      --
      Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
  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 drinkypoo · · Score: 2, Informative

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

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. 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.

    7. Re:RTFA by cpeterso · · Score: 2, Funny


      thank you Unix for combining data and error conditions into one convenient return value!

      --
      cpeterso
    8. Re:RTFA by Theatetus · · Score: 3, Funny
      misteak

      mmmm.... misteak....

      --
      All's true that is mistrusted
    9. Re:RTFA by unitron · · Score: 2, Funny
      Uh, no. 'Effect' means the result of some 'affection'.

      I thought it was pregnancy that was the result of some 'affection'.

      --

      I see even classic Slashdot is now pretty much unusable on dial up anymore.

    10. Re:RTFA by quantum+bit · · Score: 2, Funny

      The first rule of Fight-O-Net is: You do not talk about Fight-O-Net.
      The second rule of Fight-O-Net is: You do not talk about Fight-O-Net.

  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 belarm314 · · Score: 2, Interesting
      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.
      --
      When moderating, assume I have not yet had my coffee.
    6. Re:I don't think there are 31-bit architectures by pHDNgell · · Score: 2, Interesting

      I could of course be wrong but I'm pretty sure there aren't 31-bit architectures.

      Right, but that doesn't necessarily dictate how the 32 bits of 32-bit architectures should work. I ran into a problem in a programming system that used 30-bit numbers when I tried to represent time as an int. The programming system wanted two bits of the int for itself (or maybe it was just one and the sign, can't remember).

      --
      -- The world is watching America, and America is watching TV.
    7. 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));
    8. 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! :)

    1. Re:But Y2K hasn't even come yet... by Anonymous Coward · · Score: 2, Funny

      After consulting with marketing, the apocalypse has been moved up to 2K = 2000.

  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 civilizedINTENSITY · · Score: 2, Funny

      bash-2.05b$ perl -e 'print "seconds left: ", ((2**30) - time), "\n"' seconds left: 1686570 bash-2.05b$ octave GNU Octave, version 2.1.44 (i586-mandrake-linux-gnu). Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 John W. Eaton. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to . octave:1> 1686570/60/60/24 ans = 19.520

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

    3. Re:How many seconds you have left: by Dahan · · Score: 2, Informative

      No, it assumes a POSIX shell.

    4. Re:How many seconds you have left: by naelurec · · Score: 2, Informative

      Hmm.. no... you forgot a /60 (60 minutes in an hour)

      so the correct answer would be ..

      ~0.0533 years ... which is ~19.45 days ..

    5. 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 rampant+mac · · Score: 2, Funny
      Don't feel bad.

      It goes both ways.

      If your a Christian, you're, like, 15 minutes old.

      --
      I like big butts and I cannot lie.
    4. 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.

    3. Re:Prepare for the Y10K Bug! by balloonhead · · Score: 2, Funny
      You mean they'll be going for a pint after work?

      That's not a bad thing, unless you mean they'll be using those crazy american pints (12 Oz?) rather than proper wholesome British pints (16 Oz I think).

      --
      This idea was invented by Shampoo.
    4. Re:Prepare for the Y10K Bug! by the+eric+conspiracy · · Score: 2, Interesting

      What are the chances that we'll still be using the Gregorian calendar in Y10K?

      Don't know about the Gregorian calendar, but there are other calendars like the Chinese and Hebrew calendars that are already in year 4000+. These probably will be around for Y10K relative to their starting dates.

    5. Re:Prepare for the Y10K Bug! by Just+Another+Perl+Ha · · Score: 2, Interesting
      Bzzzt... wrong answer. Here's how it works:
      1 UK fluid ounce -> 28.41 ml
      1 US fluid ounce -> 29.57 ml

      1 UK pint -> 20 UK oz -> 568.3 ml
      1 US pint -> 16 US oz -> 472.3 ml
      From the above, I'd hasten to guess that you're either not American, not British or not a connoisseur of fine pints after work.
    6. Re:Prepare for the Y10K Bug! by quantum+bit · · Score: 2, Interesting

      Bah, you amateurs... the only proper way to represent a date/time is as an unsigned long long, signifying microseconds-since-epoch.

      What do you do when you need to represent a date before the epoch?

  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.

    1. Re:Y2K by Anonymous Coward · · Score: 2, Insightful

      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.

    2. Re:Y2K by InnovativeCX · · Score: 2, Funny

      Just for kicks, I decided to run the tool linked on that site. Turns out I'm in for some trouble (?).
      Output from my Windows notebook:

      Microsoft Windows XP [Version 5.1.2600]
      (C) Copyright 1985-2001 Microsoft Corp.

      C:\Documents and Settings\Scott>"C:\Documents and Settings\Scott\Desktop\y2k.exe "
      Y2K by Harlend Computer Services . Copyright (C) 1998-1999.

      This copy of Y2K has NOT been registered for installation.

      Checking your Windows configuration ...

      Testing the O/S clock ...
      Failed

      Testing the BIOS clock ...

      Good news! The BIOS in this PC will roll over properly into the
      New Millennium, and correctly recognises 2000 as a leap year.


      It seems that though this system, made in 2001 is just fine. Windows XP, with a service pack from just a few months ago, is still not Y2K compliant. Maybe this is the reason GoLive keeps crashing and my popcorn does not fully pop.
  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.

    1. Re:31 bit architecture is very common by Meowing · · Score: 2, Informative
      36 bit architectures are common. Of the mainframes I know of none are 31 bits...

      36 bits was fairly common once upon a time, but no longer. Unisys still have a 36-bit series, but they're the last of the breed. See here.

      Big scary IBM boxes are where you see the 31 bit weirdness.

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

    1. Re:Phew, my Newton's Safe! by Detritus · · Score: 2, Informative
      The official explanation.

      Short version, it simplified leap-year calculations.

      --
      Mea navis aericumbens anguillis abundat
  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 KrispyKringle · · Score: 2

      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.

    2. 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...
    3. Re:does anybody else think... by mcpkaaos · · Score: 2, Funny

      How is this in any way better than a 64-bit integer???

      Maybe because XML is easier to deal with in Visual Basic than 64 bit ints? =P

      --
      It goes from God, to Jerry, to me.
    4. Re:does anybody else think... by vrt3 · · Score: 2, Informative
      I'm sorry but you're wrong. Floating point numbers have such a large range because the fact that their point is floating gives them dynamic precision. That means that small numbers are very precise, while large numbers have much less precision.

      Think about it: a 32-bit floating point number can not possible have more different states than a 32-bit integer, yet it spans a much much larger range. It does so by sacrificing precision for large numbers.

      Just try it:
      #include <stdio.h>
      int main(void)
      {
      float a = 4e9;
      float b = 4.3;
      printf("%f\t%f\t%f\n", a, b, a+b);
      return 0;
      }
      Output:
      4000000000.000000 4.300000 4000000000.000000

      With doubles (64-bit floating point numbers) this example would work:
      #include <stdio.h>
      int main(void)
      {
      double a = 4e9;
      double b = 4.3;
      printf("%f\t%f\t%f\n", a, b, a+b);
      return 0;
      }
      gives 4000000000.000000 4.300000 4000000004.300000
      --
      This sig under construction. Please check back later.
  25. 1 billion != 2^30 by terremoto · · Score: 2, Informative

    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.

  26. 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
  27. 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 Rick+Richardson · · Score: 2, Insightful

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

    2. 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
    3. Re:ObCalculation by soulsteal · · Score: 2, Funny

      How fitting that the time of a crash would be L337.

      I mean 13:37.

  28. 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?"
  29. 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
  30. 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.

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

    Can you roll over?

    --
    Infuriate left and right
  32. 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.

  33. Fixed In Time by Ashcrow · · Score: 2, Interesting

    It seems like we will probably all be using 64bit computing by 2038 which will fix the problem itself. By then we won't have to worry for at least a few thousand years (I think).

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

    1. Re:yup... by AntiTuX · · Score: 2, Informative

      Oh, and for those who care:

      antitux@TuX0r:~$ uname -a
      Linux TuX0r 2.6.0 #4 Sat Dec 20 18:38:44 MST 2003 i686 unknown unknown GNU/Linux
      antitux@TuX0r:~$

    2. Re:yup... by Lord+of+Ironhand · · Score: 2, Funny

      > http://maul.deepsky.com/%7Emerovech/2038.html

      That page is worth visiting for the disclaimer alone:

      "PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this Web page, in any manner whatsoever, will increase the amount of disorder in the universe. Although no liability is implied herein, the consumer is warned that this process will ultimately lead to the heat death of the universe."

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

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

  37. So.... by Coppit · · Score: 2, Funny

    So does this mean we can sue SCO if our systems crash?

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

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

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

  40. Re:Yeah, but most of us are fine... by strange_harlequin · · Score: 2, Funny

    Nah... no way will any of these systems still be in use in 30 years time...

  41. 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?
    3. Re:Party Like Its 2037 by Baki · · Score: 2, Interesting

      At the moment we are using 31-dec-9999 as infinity (the max date Oracle can represent). I think chances are pretty slim that todays systems are still running in 9999.

    4. Re:Party Like Its 2037 by MonkeyBoy · · Score: 2, Funny

      NWDOS7 thinks it's a perfectly acceptable date, but is secretly wondering why you're still using it on a P90 in 2094.

      --

      Moof!

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

  43. Re:Yeah, but most of us are fine... by dmobrien_2001 · · Score: 2, Informative

    Uh, you mean Tue Jan 19 03:14:08 GMT 2038, doncha?

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

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

  46. Time stops for OS X by shking · · Score: 2, Interesting
    Don't know if the problem is OS X 10.2.8 or Perl 5.6, but time just stops at Jan 19 03:14:07 2038 on my mac

    http://maul.deepsky.com/~merovech/2038.html

    mikebabu% perl 2038.pl
    Tue Jan 19 03:14:01 2038
    Tue Jan 19 03:14:02 2038
    Tue Jan 19 03:14:03 2038
    Tue Jan 19 03:14:04 2038
    Tue Jan 19 03:14:05 2038
    Tue Jan 19 03:14:06 2038
    Tue Jan 19 03:14:07 2038
    Tue Jan 19 03:14:07 2038
    Tue Jan 19 03:14:07 2038
    Tue Jan 19 03:14:07 2038

    --
    -- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
  47. 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.

  48. Testing? We don't need no stinking testing! by coleca · · Score: 2, Funny

    "It's such a simple flaw; we don't believe it requires extensive testing to deploy the patches," he [PTC spokesman Joe Gavaghan] said.

    That's an excellent plan! Nothing bad has ever come from that train of thought before.

    In future news, PTC spokesman Joe Gavaghan is now working for Microsoft's Security division.

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

    Nooooooo!!

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

  52. Re:Seriously, why can't we fix this damn thing now by kst · · Score: 2, Interesting

    The point is that time() still returns a 32-bit value in both C and C++. That's the problem we're trying to solve here.

    No, time() returns a time_t value. The C standard defines time_t as an arithmetic type capable of representing times; there's nothing in the standard that says it has to be 32 bits, or that it counts seconds from 1970-01-01, or even that it counts seconds. (I think POSIX imposes some more specific requirements, but it still allows a 64-bit type.)

    I've worked on several systems that already use a 64-bit type for time_t. I suspect that all systems will do so well before 2038.

    If the problem hasn't taken care of itself in 20 or 30 years, then we can start worrying about it.

    (Switching to an unsigned 32-bit type would buy us another 68 years, but it would make it impossible to represent dates before 1970.)

  53. 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
  54. Re:Damn... by kiwirob · · Score: 2, Funny

    I used to do a bit of COBOL, but also have cut my teath with a few years experience with S370 Assembler. I could probably earn good money with that too. But I'm not sure i WANT to!!!

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

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

  57. Re:It's already happened. by Helios292 · · Score: 2, Informative

    Reset your power manager (you can find out how for your specific model on Apple's site), and then leave your 'book to charge fully overnight. Probably just a corrupted pmu setting. It's happened before on mine and many of the ones I worked on back when doing Apple service.

  58. Actually... by Kjella · · Score: 2, Insightful

    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.

    Well, considering how it was the 70s, the change of the millennium seemed ages away, 32 bit seemed a *lot* of memory back in those days. Think a small database with 64 vs 32 bit timestamps. My dad used to work in IBM way back, and I remember he's told me about a printing company which turned down getting another mb of mainframe memory from them, because it'd cost them $150,000. That's 50 cents extra per date.

    If I remember my history right, it was one of the Apple developers that in the design process cut two digits from the year, in order to save memory. Since they were trying to make a consumer product (or at least consumer-priced product), even more work went into minimizing cost. This was also in the 70s. The IBM PC just copied that system.

    Today, it seems utterly stupid to not double it. Just understand that today the machines have literally thousands of times more RAM than they used to. It was a real scarce resource, where every bit counted. Nobody was thinking of year 2038, they were thinking of how this would improve performance right here and now. Also at the time, computers were mostly big mainframes, with pretty much specialists and geeks. So they probably thought it'd be easy to fix when the issue arised.

    That they were mostly unable to foresee the explosion of a) the personal computer, b) the Internet and c) embedded electronics before the end of the millenium, is hardly anything you can blame them for. It wasn't really until near the very end of the millennium that people really understood the magnitude of the task. That's why the y2k-problem became such a big thing, if it had been some mainframes in a computer lab somewhere, noone would have lifted an eyebrow. It was that "the computers are everywhere, in all offices, they'll all go to hell, and society will collapse" which made it big. At which point it was a little late to fix the underlying format, since so much code relied on it being of that type.

    So if there was a time, it'd have to be the middle time... after memory got "cheap", before too much code started to rely on it. It's hard to say if such a period even existed. And even if it did, I'm sure 99,9% of the people would have wondered why the fsck you need to fix that issue NOW. The old system works, and will work for many years yet (like, long past the life time of this PC. We can fix it in the next one). Don't knock it if it works, right? So I find it quite natural it turned out the way it did, no matter how smart people were.

    Kjella

    --
    Live today, because you never know what tomorrow brings
  59. the arithmetic? by jqh1 · · Score: 2, Informative

    It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic).

    It's not a billion seconds, it's 1,073,741,824 seconds -- right?

    and we are close:

    perl -e "print time();"
    1072061932

    1 365 day year is 60*60*24*365 = 31,536,000
    seconds.

    there are 8 leap years in there, and probably a few leap seconds, sure, but:

    1,000,000,000 / 31,536,000 = 31.70979 years to hit 1 billion seconds.

    1970 + 31.7 years puts us in September 2001. Randall Schwartz called this event U1E9 (unsigned 10 to the 9th power?) - there were a few glitches (mostly sorting related), but I've still got all my canned goods and batteries.

    --
    who's moderating the meta-moderators?
  60. 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...
  61. 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

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

    1. Re:You, sir, are incorrect by stephens_domain · · Score: 2, Funny

      You want to correct everyone's grammar on slashdot?

      I've heard some lofty goals, but this goes to a whole new level.

      --

      ..
    2. Re:You, sir, are incorrect by Smelly+Jeffrey · · Score: 2, Insightful

      Y2K began on January 1, 19101

      Let:
      Y2K == "year two-thousand"
      19100 == 2000
      19101 == 2001.

      You mean to tell me that the "year two-thousand" began on January 1, 2001?

  64. 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?)
  65. 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()?
  66. 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?

  67. TAI by Detritus · · Score: 2, Interesting

    UTC is a mess. I'd rather see all computer clocks use TAI (International Atomic Time) internally.

    --
    Mea navis aericumbens anguillis abundat
  68. Re:subject by quantum+bit · · Score: 2, Interesting

    Recompiling everything is no big deal to Gentoo and *BSD people.

    That's pretty much right. Just out of curiosity I tried recompiling everything on my FreeBSD system after changing the definition of time_t from int32_t to int64_t.

    Surprisingly, everything works. I guess this is probably because it's already sometimes compiled for 64-bit architectures anyway.

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

  70. Re: Tag bits in integers by some+guy+I+know · · Score: 2, Informative

    Not to be too pedantic or anything, but to use your shift right scheme for extracting integers, the second-to-LSB must be zero (naught) for even numbers, and 1 for odd numbers (in a two's comp machine).
    So the tag bits have to be 00 or 01 for even integers and 10 or 11 for odd integers.

    Some implementations of LISP go even further, using additional bits in the non-integer case.
    For example:
    0 - Upper 31 bits are signed integer (even or odd).
    001 - Mask to get pointer to object, 8-byte aligned.
    011 - Upper 29 bits are index into cons table.
    101 - Upper 29 bits are index into string table.
    111 - etc.

    I seem to recall that Scheme, a LISP dialect, uses this type of tortuous mechanism to extreme extent.

    --
    Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
  71. Orange Alert by Entropy_ajb · · Score: 5, Funny

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

  72. Not quite accurate by SoupaFly · · Score: 2, Informative
    2^30seconds / 60seconds/minute / 60minutes/hour / 24hours/day / 365.242199days/year = 34.025551925361years

    Actually, there are approximately 86,400.002 seconds in a day (see here). In addition, you neglected to add the leap seconds that may or may not be required.

    I'm just sayin', if you're going to try and be ultra accurate, then don't half-ass it.

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

    2. Re:Not quite accurate by PacoCheezdom · · Score: 2, Funny

      13:37 in the afternoon, huh?

      Saturday, January 10, some big iron datacenter in Silicon Valley
      Tech: What's this? ERROR 2393: HAXX0rS HAEV STOELN YUOR MEGAHURTZ!


      I love you Jeff K.

  73. Pure nonsense! by AvantLegion · · Score: 2, Funny
    What a crock. I'm on an old UNIX machine and nothi.......

  74. 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.
  75. 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
  76. The end of the world by Handyman · · Score: 2, Funny

    I remember talking to a friend who tried to convince me that the earth was going to end somewhere in 2001. Why? Well, it's very simple. The number of the beast is 666, multiply that by three (there was a reason for that too -- not sure what it was, but it was biblical as well). That gives you 1998, and that's the number of years after the birth of Christ that the world is going to end. However, he told me, Jesus Christ wasn't born exactly on the first day of year one, he was actually born somewhere around 3 B.C., so that meant that the end of the world was going to take place in 2001.

    This conversation took place somewhere in the year 2000. He was not very pleased to hear that if he were right, the world would already have ended 5 years ago. :)

  77. Re:subject by Lemmeoutada+Collecti · · Score: 2, Insightful

    Aha, you see, it compiled. But have you tested every function and routine to make sure no programmer assumed a x bit integer? Or based calculations on the rollover shortcut? Or required a 32 bit integer for certain time calculations? Mere compilation is not enough to ensure accurate and correct operation of all programs.

    Personally, I would have more concerns about the stability of the recompiled system than the 32 bit time based one at this point.

    --

    You can have it fast, accurate, or pretty. Pick any 2.
  78. Re:Mod parent up by dan_b · · Score: 2, Informative

    Most systems are moving or have moved to 64 bit time_t, but that doesn't actually help because the compiled timezone data files which they're still using for timezone and DST lookup are still based on 32 bit quantities. At least, that was the case on my Linux Alpha box (until it died this morning. Need PSU)

    The workaround we have in SBCL sucks more than slightly, to be honest. What we'll probably do at some point is get the source Olsen data ourselves and parse it into a form that doesn't throw useful information away quite as freely.