One of those magic times: On Friday the 13th!

Jon

Paw Prints: Writings of the maddog

Feb 01, 2009 GMT
Jon maddog Hall

"At 11:31:30pm UTC on Feb 13, 2009, Unix time will reach 1,234,567,890.
Where will you be at this momentous second?" - from Bell Labs

This will be Friday, February 13th at 1831 and 30 seconds EST. If you want to find out what time it will be in your local time, try this Perl script courtesy of Matias Palomec:

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

Now if there was any reason to fear Friday the 13th, I think this is it. That many numbers sequentially in a row representative of time? Who knows what will stop working? Will lex(1) cease to work, will yacc(1)s
everywhere revolt? Will the rapture be upon us?

I remember asking Alan Cox about UNIX (note that I spelled UNIX in all capital letters, as it should be) time with respect to Linux in 1999. I was confident that most Linux systems would not be adversely affected by "Y2K", but I knew about a hidden time-bomb in the year 2038, when the "UNIX epoch" comes to an end. Alan assured me that Linux was now working on 64-bit time, and its "roll-over" would happen about the time that the sun burnt out. And while this upcoming event is not a "roll-over", nevertheless because it occurs on Friday the 13th I will be holding my breath....

I intend on being at the place where I have the best chance of surviving this potential catastrophe and where I can personally do the most good:

=>Martha's Exchange Restaurant in Nashua, New Hampshire, USA<=

While our friends at Bell Labs (er, ah, Lucent....O.K. "Alcatel-Lucent") strive to understand this phenomenon, I will be doing my civic duty by drinking fine beer, and maybe an Islay scotch. This is hard to do while you are holding your breath, but I will suffer through. Who knows, perhaps the U.S. government will give us a "bailout" to study this issue.

Who will join me as we watch the time of UNIX line up? Please have a picture taken of you and your friends whereever you are at this time and email it to me at Pawprints AT linuxpromagazine DOT com

maddog

« previous post next post »

