The Quickly Descending Unix Timestamp

Teach writes: "If my calculations are correct, on Thursday, April 19, 2001, at 04:25:21 UTC (00:25:21 EDT and late Wednesday at 21:25:21 PDT), the UNIX clock will read 987654321, which is pretty cool. This will be the first of two such "significant" events in 2001, the second being 01:46:39 UTC on 2001-09-09, when the clock will read 999999999 (and then of course "roll over" to 1000000000 one second later). Use the Time Zone Converter to help you figure out when this will occur in your area, or read up on other critical dates (such as when the 32-bit signed UNIX clock overflows in 2038)."

Comments

Are we coming up to an "S1B" bug?

[Speare]

Not many programs are gonna care how many digits are in a timestamp, but I bet some do try to format stuff assuming a less-than-one-billion-seconds-since-epoch time.

Review your code?

Re:Are we coming up to an "S1B" bug?

[edhall]

There is another 999999999 rollover problem. Some admin scripts (in BASH, PERL, etc.) assume that the decimal timestamp can be compared as an ASCII string. Unfortunately, 999999999 > 1000000000 in this case, which can cause such scripts to break in subtle or overt ways. For example, if TS1=999999999 and TS2=1000000000, the BASH statement:

if [ $TS1 ">" $TS2 ]; then

will evaluate as true.

-Ed

It's like an odometer

[Slashdot Cruiser]

Fortunately, the Unix internal clock works in a manner very similar to the odometer on the Slashdot Cruiser. When you go to trade in your Unix system and step up to Windows, all you have to do is crack open the little block box inside your machine and roll it back several hundred thousand milliseconds.

Nobody will know the difference save the occasional hidden-camera "consumer protection" reporterette. These people seem to have nothing better to do than spy on semi-honest computer salesman and publicly humiliate them for the crime of trying to feed their families. We could talk about the silliness of having to disclose whether or not your computer had its case straightened after a minor plastic-bender, but that would be a whole nother post....

Using Perl....

[ajs]

So, you have a UNIX timestamp you want to check out? Try Perl on the command-line:

perl -MPOSIX -le 'print ctime(999999999)'
perl -MPOSIX -le 'print ctime(987654321)'

For another timezone, you can just set the TZ environment variable. On the command-line, or in the code:

perl -MPOSIX -le '$ENV{TZ}="CST";print ctime(200)'

Actually, because there are historical reasons for ctime supplying a newline, you can drop the "l" from "-le".

Java time

[andyh1978]

3E08 approx. - Java time fails - (64-bit signed milliseconds from 1970) - A.D. 292,278,994-08-17 Sun 07:12:55.808 GMT

I knew Java was over-engineered, but this is taking things a bit far. :-p (and possibly being a little optimistic on the popularity of Java over the next 292 million years)

Look, ma, no modules!

[J'raxis]

No module needed:
perl -le 'print scalar gmtime(999999999)'

And of course localtime() for your own timezone.

...I am the Raxis.

Also.....

[ZanshinWedge]

In case you were wondering, unixtime 123456789 occured on
Thu Nov 29 13:33:09 1973
(please do not waste mod points on this post, thanks)

Re:"One Billion Seconds of Unix"

[isomeme]

I dunno, but that sounds like one of the best excuses for a geek party I've ever heard.

Predicted party song:

One billion seconds are stored in time_t,
One billion seconds of time;
Decrement, post an event,
Nine hundred ninety-nine million, nine hundred ninety-nine thousand, nine hundred ninety-nine seconds are stored in time_t...

--