Joe Touch <touch@xxxxxxx> 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.
> 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).
:: 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.
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.
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.
Tony.
--
f.anthony.n.finch <dot@xxxxxxxx> http://dotat.at/ - I xn--zr8h punycode