http://qs1969.pair.com?node_id=440596

On today's Friday the Unix time stamp achieves a singular value around 1:58:31 UTC (2:58:31 MEZ): 1111111111. This value earns the descriptor historically, because the next combination of this kind (2222222222) lies beyond all times: The Unix time ends on 19 January 2038. From the view of the Coder the time is meanwhile banal, because after the DEC system, on which the Unix time stamps were born, would be correct the octal way of writing 10216432707 and everything else as a liquor number.

Replies are listed 'Best First'.
Re: 1111111111
by Fletch (Bishop) on Mar 18, 2005 at 03:14 UTC

    It overflows a 32-bit time_t value then, but so long as you move to a 64-bit value (as many of the major *NIXen have started doing, I believe; similar to offset_t growing for large file support) everything will continue to work just fine.</pedant>

    It's the people running embedded systems (or emulators) that're in for trouble . . .

      <rant>
      If switching to a 64-bit value for time_t meant that "everything will continue to work just fine", 32 bit time_ts would have been something of the past already.

      There's a lot more to it than that. First, it's a matter of synchronization. Compiling a piece of software that uses 64 bit time_t and linking that (either at compile, or run time) against a library that expects 32 bit timestamps is unlikely to work correctly. Another synchronization problem happens in client/server applications. If one side starts thinking that timestamps are 8 bytes instead of 4, you have a problem. Second problem is data. 32 bit time_t date written to a database, or serialized takes 4 bytes. But if you switch to 64 bit timestamps, you can't assume your data has suddenly changed.

      Now, switching to a different time_t size doesn't have to be a problem. If everyone is aware of the potential problems and takes them into account, no major problems will arrise. In fact, problems will only arrise if people are naive enough to think that "moving to a 64-bit value will make everything to continue to just work fine". It may be telling that some vendors use time64_t instead of changing the type of time_t.

      Interesting is also this Long Time Type proposal.
      </rant>

        The answer is simply my friend. Although it could be a bit of work in some cases, its mostly considered a minor/non-issue today. Developers always have to worry about bigger problems or features to add. The closer we get, the bigger the priority this will become. Heck, we got @ 33 years to plan.

      ah shucks... I was just about to notify the Enquirer that the universe will end in a scant 3 decades....
      and then hustle the feds for a LARGE grant to avert the catastrophe.

      And there you go spoiling it

      ;>)
Re: 1111111111
by Callum (Chaplain) on Mar 18, 2005 at 00:23 UTC
    :)
    *sigh* time was I'd have actually known this, not using Unix anymore has had terrible consequences, now I just spend my time playing with Excel and Powerpoint :( MBAs are bad things... :)

    "The Unix time ends on 19 January 2038."
    But fortunately that won't be a problem, because there's no way we could possibly still be using a dating scheme with a hard stop like that in it then... right?

    Ah well, maybe'll it'll be good for some decent contract work in 23 years time! :)

Re: 1111111111
by zentara (Archbishop) on Mar 18, 2005 at 14:29 UTC
    This reminds me of the "Millenium bug" which threatened the world a few years ago. The doom was prevented by thousands of Fortran and Cobol programmers, who saved us for the measly collective sum of 5 billion dollars. This will be another "programmer's bonanza". Of course it will probably all be outsourced to India and Bangladesh this time :-). If you need to save the world, you may as well save money too. :-) I'll be too old to care anyways.

    P.S. Hmmmmm. This occurs right after the tip-off time of the Second MarchMadness Game today... I wonder what the numerologists would say....I think it means a big upset....sure...yeah....bet on the underdog today. :-)


    I'm not really a human, but I play one on earth. flash japh

      Sithspit. While there were some very specific date-sensitive systems, the Y2K bug was largely hype.

      I remember lieing in bed, sick, about two weeks before the date rollover, when I had a violent case of the obvious: why would my computer care if the date is Jan 1, 1900 (or 19100)? The majority of computers wouldn't.

      Now, there are computers that do care, and were proven to care by putting the dates to Dec 31, 1999 @ 11:59pm and waiting a few minutes. Billing systems in particular were affected, so we were looking at a potential finacial crisis. And yes, it was largely FORTRAN and COBOL code.

      But the power would continue to run. Satalites would not fall. Nukes would not be launched.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

        Yeah, if I recall correctly, the only malfunction the news reported was a few remote seismic monitors up in Alaska. It sure was "whooped up" in the media though.

        I'm not really a human, but I play one on earth. flash japh
      The unix time value rolled over to 10 (decimal) digits back on Sept 9th, 2001. A few things broke, but nobody really noticed.

      slashdot covered the story.

Re: 1111111111
by tlm (Prior) on Mar 18, 2005 at 02:39 UTC
Re: 1111111111
by fraktalisman (Hermit) on Mar 19, 2005 at 22:11 UTC

    I remember the millennium very well. During december I had been working on an ecological farm in Andalucia, Spain and when returning to Germany by bus in the early days of January 2000, the digital display at the Spanish bus station did not work. It had worked before.

    I had gotten myself ready to come home and see my Windows 95 having expired. Of course, it hadn't. I found it even a bit disappointing that no millennium chaos had happened. I started learning perl shortly afterwards and was fascinated by the elegant way of the time function ... year+=1900 ... why not? Or maybe the elegance here lies within the system not within perl? I don't know, and luckily I don't have to care about 32 or 64 bit time format either.

    Now some more years back in time, I stopped using Windows 3.11 (you can see, I'm not a UNIX type of guy at all, some Linux experiments not taken into account, I really used Commodore until 1990, DOS PC until 1995, Windows 3.1x until 1998) and I remember that on download sites there were mostly at least two versions of executables - 16bit and 32bit. To me, it's a reasonable and conscious decision to give a 64 bit function a new name, not the same name as the 32 bit version. If there is a program that expects 32 bit, it should either get 32 bit or an error message. But programmers should be easily aware which version they are using!