Re: Predictable Internet Time

[Joe Touch <[e-mail]>]

On 1/3/2017 2:33 PM, Tony Finch wrote:
> Joe Touch <[e-mail]> 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