Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

February 13th, UNIX Time Will Reach 1234567890

Posted by timothy on Sun Feb 08, 2009 04:26 PM
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."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by John Hasler (414242) on Sunday February 08 2009, @04:31PM (#26776165)

    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)

      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.

      • 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:3, Informative)

              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)

                  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.

              • Re: (Score:3, Informative)

                Oh, that's right, it doesn't.

                Exactly. That's why all programs should store and communicate future date/times in local time format (with the local timezone) and use GMT only for the current time or past events, because nobody knows when the government is going to come along and redefine time. Your 3PM appointment at the dentist is at 3PM regardless of how many leap seconds get inserted or if its decided that this year, daylight saving time will only shift by 30 minutes, or whatever other crisis may come.

                  • Re: (Score:3, Insightful)

                    Pedantically.... You should always store in UTC. GMT is just a more important local time, but still subject to local laws and whims.
              • by CustomDesigned (250089) on Sunday February 08 2009, @09:00PM (#26778587) Homepage Journal

                I am gratified to see that time() in gnu/linux returns seconds since the epoch. They mention the contradictory requirements of Posix, but opine that it was a technical error, and seconds since the epoch is what they really meant (or should have meant).

                NOTES POSIX.1 defines seconds since the Epoch as a value to be interpreted as
                              the number of seconds between a specified time and the Epoch, according
                              to a formula for conversion from UTC equivalent to conversion on the
                              naive basis that leap seconds are ignored and all years divisible by 4
                              are leap years. This value is not the same as the actual number of
                              seconds between the time and the Epoch, because of leap seconds and
                              because clocks are not required to be synchronised to a standard refer-
                              ence. The intention is that the interpretation of seconds since the
                              Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further
                              rationale.

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

            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]

            • Re:With (Score:5, Funny)

              by Anonymous Coward on Sunday February 08 2009, @08:56PM (#26778561)

              The french tried it. It failed.

              If any post should be marked redundant...

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

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

      And change the combination on my luggage!

    • Re: (Score:3, Insightful)

      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.

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

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

  • 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!!!"

  • 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 jimicus (737525) on Sunday February 08 2009, @06:35PM (#26777511) Homepage

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

    • Re: (Score:3, Informative)

      I'm going to quit work before 2147483647 because I don't want to update all my code.

    • by FooAtWFU (699187) on Sunday February 08 2009, @05:03PM (#26776527) Homepage

      The OS itself may live past the 2038 32-bit time_t rollover, but the same cannot be said about all mission-critical apps that may be running on top of the Linux OS.

      Or any OS, for that matter.

      And now a bit of topical humor so this post isn't purely an exercise in pointing out the obvious: "Every day is a long day, because 86400 seconds won't fit in a short."