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."
perl -e 'print localtime(1234567890) ."\n";'
Let the "." concatenate operator do it for you.
Infuriate left and right
The standard unix date command will suffice:
date -d @1234567890
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
Sorry, UNIX time is exactly 86400 seconds per day.
If you read this history of POSIX time 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 perhaps even GPS time which are all defined on different foundations.
You can not assume that POSIX time actually means anything better than the time on your watch does, unless you are fully aware the whole chain.
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
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.
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.
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.