February 13th, UNIX Time Will Reach 1234567890 376
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."
Leap Seconds? (Score:5, Funny)
Is that with or without leap seconds?
Re:Leap Seconds? (Score:5, Funny)
On Friday the 13th, every second is a leap second. BOO!
Re: (Score:2, Funny)
Re: (Score:3, Insightful)
But here it won't happen until Saturday.
"Sat Feb 14 00:31:30 2009 CET"
With (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re:With (Score:5, Informative)
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:With (Score:5, Informative)
in what way is the "second" metric?
How about this way? [nist.gov]
Re: (Score:3, Informative)
The second is the official SI unit of time.
http://en.wikipedia.org/wiki/SI [wikipedia.org]
Re: (Score:3, Insightful)
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)
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)
The french tried it. It failed.
If any post should be marked redundant...
Leap seconds (Score:5, Insightful)
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:2, Informative)
Unfortunately you're wrong. "Unfortunately" because that would have made sense. Unix time counts the (milli-)seconds since the Unix epoch excluding leap seconds. As far as Unix time is concerned, these seconds don't exist. What's worse, the behavior near a leap second is not defined. Some slew the clock, some stop it for a second, some even repeat the second. As it stands, Unix (POSIX) does not have a way to reliably count the seconds between two points in time. If you're not thinking "WTF?" now, read that
Re: (Score:2, Informative)
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)
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)
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)
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)
UNIX time vs TAI (Score:2)
Not so. UNIX time is strictly defined in POSIX, as are the arithmetic relationships between it and human time, e.g. a time_t % 60 gives you the elapsed seconds in the current minute, which would not be true if unix time included leap seconds.
What you are describing is TAI, or International Atomic Time. If you were to choose to run your system on TAI, you would need some conversion routines if you wanted your system to remain POSIX compatible (which is what modern unix/linux apps expect) -- e.g. time() a
Re: (Score:2)
Technically, you are right. But that has got to be the stupidest thing I've ever seen (not you - the decision by the POSIX committee). POSIX destroys the simple second count just because some braindead application expects time()%60 to be the offset within a minute, instead of using localtime? Because some bozo thinks he can divide seconds by a constant to get days instead of using localtime() (or properly designed substitute), the POSIX committe "makes it so"?
A posix timestamp isn't even an unambiguous t
Linux interpretation of Posix (Score:5, Informative)
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:Leap Seconds? (Score:5, Funny)
What do you mean? An African or European leap second?
scalar() unnecessary (Score:5, Informative)
perl -e 'print localtime(1234567890) ."\n";'
Let the "." concatenate operator do it for you.
Re:scalar() unnecessary (Score:5, Interesting)
Fri Feb 13 13:45:21 2009
Apparently a palindrome is one the same day!
Re:scalar() unnecessary (Score:5, Informative)
Perl is unnecessary:
date -d@1234567890
Re:scalar() unnecessary (Score:5, Funny)
Thus proving TMTOWTDI. ;)
Teenage mutant turtle on wild turtle date...? What the hell does I stand for?!
Re: (Score:2)
it is, you need watch --interval=1 date +"%s" or the interval could be anything
Re: (Score:2)
Or if we're still playing golf:
watch -n 1 date +"%s"
Re: (Score:2, Interesting)
Re: (Score:2)
While we're finding other WTDIs:
php -r "echo strftime('%Y-%m-%d %H:%M:%S', 1234567890);"
why command-line? (Score:5, Interesting)
Re: (Score:3, Funny)
You are talking about the countdown to a "cool" number in UNIX time, and you don't want to use the command line???
Re: (Score:2)
You know, being snide just because you don't know how to do something leaves a poor impression.
Hint: date -d 'jan 1 1970 00:00:00 UTC 1234567890 seconds' works just fine on a GNU machine.
It's also a notable day because... (Score:5, Funny)
Re:It's also a notable day because... (Score:5, Funny)
Then they look at you like you are an idiot and never talk to you again. enjoy you birthday alone.
Re:It's also a notable day because... (Score:5, Funny)
Re: (Score:2, Funny)
Re:It's also a notable day because... (Score:5, Funny)
Re:It's also a notable day because... (Score:4, Funny)
Actually, the date... (Score:4, Funny)
...that I really feel I missed:
$ perl -e 'print scalar localtime(8675309),"\n";'
Sat Apr 11 11:48:29 1970
Re: (Score:2)
Re: (Score:2)
I doubt anyone cared much about 8675309 in 1970, considering the song was about -12 years old.
What kind of stupid time is that? (Score:5, Funny)
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)
Hey! That's my luggage combination!
Re: (Score:2)
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.
Re: (Score:3, Funny)
> 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.
Re: (Score:2)
Perl script is unnecessary (Score:5, Informative)
The standard unix date command will suffice:
date -d @1234567890
Re:Perl script is unnecessary (Score:5, Funny)
I've wasted my life.
Re: (Score:2)
you think thats bad, i have three terminals open now, but the most interesting was.
>>> def edate(n):
... i=0
... while i != n :
... d = "date -d@" + str(2**i)
... print n, " ->", os.popen(d).readline(),
... i+=1
produced an interesting bug at 56 because the year is bigger than 2^32
I think it is infact ME thats wated my life
date -d Does not work (Score:2)
date -d @1234567890
does not work on my Fedora Core 5 machine. Which is not that old.
The perl script works more reliably.
Well since they said UNIX time and not Linux time (Score:2)
Re: (Score:2)
date -d 'jan 1 1970 00:00:00 UTC 1234567890 seconds'
Re: (Score:2)
How about
while true ; do date +%s; sleep 1; done
Re: (Score:2)
Oh, well... (Score:2)
Re: (Score:2)
For about half the world .... (Score:4, Interesting)
Y2^40K (Score:5, Funny)
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:
Re: (Score:2, Funny)
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:
If only they had followed RFC2550 [ietf.org], that would never have happened!
Re: (Score:2)
Re: (Score:2)
And I'm STILL waiting for my flying car, dammit!!
UNIX epoch 'roll-over' (Score:2, Funny)
>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
Re: (Score:2, Funny)
This will all be settled by the Great Windo-Linux War of 2089. Or so my future self told me, during his last visit.
...So 2089 will be the year of the Linux desktop?
Not If... (Score:2)
Not if we start counting at a much finer resolution. I mean, after all, seconds are so...Last Century.
Comment removed (Score:4, Funny)
Why all the hatin'? (Score:5, Insightful)
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.
S^64 and Solar burnout (Score:5, Funny)
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?
Re: (Score:2)
You spoiled kids! back in my day, I had to crawl under my desk and use a lighter to see while plugging in a USB stick. We didn't need fancy lights or front-of-box USB ports; we had our raw muscle and... oh, wait. You said candles, not flashlight.
Could you rephrase the question but with the word 'flashlights' in place of 'candles'?
Also, feel free to get off my lawn after that.
Re: (Score:2)
USB sticks! What's this about USB sticks! In my day (before Win98 with your little USB support) we had floppies (the real floppy ones, not the little dinky things the older kids stopped playing with recently) and we liked it!
64-bit time EXCEPT... (Score:5, Interesting)
... 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...
Friday, February 13th at 1831 (Score:2)
First thought: "Wait, wasn't that almost 180 years ago?"
Coincidence (Score:2)
the UNIX epoch 'roll-over' would happen about the time that the sun burnt out.
Perhaps the roll-over will be the cause of the sun burning out.
what about outside US (Score:2)
alex@quadruped:~$ perl -e 'printlocaltime(1234554321)
Sat Feb 14 06:45:21 2009
So I call insensitive clods.
Re:so what? (Score:5, Funny)
Wow, you must have a hard time finding joy in anything.
Re: (Score:3, Interesting)
11.23 seconds later UNIX time will reach 10^11/3^4. You can celebrate that instead.
Re: (Score:2, Funny)
Re:so what? (Score:5, Funny)
However, considering that OSX is based on BSD, you can also get Apple pi.
Re: (Score:2)
If you think people get crazy about pi day wait till you mix pi and unix.
Mmmm... pi...
Re: (Score:2)
Actually thats too big to be stored using a 32 bit number, so the localtime function wraps it around to: Wed Jun 14 11:09:18 1933
Re:so what? (Score:4, Funny)
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?
Re: (Score:2)
Protip: the women who bother reading this story are probably at least somewhat interested in the subject, and thus won't be impressed by you showing how uninterested you are.
Re: (Score:2)
Protip: the women who bother reading this story are probably at least somewhat interested in the subject, and thus won't be impressed by you showing how uninterested you are.
Yeah because if one thing from my post is clear, it's that I'd totally go for a chick that'd find his comment interesting. Maybe I could flirt with her by tugging on her third ponytail.
Re: (Score:2)
Hmm. I don't know what posessed me to make that post, but I wish I hadn't. That was shitheaded and patently undeserved. I'm sorry.
Re: (Score:2)
Re: (Score:3, Informative)
I'm going to quit work before 2147483647 because I don't want to update all my code.
Re: (Score:2)
I mean seriously... why is 1234567890 such a special timestamp? Where was the article when we crossed 123456789 ? :)
I'm not quite sure or not whether you've noticed that 123456789 would be 1973? This is a couple of years before Taco got around to starting this heap of junk.
Re:Must be a slow news day.. (Score:5, Funny)
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."
Re: (Score:2)
Quit whining, that means there were be guaranteed work for a bunch of coders in 2038 that would probably otherwise be unemployed or going nuts in retirement.
Then a bunch of whiny MS fanboys will all be saying OMG we fixed that back in 2000, Linux iz teh suXX0rz.
Though I'm hoping that by 2038 MS would have already received the flaming death it deserves, Bill Gates will have died from some horrible disease he picked up while exploiting third world children, Linux will have dwindled down to 3 or 4 fairly unifi
Re: (Score:2)
As for Linux using 64-bit time, that's great, but many applications still were compiled with a 32-bit time_t
Some time near 2025 redhat or whoever is putting out business distros will announce there entire repo is compiled with 64bit time_t with all databases will use 64bit integers for dates by default.
They'll have issues just like the Year 2000 issues that were a problem 10 years ago.
Erm where there any Y2k issues? most of the world ignored them and got by fine
Y2k issues... nine years later (Score:2)
And you can google for some who didn't get by Y2k... [google.com]
Re: (Score:2)
Astronomers have long been doing this by using the Julian day [wikipedia.org] in their records. It's convenient because not only does it ignore things like years (avoiding any issues caused by the change from the Julian to the Gregorian Calendar) it makes it easy to calculate intervals because it's just the number of days since an arbitrary starting point. And, because it counts the days since Jan 1, 4713 B
Re: (Score:2)
I'm a Neanderthal, you insensitive clod!
Re: (Score:2)
The rest of the world is enjoying Valentine's Day with people important to them. Damn :)
That's OK, we'll enjoy Valentine's Day on the 14th where it belongs.
So technically you can't be 14 ! ;) (Score:2)
Since you are just born ... ..
You would be born around 792639715 if I'm not wrong in my math