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
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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
Knowledge is power. Knowledge shared is power lost.
in what way is the "second" metric?
How about this way?
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.