SIDEBAR
»
S
I
D
E
B
A
R
«
Time 1234567890 is coming up soon
January 22nd, 2009 by jens

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.


12 Responses  
  • Matt writes:
    January 22nd, 200911:42 AMat

    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 writes:
    January 22nd, 200912:30 PMat

    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 writes:
    January 22nd, 200912:44 PMat

    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 writes:
    January 22nd, 200912:45 PMat

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

           
  • Chris Rowe writes:
    February 7th, 200910:45 AMat

    Check out http://www.coolepochcountdown.com

           
  • Jens Alfke writes:
    February 7th, 200911:10 AMat

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

           
  • Richard Matteson writes:
    February 12th, 20091:05 AMat

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

           
  • Jens Alfke writes:
    February 12th, 20099:01 AMat

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

           
  • fluffy writes:
    February 12th, 20099:07 AMat

    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 writes:
    February 12th, 20099:44 AMat

    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 writes:
    February 12th, 20092:14 PMat

    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 writes:
    February 12th, 20092:19 PMat

    Whoops, I mean GMT -8…

           


»  Substance:WordPress   »  Style:Ahren Ahimsa