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."
Re:so what? (Score:3, Interesting)
11.23 seconds later UNIX time will reach 10^11/3^4. You can celebrate that instead.
Re:Why perl? (Score:2, Interesting)
why command-line? (Score:5, Interesting)
Re:scalar() unnecessary (Score:5, Interesting)
Fri Feb 13 13:45:21 2009
Apparently a palindrome is one the same day!
For about half the world .... (Score:4, Interesting)
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...
Re:Must be a slow news day.. (Score:1, Interesting)
MS didn't fix it back in 2000. MS never got it wrong in the first place. Time in Windows has always been been defined as a 64-bit count of 100ns increments since 1900, with negative numbers representing time before 1900, well into pre-history.
The Windows clock range is a 58,455 year range, from ~ 29K B.C. to +29K A.D.
This 2038 issue is and always has been a Unix bug.
Even the original Mac OS used January 1901 for its epoch, so again, this has /always/ been a Unix/Linux bug.
Re:Leap seconds (Score:1, Interesting)
I love how on slashdot people who are COMPLETELY wrong can get mod'ed +5.
POSIX defines time_t to be leap second ignorant. Therefore leap seconds like last 12/31's 23:59:60UTC do NOT have a time_t associated with them.
Now sure, if you have a disconnected machine it will count it -- the kernel has no idea when leap seconds are going to be declared in the future so it just keeps counting up ticks. However, if you have a machine synchronized via NTP (or anything else) it will slow the clock down to "paper over" the fact that an extra second arrived.
That's why you DON'T EVER have to do a multiply or divide by 61 since every minute in POSIX is defined as having exactly 60 seconds. Notice how this story is about time_t==1234567890 and it's happening at 30 seconds past the minute? It's not a coincidence that both of those numbers are divisible by 10.
Re:Posix != unix (Score:1, Interesting)
Your example illustrates localtime() behavior, *not* time() behavior.
...and you're still wrong. You can't divorce them like that. Follow along, please:
1. POSIX defines the meaning of the time_t timescale
2. As already illustrated, leap seconds DO NOT HAVE a POSIX time_t value associated with them
3. POSIX defines time() as returning the current time as a time_t
4. POSIX defines functions like localtime() as taking a time_t argument
5. Contrary to your ridiculous point that "Posix != unix", every UNIX you've ever heard of follows this convention.
Now what happens when a leap second occurs and your machine isn't synchronized via ntp (or whatever)? Well, the kernel increments the value of time() just like any other second. That doesn't mean that time() is defined to include leap seconds, it means THAT COMPUTER'S CLOCK IS NOW WRONG and is returning an inaccurate value for time(). Of course, since you're not running NTP you probably don't know or care that your clock is now one more second off. Since most undisciplined computer clocks will drift more than a second every few years the error from unaccounted leap seconds isn't your primary source of time() inaccuracy anyway.
The fact that time_t is a POSIX-standardized timescale is not some minor detail here -- it means that they can be (and are) shared by network protocols, etc and have an agreed-to meaning across machines.
If you are regularly synchronizing your kernel's clock via NTP, rdate, or anything else you WILL see time() change (either by skewing the rate, or jolting the time backwards) So, yes, time() is following the POSIX convention for leap seconds, albeit in an ugly fashion.
The fact that on some OSes you can change this behavior by setting TZ=right/* does NOT change this. What you're saying when you do that is "I am using a non-POSIX timescale for time_t with my kernel, and I want libc to use that" This isn't something that you do lightly because:
1. You break any (POSIX-compliant!) application that does its own manipulations on time_t values. Just because localtime() knows what's going on doesn't mean everybody else does.
2. You also break anything that relies on tv_sec<60... and there can be all kinds of subtle dependencies on that. (Are you sure nothing on your system parses a logfile with a regex that includes ":[0-5]\d"?)
3. Since your time_t timescale is now non-standard anything that communicates a time_t over the net to another machine is potentially busted. (Think modtimes of files in NFS)
Just because you CAN (with some effort) convince your machine to behave in a manner that deviates from the standards does not mean the standard does not exist. Further, TZ=right/* is not normal practice on any UNIX I've ever seen (and, believe me, I've seen a lot of them over the last 20 years) -- it's purely for people who have very special needs wrt timekeeping and are running a very well-defined set of programs that they know are safe to use with a non-standard time(). I doubt one in 100,000 UNIX machines are configured to use TZ=right/* (and it certainly is not described in POSIX) so it's only relevant to this discussion as a footnote.