Comments

  • another numerological date

    If you really want to witness another cool timestamp (someone else said that none of us will witness one) heres another one:

    1 2 4 8 16 32 64

    >>> time.gmtime(1248163264)
    (2009, 7, 21, 8, 1, 4, 1, 202, 0)

    So that would be September 21st this year. I agree it's a bit far-fetched, but at least we all won't have to live with the idea that we can never witness a cool timestamp.

  • noone has tried

    Has no one tried pushing the time forward to see what happens?

  • Syncronicity?

    Never been here before. It seems no matter how far I roam something always brings me back. I linked here through The Daily Grail (Australia) and my wife (Japan) and I will be at Martha's for dinner tomorrow. Just thought it was kind of,,,well,,,syncronistic!

  • kzr7hbz

    date +%s
    1234570745

  • 64/32

    Can't we all just agree to run 64-bit by 2038?

  • time zone of death

    now goddamnit whats going to happen lets all watch as the time lines up if it ends i dont care at 10:31:30 itll end

  • woo-hoo.

    Hi, Maddog! I'll be celebrating more sedately in Maryland - I never did make it back to Boston to live. blunk

    I'm amused by Mr. Krause's article from years gone by. It didn't just happen that "the epoch" was the year that UNIX(tm Bell Labs etc.) was created - It's "the UNIX epoch" and it was DEFINED by Ken and Dennis, not by any microcomputer guys. But, good numerology.

    Morty is right about all those programs that need to be upgraded - or at least re-compiled - to use 64-bit time [remember all that Y2K work, guys?]. But it looks like a lot if it has already been done - IF IF IF you're running on a 64-bit system.

    And I can't write that last phrase without reminding folks that the first and arguably still best 64-bit general-purpose processor was actually put into production in 1992.
    http://en.wikipedia.org/wiki/DEC_Alpha
    http://h18002.www1.hp.com/alphaserver/
    http://www.alphalinux.org/
    And should never have been allowed to drop into the deskcracks of history!

  • My calendar is already marked

    It's interesting that it took so long for the wave of interest to catch on about this date. I remember blogging about the rollover to 1,111,111,111 back in March of 2005. And I've been looking forward to February 13, 2009 ever since.

    http://community.livejournal.com/do_ne_ge_of_cu/2607.html

    We will soon witness the last significant numerological date in computer history during our lifetime (using decimal notation at least, so long as the standard for Unix time maintains signed 32-bit integers).

  • Prize

    My wife and I are expecting on Feb 14, does anyone know if there is going to be a prize for the baby that is born at that time? "Kind of like the first child born each year"
    I am already telling her that she can't give birth until this exact moment in computer history
    Our other plan is if its a girl and born on Feb 17 were going to name her Annie for the TV transition...

  • lbmcizma

    <a href="http://vfoqdyud.com">wkgsoqzn</a> [URL=http://dffndbfz.com]trmektjp[/URL] cyyduywt http://vwwctfgt.com kbnwyfyv zoxmmqsd

  • It must the date then....

    I can get to the same time, only pacific time, so its a little later...

    date -d @67768036191705599
    Wed Dec 31 23:59:59 PST 2147485547

  • Time_t is 64 bit but date's year is still 32!

    Meza--67768036191673199 is still way less than 2^64 (or 2^63 plus sign), but hey, that year number looks familiar! Looks like your system handles 64 bit time, but your date command still want to store the year as a 32-bit signed integer...

  • last year

    meza@vash:~$ date -d @67768036191673199
    2147485547. dec. 31., wednesday, 23.59.59 CET

    this is the last time I can get...

  • Its my birthday this Friday...

    Looks like I'm *extra* lucky this year... not only does my birthday fall on a Friday this year (the 13th), but its also going to be host to this very special event.

    Mom, you picked a good day to give birth to me, some 37 years ago.

    w00t!

  • Not just Windows.. DOS had an "end of days" also

    I remember my boss back in 1999 (Thankfully I am retired now..so to speak) Asking me about the Y2K turnover and will our Windows and DOS PCs survive.
    LOL. She was an old lady - a grandmother, possibly a GREAT grandmother, (No offense St Grace of Hopper) and as CIO (LOL!) she though that half our PCs would self-destruct when 2000 came about.
    So I switched a coupla PCs over to the year 2005. No one noticed.
    And as well I checked the date at location 50 in DOS's memory - was it 16 bits or 32? cannot remember - and figured it was good until the year 2027.. or 2037? before all the 1s rolled over to zeros.
    Presumably by now, Vista, and Win7 which I now use, do not keep dates at location x50 anymore..

    Wait! it's the BIOS, not DOS! Where IS the clock kept now??

  • End of the World???

    FYI
    It won't be friday the 13th everywhere in the world when this is supposed to happen. So just 1 timezone further east it will be actually saturday the 14th. So what's going to happen to them? Will the world end for half of us?

    Something to think about!!!

  • Pedantry

    "note that I spelled UNIX in all capital letters, as it should be" - What's with the pedantic KAOS-geek shit?

  • Australia

    In Aus it will be on the 14th - Valentine's Day. Sounds like a better omen than Friday 13th (not that I believe in omens).

  • CoolEpochCountdown

    Also see http://www.coolepochcountdown.com

  • UTC+8

    Najmi@Najmi ~
    $ perl -e 'print scalar localtime(1234567890),"\n";'
    Sat Feb 14 07:31:30 2009

  • Windows

    Windows has the same 32-bit time constraint as unix if the program was written using C/C++ and used time_t. Some developers would have been smart and used other time objects, like COleDateTime. I'm surprised they haven't deprecated time_t and/or eliminated it from 32-bit programming all together. I guess one hopes that in 2038, if Apophis doesn't wipe us out in 2036, all computing would have shifted to 64-bit. That's not unreasonable seeing that the shift from 16 to 32 bit computing didn't take too long < 20 yrs.

  • What a difference a day makes (a.k.a Total Systems Failure)

    If all else fails, we have a "gentlemen's agreement" to roll the clock forward to the 14th... or 15th depending if the time lock (embedded Linux) on our bunker door functions as required.

    Has anyone prepared for the December 21, 2012 date? At this time we are just starting our roundtable discussions with our system engineers. Should we migrate to a Windows platform?


  • Wrong place to be at the critical time

    I thought that Milliways would be the correct place to be at that time.

    Remember, "DON'T PANIC!".....

  • Martha's? For the End of the World?

    You are going to Martha's for the end of times? Go candlepin bowling at Leda Lane's if you're going to go out or if you want to be at a bar go to Peddlars, but sheesh Martha's? You'll just get stabbed.

    Repent users, the UNIX apocalypse is at hand!

  • hi!!!

    what's the purpose of this...guys just asking...

  • UNIX (Linux) Time

    At my organization, our mitigation plan involved all critical computer hardware and software to be verified as compliant. We've spent millions on upgrading communication systems to compliance. Supplier verification is ongoing and is partially complete. Production has no compliance issues other than the planned pull in of material in the last month of 2009 to avoid any supply delays caused by outside UNIX (Linux) sequentially date issue.

    Verification of security systems compliance is awaiting a facility-specific response although the supplier has issued a general compliance statement.

    In a report presented to senior management, our staff engineers have addressed any and all forseen issues with the Friday the 13th Date issue.



  • userspace and 64-bit time

    While it's nice that the Linux kernel has a 64-bit time implementation, this doesn't immediately fix the Linux userspace. It's not as easy as just increasing time_t to 64 bits, either. A lot of code uses binary file formats with embedded times -- if you increase time_t to 64 bits naively, file format compatibility breaks. If you use printf on a time_t with a 32-bit format specifier, compatibility breaks, and you might not even notice. This is a difficult and subtle problem.

  • will i die?

    ohh not... we all gonna die......................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  • Damn, wrong time zone

    Or else that would be the very same day I'm getting married. That would have been so cool.

  • Yes, 64 bit

    > date -d @2147483648
    > outputs:
    > date: invalid date `@2147483648'

    On my AMD64 machine running Debian:

    /~ date -d @2147483648
    Mon Jan 18 21:14:08 CST 2038
    /~ date -d @21474836480
    Sat Jul 6 03:21:20 CDT 2650
    /~

  • 64 bit?

    Well, I respect Alan and all, but
    date -d @2147483647
    (maximum int) outputs:
    di jan 19 04:14:07 CET 2038

    and
    date -d @2147483648
    outputs:
    date: invalid date `@2147483648'

    now in the perl script the latter outputs:
    Fri Dec 13 21:05:24 1901

    which is Friday the 13th again!!!

    coincidence?

    but then I'll be 67 and sipping a drink under a palm tree somewhere, so i don care really.. blunk

  • February 14th

    It will be February 14 in my time zone. So, in case you're superstitious you should travel to a time zone where it'll be February 14.

  • perl?

    dumb perl script.

    date -d @1234567890
comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News

Tag Cloud

Administration Community Events Hardware Linux Linux Pro Magazine Mobile Programming Security Software Ubuntu Web Development Windows free software open source