Forgot your password?
typodupeerror
Unix Operating Systems Software IT

February 13th, UNIX Time Will Reach 1234567890 376

Posted by timothy
from the less-often-than-a-stopped-clock-is-right dept.
mikesd81 writes "Over at Linux Magazine Online, Jon maddog Hall writes that on Friday the 13th, 2009 at 11:31:30pm UTC UNIX time will reach 1,234,567,890. This will be Friday, February 13th at 1831 and 30 seconds EST. Matias Palomec has a perl script you an use to see what time that will be for you: perl -e 'print scalar localtime(1234567890),"\n";' Now, while this is not the UNIX epoch, Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."
This discussion has been archived. No new comments can be posted.

February 13th, UNIX Time Will Reach 1234567890

Comments Filter:
  • by John Hasler (414242) on Sunday February 08, 2009 @04:31PM (#26776165) Homepage

    Is that with or without leap seconds?

    • by dotancohen (1015143) on Sunday February 08, 2009 @04:36PM (#26776223) Homepage

      On Friday the 13th, every second is a leap second. BOO!

    • With (Score:4, Informative)

      by Vellmont (569020) on Sunday February 08, 2009 @04:52PM (#26776415) Homepage

      Good question:
      http://en.wikipedia.org/wiki/Unix_time [wikipedia.org]

      the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60).

      I don't think there's any defined way for a POSIX machine to deal with leap seconds. The usual solution is to slew the clock a bit after they occur.

      • Can we just not use them? I mean, who really cares if the sun is at its highest point a minute after midday on the summer solstice? Maybe in a hundred years or so we can schedule a leap minute, and by then we'll probably have worked out sensible standards for dealing with them.
        • by shaitand (626655)

          maybe we could just move to a calendar and time system that gives finer resolution and is based on 10's like the metric system.

          • Re:With (Score:5, Informative)

            by ultranova (717540) on Sunday February 08, 2009 @06:04PM (#26777177)

            maybe we could just move to a calendar and time system that gives finer resolution and is based on 10's like the metric system.

            Unix clock is using the metric system. "Second", after all, is the metric unit for time, and Unix clock simply counts the seconds after a certain point in time. It's only the human representation of that value which deals with minutes and such.

          • Re: (Score:3, Insightful)

            by FST777 (913657)
            The resolution is not the problem. Due to the fact that we are measuring nature, small changes do happen. This is the reason that leap seconds aren't scheduled decades in advance.

            See here [wikipedia.org].

            I'd like the metric system to take over our measurement of time, but, disregarding other problems, it won't solve the leap second issue all by itself.
          • Re:With (Score:5, Informative)

            by Daimanta (1140543) on Sunday February 08, 2009 @07:55PM (#26778173) Journal

            The french tried it. It failed.

            The days(fixed) in a year(fixed) are not divisible by 10 so there were days without a month. Furthermore it increases the number of days in each week and it changed the definition of the hour(10 each day) the minute(100 each hour) and the second(100 each minute).

            All in all, it was a mess. Not designed with nature as a guideline(like pretty much all other calendars) but with the number 10, a number based on the fingers on our hands.

            http://en.wikipedia.org/wiki/French_Republican_Calendar [wikipedia.org]

      • Leap seconds (Score:5, Insightful)

        by CustomDesigned (250089) on Sunday February 08, 2009 @05:55PM (#26777063) Homepage Journal

        Raw unix time is simply a count of seconds since a defined point in time - and has nothing to do with leap seconds. Leap seconds only come into play when converting to human readable display format (along with timezones and DST). Leap seconds have been handled for some time by the zoneinfo library used by most unix and linux distros. Even Java handles leap seconds with my port of zoneinfo to a Java TimeZone implementation [nyud.net].

        The tzdata package included in most Linux distros includes leapsecond data in the "right" directory. You can find out the time including leapseconds by setting your TZ environment variable to "right/...". For instance:


        $ TZ="right/US/Eastern" date; TZ="US/Eastern" date
        Sun Feb 8 17:52:42 EST 2009
        Sun Feb 8 17:53:06 EST 2009

        • Re: (Score:2, Informative)

          by Anonymous Coward

          Unfortunately you're wrong. "Unfortunately" because that would have made sense. Unix time counts the (milli-)seconds since the Unix epoch excluding leap seconds. As far as Unix time is concerned, these seconds don't exist. What's worse, the behavior near a leap second is not defined. Some slew the clock, some stop it for a second, some even repeat the second. As it stands, Unix (POSIX) does not have a way to reliably count the seconds between two points in time. If you're not thinking "WTF?" now, read that

          • Re: (Score:2, Informative)

            by TeXMaster (593524)
            Fortunately, the one who's wrong is you. Unix time counts the (milli)seconds elapsed since the Unix epoch, full stop. When leap seconds are introduced, they elapse just as well as normal seconds, although every minute, hour, day, week, month, year etc containing will be one second longer (e.g. the minute will be 61 seconds long instead of 60 seconds long). So you only care about leap seconds and Unix time only when you have to convert from Unix time to human-readable form, or conversely, because instead of
            • Re: (Score:3, Informative)

              by hamster_nz (656572)

              Sorry, UNIX time is exactly 86400 seconds per day.

              If you read this history of POSIX time [mail-archive.com] it becomes apparent that POSIX time is a mashup of UTC and GMT that is different to either.

              The standard does not require your system clock to be accurate. When a leap second occurs, unless your POSIX system makes the effort to adjust its clock (say via the adjtimex(2) call), your POSIX system's clock will ignore the leap second.

              To make matters worse, people are now syncing their systems to a UTC or TIA time source, or

              • Re:Leap seconds (Score:4, Informative)

                by sshock (975534) on Sunday February 08, 2009 @09:14PM (#26778673) Homepage

                Sorry, UNIX time is exactly 86400 seconds per day.

                Exactly. Mod parent up. Mod gparent down.

                date -u -d @1230767999
                Wed Dec 31 23:59:59 UTC 2008

                date -u -d @1230768000
                Thu Jan 1 00:00:00 UTC 2009

                What happened to the leap second? It was completely ignored, yep.

                • Re: (Score:3, Informative)

                  by Alain Williams (2972)
                  Try again with the 'right' timezone -- note the seconds of '60':

                  TZ="right/GB" date -d @1230768022
                  Wed Dec 31 23:59:59 GMT 2008

                  TZ="right/GB" date -d @1230768023
                  Wed Dec 31 23:59:60 GMT 2008

                  TZ="right/GB" date -d @1230768024
                  Thu Jan 1 00:00:00 GMT 2009

            • Re:Leap seconds (Score:4, Informative)

              by JackHoffman (1033824) on Sunday February 08, 2009 @08:13PM (#26778271)

              Total moderation failure...

              Here's how the standard defines the meaning of "seconds since the epoch" in relation to UTC dates: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_14 [opengroup.org]
              As you can see, the meaning is actually "seconds since the epoch, excluding leap seconds." Always read the definitions.

              According to that definition, the time_t value of "Friday the 13th, 2009 at 11:31:30pm UTC" is:
              30 + 31*60 + 23*3600 + 43*86400 + (109-70)*31536000 + ((109-69)/4)*86400 - ((109-1)/100)*86400 + ((109+299)/400)*86400
              = 30 + 1860 + 39600 + 3715200 + 1229904000 + 864000 - 86400 + 86400
              = 1234567890

              So, to answer the question which started this: Not including leap seconds.

              Besides, it should be "Friday the 13th, 2009 at 23:31:30 UTC." The am/pm notation is not without ambiguities.

        • Not so. UNIX time is strictly defined in POSIX, as are the arithmetic relationships between it and human time, e.g. a time_t % 60 gives you the elapsed seconds in the current minute, which would not be true if unix time included leap seconds.

          What you are describing is TAI, or International Atomic Time. If you were to choose to run your system on TAI, you would need some conversion routines if you wanted your system to remain POSIX compatible (which is what modern unix/linux apps expect) -- e.g. time() a

          • Technically, you are right. But that has got to be the stupidest thing I've ever seen (not you - the decision by the POSIX committee). POSIX destroys the simple second count just because some braindead application expects time()%60 to be the offset within a minute, instead of using localtime? Because some bozo thinks he can divide seconds by a constant to get days instead of using localtime() (or properly designed substitute), the POSIX committe "makes it so"?

            A posix timestamp isn't even an unambiguous t

    • by Yvan256 (722131) on Sunday February 08, 2009 @05:33PM (#26776791) Homepage Journal

      What do you mean? An African or European leap second?

  • scalar() unnecessary (Score:5, Informative)

    by A nonymous Coward (7548) on Sunday February 08, 2009 @04:32PM (#26776183)

    perl -e 'print localtime(1234567890) ."\n";'

    Let the "." concatenate operator do it for you.

  • by A beautiful mind (821714) on Sunday February 08, 2009 @04:32PM (#26776187)
    ...it's my birthday. I've been telling people for years that my birthday is at 1234567890.
  • by dotancohen (1015143) on Sunday February 08, 2009 @04:34PM (#26776211) Homepage

    ...that I really feel I missed:

    $ perl -e 'print scalar localtime(8675309),"\n";'
    Sat Apr 11 11:48:29 1970

  • by John.P.Jones (601028) on Sunday February 08, 2009 @04:37PM (#26776237)

    So the time is 123456789? That's the stupidest time I've ever heard in my life... It sounds like something an idiot would have on his luggage.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      Hey! That's my luggage combination!

    • by mochan_s (536939)

      That's amazing! I've got the same combination on my luggage!

      And change the combination on my luggage!

    • Re: (Score:3, Insightful)

      by Waffle Iron (339739)

      So the time is 123456789? That's the stupidest time I've ever heard in my life... It sounds like something an idiot would have on his luggage.

      Indeed, it would be hard to find a more stupid era than Nov 1973. It was the height of the Watergate scandal, a time of inflation, energy crisis, bad haircuts, ugly suits, and the quality of pop music spiraling downward. Truly a nadir in modern history.

      • Re: (Score:3, Funny)

        by DiegoBravo (324012)

        > and the quality of pop music spiraling downward. Truly a nadir in modern history.

        I'd call that an inflection point. The nadir is TODAY.

    • Hey! That's my root password!
  • by Chris Pimlott (16212) on Sunday February 08, 2009 @04:43PM (#26776289)

    The standard unix date command will suffice:

    date -d @1234567890

    • by Anonymous Coward on Sunday February 08, 2009 @04:51PM (#26776399)
      Leave it to a Slashdot story to make my terminal window look like this:

      dave@tomservo:~$ perl -e 'print scalar localtime(1234567890),"\n";'
      Fri Feb 13 18:31:30 2009
      dave@tomservo:~$ perl -e 'print ~~ localtime(1234567890),"\n"'
      Fri Feb 13 18:31:30 2009
      dave@tomservo:~$ perl -e 'print localtime(1234567890) ."\n";'
      Fri Feb 13 18:31:30 2009
      dave@tomservo:~$ `watch date +"%s"`

      dave@tomservo:~$ perl -le 'print ~~localtime 1234567890'
      Fri Feb 13 18:31:30 2009
      dave@tomservo:~$ date -d @1234567890
      Fri Feb 13 18:31:30 EST 2009
      dave@tomservo:~$

      I've wasted my life.

      • you think thats bad, i have three terminals open now, but the most interesting was.
        >>> def edate(n):

        ... i=0

        ... while i != n :

        ... d = "date -d@" + str(2**i)

        ... print n, " ->", os.popen(d).readline(),

        ... i+=1

        produced an interesting bug at 56 because the year is bigger than 2^32

        I think it is infact ME thats wated my life

    • date -d @1234567890

      does not work on my Fedora Core 5 machine. Which is not that old.

      The perl script works more reliably.

    • by slashnik (181800)

      How about
      while true ; do date +%s; sleep 1; done

    • by dfn_deux (535506)
      That is a gnu'ism. It isn't "standard unix".
  • I guess I'll have to wait until 2012 [wikipedia.org] for the end of the world.
  • by taniwha (70410) on Sunday February 08, 2009 @05:13PM (#26776625) Homepage Journal
    this of course will be happening on Sat Feb 14th .... at about lunch time here in NZ .... earlier that day (at breakfast) it will be 1234554321
  • Y2^40K (Score:5, Funny)

    by DRJlaw (946416) on Sunday February 08, 2009 @05:16PM (#26776651)

    Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."

    This is just the sort of short-sighted thinking that lead to our recent Y2K hysteria, except this time our poor beleaguered descendents will be in the middle of an exodus from the solar system when all their legacy systems throw simultaneous exceptions. This will of course cause their engine and guidance systems to fail, so that the last dying gasps of humanity will consist of:

    [Captain]Captain's log, stardate 1704.4. Ship out of control, spiraling down towards Sol; we have 19 minutes of life left, without engine power or helm control.
    [Engineer interrupting] I'll be damned. The clocks on every piece of technology in existence have failed because that damned Brit used a 64 bit counter...
    [Captain]COOOOOOOOOOOOOX!!!"

    • Re: (Score:2, Funny)

      by Simetrical (1047518)

      Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."

      This is just the sort of short-sighted thinking that lead to our recent Y2K hysteria, except this time our poor beleaguered descendents will be in the middle of an exodus from the solar system when all their legacy systems throw simultaneous exceptions. This will of course cause their engine and guidance systems to fail, so that the last dying gasps of humanity will consist of:

      [Captain]Captain's log, stardate 1704.4. Ship out of control, spiraling down towards Sol; we have 19 minutes of life left, without engine power or helm control. [Engineer interrupting] I'll be damned. The clocks on every piece of technology in existence have failed because that damned Brit used a 64 bit counter... [Captain]COOOOOOOOOOOOOX!!!"

      If only they had followed RFC2550 [ietf.org], that would never have happened!

    • by profplump (309017)
      At least it buys us some time.
    • If they are still running *NIX of any flavor when the sun dies then they should be forced to stay put... Lazy Bastards!

      And I'm STILL waiting for my flying car, dammit!!
  • by Anonymous Coward

    >UNIX epoch 'roll-over' would happen about the time that the sun burnt out."

    Yes, that will be a nice little surprise for whatever cyborg/singularity we've evolved into as they try to flee to a habitable star system in their linux controlled vessels.

    Linux will doom us all.
    BG

  • working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out.

    Not if we start counting at a much finer resolution. I mean, after all, seconds are so...Last Century.

  • dammit! (Score:4, Funny)

    by tbj61898 (643014) <andre@@@vellori...it> on Sunday February 08, 2009 @05:48PM (#26776999) Homepage

    it's my password... now everyone know it, thanks SLASHDOT! :-)

  • by altek (119814) on Sunday February 08, 2009 @05:49PM (#26777001) Homepage

    Yes, it's a slow news day and that's why this is on the front page! It's Sunday afternoon (for most of us), ferchrissakes.

    So just enjoy it, it's geeky and novel. I don't think anybody meant for it to be considered a big deal, and if you don't find any fleeting moment of joy from it, just move along.

  • by sprior (249994) on Sunday February 08, 2009 @06:00PM (#26777139) Homepage

    Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."

    So great, we're going to be dealing with the 64bit time roll over in the dark? What kinda planning is that! Do we have candles?

    • by Gazzonyx (982402)
      Candles! Candles?!

      You spoiled kids! back in my day, I had to crawl under my desk and use a lighter to see while plugging in a USB stick. We didn't need fancy lights or front-of-box USB ports; we had our raw muscle and... oh, wait. You said candles, not flashlight.

      Could you rephrase the question but with the word 'flashlights' in place of 'candles'?

      Also, feel free to get off my lawn after that.
      • by sprior (249994)

        USB sticks! What's this about USB sticks! In my day (before Win98 with your little USB support) we had floppies (the real floppy ones, not the little dinky things the older kids stopped playing with recently) and we liked it!

  • by jimicus (737525) on Sunday February 08, 2009 @06:35PM (#26777511)

    ... for any application that assumes sizeof(time_t) is 32 bits.

    Not that I'd expect that to be the case with any half-decent intelligently written application. But we all know how common applications which are neither half-decent nor intelligently written are...

  • First thought: "Wait, wasn't that almost 180 years ago?"

  • the UNIX epoch 'roll-over' would happen about the time that the sun burnt out.

    Perhaps the roll-over will be the cause of the sun burning out.

  • I get:
    alex@quadruped:~$ perl -e 'printlocaltime(1234554321) ."\n";'
    Sat Feb 14 06:45:21 2009

    So I call insensitive clods.

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Working...