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
perl -le 'print ~~localtime 1234567890'
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
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 again.
Fortunately, the one who's wrong is you. Unix time counts the (milli)seconds elapsed since the Unix epoch, full stop. When leap seconds are introduced, they elapse just as well as normal seconds, although every minute, hour, day, week, month, year etc containing will be one second longer (e.g. the minute will be 61 seconds long instead of 60 seconds long). So you only care about leap seconds and Unix time only when you have to convert from Unix time to human-readable form, or conversely, because instead of simple divisions and multiplication by the usual 60 seconds you'll have to interspread some division/multiplication by 61.
"I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
So you only care about leap seconds and Unix time only when you have to convert from Unix time to human-readable form
I never knew Unix could see into the future. But how else could a 1995 version of Irix (for example) correctly convert Unix time to human readable time taking all the subsequent (and unpredictable) leap seconds into account.
Oh, that's right, it doesn't. And neither does it take pre-1995 leap seconds into account.
If Unix time worked as you suggest it would be impossible to unambiguously represent times in the future (because you wouldn't know how many leap seconds were going to elapse). Consequently, Unix doesn't work like this. Or, to be completely anal, POSIX doesn't work like this. You may be aware of some Unix variant that does.
Read this for enlightenment.
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.
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
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
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
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.