I've just discovered that Unix time does not include the leap seconds. I think it's quite surprising because doing that, it is slowly diverging from UTC… but that's not the point of my question.
Edit (3x): in brief, see below and comments for more discussion:
Assuming the system clock follows Unix/POSIX time (not "real" UTC), how to get the real number of seconds elapsed since Unix epoch (from date
or any other program)?
Or, at least, is there somewhere a "leap seconds" file in Linux where I can get the leap seconds without downloading them manually?
Explanation on how I arrived to the conclusion that my system clock is set to Unix time:
Reading the following lines from this link suggested by Richm:
As a result, for the most precise determination of epoch relative to the historic Gregorian calendar and UTC timescale, the user must subtract from the apparent NTP or POSIX epoch the relevant offset provided by the IERS.
Explanation on how I arrived to the conclusion that date --utc +%s
really gives what we call "Unix timestamp":
The first leap second was introduced on June, 30th 1972.
Between 01 Jan 1970 00:00:00 (Unix epoch) and 01 Jul 1972 00:00:00, we can easily compute that there were 365 + 365 + (31+29+31+30+31+30) days + 1 leap second = 912 days + 1 leap second = 78796801 seconds. Now try date -R --utc -d @78796801
… Output: Sat, 01 Jul 1972 00:00:01 !! If you thought (as I did before) that Unix timestamp directly gives the number of seconds elapsed in our real world since 01 Jan 1970 00:00:00… its wrong!
This example proves that date
considers the value after the @
as a real Unix timestamp and gives the correct corresponding date following POSIX time definition. But how to use the same value and say that this is not a timestamp but a number of real seconds since the epoch?…
[Don't read the following: wrong initial assumption, I keep it for "memory"]
date -R --utc && date -R --utc -d @$(date --utc +%s)
Interpretation of the command line:
The first date
gives the date set on my computer in UTC; the $(date ...)
gives the Unix time, i.e. the number of seconds since Unix epoch minus the (25 this day) leap seconds; the date
using this Unix time as parameter should then give a date 25 seconds in the past compared to the first command if it didn't manage properly the leap seconds. It's not the case, thus date
must be "leap seconds-aware".
Best Answer
I didn't find a simple solution to my question, so I've written a small Bash script to solve it. You need to download the leap seconds file given in the link below and put it with the script or change the path to it. I didn't write
utc2unix.sh
yet, but it's very easy to adapt. Do not hesitate to comment/give suggestions...unix2utc.sh:
Just some tests:
date --utc +%s && ./unix2utc.sh
-> today and at least until June 2015 the difference is 25 sec../unix2utc.sh 78796799
->78796799
./unix2utc.sh 78796801
->78796802
./unix2utc.sh 78796800
->78796800
+ on stderr:Warning: POSIX time ambiguity: 78796800 matches 2 consecutive values in UTC time! Only the smallest value is given.