On 1/3/2017 2:33 PM, Tony Finch wrote:
Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 1/3/2017 12:34 PM, Tony Finch wrote:
Well, the problem is that "seconds since the epoch" is not a count of
UTC seconds,
Correct; it's UTC-(leap seconds since epoch start).
it is a mapping from broken-down time to a linear time,
Seconds since epoch is as linear as it gets.
Except that that the number of leap seconds isn't constant, so it is
only superficially linear: there is a wrinkle at every leap second.
Leap seconds are still seconds, which are counted in "seconds since epoch".
The conversion of epoch seconds to larger units is where the leap
seconds is counted.
A "day" as a unit of time is not exactly 86400 seconds (if it were, we
wouldn't need leap seconds).
POSIX disagrees with you (and it is in denial about its agreement with
UTC).
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
:: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400
There's no allowance for the number of leaps since the epoch in that
specification.
Denial is not just a river in Egypt ;-)
Try the following (and sorry about the perl, but the date command
isn't portable enough). Note that the difference between the POSIX
time_t seconds since the epoch is 1s (...8800 - ...8799 == 1) but the
elapsed time was 2s.
$ perl -MPOSIX -e 'print strftime "%F %T\n", gmtime 1483228799'
2016-12-31 23:59:59
$ perl -MPOSIX -e 'print strftime "%F %T\n", gmtime 1483228800'
2017-01-01 00:00:00
There is no distinct time_t value for 2015-12-31 23:59:60.
In would presume that the same code would generate a time that is one
second behind UTC right now.
I.e., the Posix code is incorrect in claiming it reports UTC.
To make this message slightly more on-topic for this list, anyone who
cares about this subject should be aware that NTP timestamps work
exactly the same way as POSIX timestamps, except for a constant offset
between NTP time and POSIX time due to the different choice of epoch.
The relevant difference is that POSIX does not specify how leap
seconds are handled, whereas NTP has a couple of extra bits which
allow the next leap second to be transferred (in theory but often not
in practice). NTP also has no distinct timestamp value for the leap
second, except if you include the leap indicator bits.
NTP reports seconds since epoch; it is in the conversion of that value
to display time that the issue of leap seconds comes into play. In that
case, some systems report 59-59-00 and others 59-00-00, i.e, repeating a
UTC value to account for the leap second in the human-readble output.
Internally, the number of seconds which have passed is correct and
include the leap second.
Joe