Slashdot Mirror
February 13th, UNIX Time Will Reach 1234567890
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."
Is that with or without leap seconds?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
perl -e 'print localtime(1234567890) ."\n";'
Let the "." concatenate operator do it for you.
Infuriate left and right
...it's my birthday. I've been telling people for years that my birthday is at 1234567890.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
...that I really feel I missed:
$ perl -e 'print scalar localtime(8675309),"\n";'
Sat Apr 11 11:48:29 1970
It is dangerous to be right when the government is wrong.
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.
Wow, you must have a hard time finding joy in anything.
I just pooped your party.
The standard unix date command will suffice:
date -d @1234567890
11.23 seconds later UNIX time will reach 10^11/3^4. You can celebrate that instead.
I'm going to quit work before 2147483647 because I don't want to update all my code.
Good question:
http://en.wikipedia.org/wiki/Unix_time
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.
AccountKiller
Or if you want the countdown, something like while true; do let a=1234567890-`date +"%s"`; echo $a; sleep 1; done"
Belief is the currency of delusion.
http://coolepochcountdown.com/
The World Wide Web is dying. Soon, we shall have only the Internet.
Just wait till Unix time reaches 3141592654 (sorry I rounded up the last digit on the holy number, if its that bad you can celebrate a second earlier) If you think people get crazy about pi day wait till you mix pi and unix.
http://www.aaronrogier.net
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."
The World Wide Web is dying. Soon, we shall have only the Internet.
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
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:
>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
However, considering that OSX is based on BSD, you can also get Apple pi.
Good, inexpensive web hosting
it's my password... now everyone know it, thanks SLASHDOT! :-)
nop, nop, nop #VBLANK
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.
THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
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.
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
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?
1234567890 is some arbitrary decimal string, if you wished to note a notable number, why not one which is 2^N, for something so entirely based within computers, it seems much more sensible to think in binary than some decimal number which happens to look a little pretty
Why do we have gaydar but not virgindar?
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
... 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...
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.
I think you're having some trouble with overflow. Try 64 bit:
[bishop@cluster ~]$ perl -e 'print scalar localtime(3151592653),"\n"'
Wed Nov 13 12:24:13 2069
32 bit:
bishop@home $ perl -e 'print scalar localtime(3141592653),"\n"'
Wed Jun 14 13:09:17 1933
http://letmegooglethatforyou.com/?q=TMTOWTDI
Well I guess you're running a very weird version of linux then. I've done a LOT of time related on UNIX over the years (including dealing with the leap second question) and I can assure you that the following UNIXes all follow the Posix definition: Linux, Solaris, FreeBSD, OS/X, AIX, HP/UX, OpenBSD. I'm not aware of a single UNIX that operates differently.
On systems that have timezone support based on the reference zoneinfo implementation you can use a $TZ prefixed with "right/" (i.e. "right/US/Eastern", etc...) to use an alternative timescale where time_t includes leap seconds. I've never seen a linux distro that enabled this by default. Some zoneinfo-using OSes (like OS/X) don't even bother to ship these files.
Also ntpd only supports the POSIX definition. So if you're using a UNIX with ntpd support, guess what... you have POSIX time_t.
But if you STILL don't believe me, here's a one-liner you can try running at your shell prompt (assuming you have GNU date, like on a linux box):
$ date -d@1230767999; date -d@1230768000
Wed Dec 31 15:59:59 PST 2008
Wed Dec 31 16:00:00 PST 2008
Note that those two times were NOT consecutive (there was a leap second @23:59:60 GMT) but, as you can see, they had consecutive time_t's. Also note how the beginning of every hour has a time_t that is divisible by 100 (since posix assumes that all hours are 3600 seconds)
Hm. I read the RFC, and it seems patently insufficient when discussing necessary granularity. Clearly, time should be represented in Planck units, as this is the (currently theorized) maximum necessary resolution to describe a timepoint.
Current estimates on the age of the universe indicate that approximately 10^61 planck times have elapsed. This puts us at a present need beyond 128-bit time.
Assuming the ultimate fate of the universe is heat death with proton decay, then 256-bit time should cover the span of the life of the universe to beyond the presence of matter (~10^100 years).
For the truly pedantic, Planck-resolution time structs could be coupled with meta-size header concept from the I-TAG described in RFC2795, which would yield arbitrary representation in the case of future needs, such as if the universe does not die on schedule.
It is left as an open question to decide where the zero-point of the calendar should be fixed, given the imprecise knowledge of the birth of the universe.