Jan 22 2009

Time 1234567890 is coming up soon

In just three weeks the Unix time_t timestamp (the number of seconds since 1 Jan 1970) will hit the crucially important value 1,234,567,890:

$ python -c 'import time; print time.ctime(1234567890)'
Fri Feb 13 15:31:30 2009

(That’s PST.) Just in time for a geeky Friday-the-13th happy-hour beer bash.

This entry was posted on Thursday, January 22nd, 2009 at 10:32 AM and is filed under Computers. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

12 Responses to “Time 1234567890 is coming up soon”

  • Matt Says:
    January 22nd, 2009 at 11:42 AM

    Wouldn’t it be all time zones, the same time for each? In other words, 15:31 for PST and 15:31 for EST, not 18:31 for EST. Right?

  • Joachim Bengtsson Says:
    January 22nd, 2009 at 12:30 PM

    I’m guessing not…
    20:28:54 nevyn:~$ python -c ‘import time; print time.ctime(1234567890)’
    Sat Feb 14 00:31:30 2009

    (in Sweden, GMT+1)

  • Jens Alfke Says:
    January 22nd, 2009 at 12:44 PM

    No, timestamps refer to absolute times. Zero is defined as midnight, 1 Jan 1970 GMT. It would be a real mess if you had to store a timezone too, especially because time zones shift around by political whims.

  • fluffy Says:
    January 22nd, 2009 at 12:45 PM

    Bah, wake me up at Sat Nov 27 20:35:28 2032 (0x76543210).

  • Chris Rowe Says:
    February 7th, 2009 at 10:45 AM

    Check out http://www.coolepochcountdown.com

  • Jens Alfke Says:
    February 7th, 2009 at 11:10 AM

    Chris — You rock! I’ll be there Friday afternoon with a bottle of champagne. I’ve posted it to del.icio.us.

  • Richard Matteson Says:
    February 12th, 2009 at 1:05 AM

    How about 2147483648 (0x80000000). Will it be
    Fri Dec 13 12:45:52 1901 or
    Mon Jan 18 19:14:08 2038

  • Jens Alfke Says:
    February 12th, 2009 at 9:01 AM

    Richard — Not 1901 certainly. The Unix epoch starts at 1/1/1970, so if anything it’d roll over to that…

  • fluffy Says:
    February 12th, 2009 at 9:07 AM

    Not true! 0x80000000 is INT_MIN - which is -2^31. The (immediate) problem is that time_t is a signed int, not an unsigned int.

  • Jens Alfke Says:
    February 12th, 2009 at 9:44 AM

    Duh, you’re right of course, and they can’t change that for compatibility reasons. But wasn’t a 64-bit equivalent to that added ages ago?

    (It doesn’t affect me because I don’t use POSIX time APIs; I either use Foundation, whose time type is ‘double’, or Java/Ruby/Python/etc. which all use 64-bit ints for time…)

  • Richard Matteson Says:
    February 12th, 2009 at 2:14 PM

    Well, perl is still using a 32 bit signed integer:

    $ ## 2147483647 or 0x7fffffff
    $ ## local time is PST here (GMT +8)
    $ perl -e ‘print scalar localtime(0x7fffffff).”\n”;’
    Mon Jan 18 19:14:07 2038
    $ perl -e ‘print scalar localtime(0).”\n”;’
    Wed Dec 31 16:00:00 1969
    $ perl -e ‘print scalar localtime(0x80000000).”\n”;’
    Fri Dec 13 12:45:52 1901
    $ ## which is the same as -2147483648 (32 bit 2’s complement)
    $ perl -e ‘print scalar localtime(-2147483648).”\n”;’
    Fri Dec 13 12:45:52 1901

  • Richard Matteson Says:
    February 12th, 2009 at 2:19 PM

    Whoops, I mean GMT -8…