Re: [Ntp] Leap second draft

[Warner Losh <[e-mail]>]

On Sat, Mar 30, 2019 at 11:06 AM Daniel Franke <[e-mail]> wrote:

> On Sat, Mar 30, 2019 at 11:29 AM Kurt Roeckx <[e-mail]> wrote:
> > I think this is all not very relevant for NTP where we care about
> > the current time, not about what happened in 1972. I'm not sure
> > we need all that historic information in the draft.
>
> My earlier, off-list reply to Steve was:
>
> > I'll do my best to revise the background on historical UTC and TAI so
> > that it is fully accurate while not overwhelming the reader with
> > information that isn't necessary for understanding the rest of the
> > draft. Patches welcome if they meet those desiderata.
>
> I've put the XML source for my draft into a git repo at
> https://github.com/dfoxfranke/ntp-leap-seconds. The latest HEAD has
> revised text which I think should be satisfactory.
>

https://www.itu.int/rec/r-rec-tf.460/en says the latest version is TF.460-6
published in 2002. There's a TF.460.5 published in 1997, but nothing
published in 1996. You should reference this.

I'm not sure that the definition of SI second adds anything to the
explanation of TAI time.

I'm not sure that saying TAI time is a physical manifestation of TT time is
useful, and later references to it.

I'd omit that these clocks are authoritative. TAI is a paper time scale
that's based on the input of these clocks, but no one clock in it is
authoritative and there's no real-time realization of TAI anywhere, just
national standard's lab's UTC. If you are going for simplicity, these
details can be omitted because they won't affect the implementation, nor
the necessary bits of timekeeping needed to understand the rest of the
document.

TAI did not measure solar seconds prior to 1972. You should not mention
that, as it is misleading. I'd opt instead for the more bland "The NTP
timescales assume nothing about TAI and UTC prior to 1972." instead. There
will be no NTP time exchanges for those times, so keeping it simple and
reducing the fiction here would be good.

A reference to the POSIX standard would be likely be helpful.
http://pubs.opengroup.org/onlinepubs/9699919799/ has the definition, and
the reference on all the pages is "The Open Group Base Specifications Issue
7, 2018 edition IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)"

POSIX does not assign a value to the leap second. To say it embraces the
ambiguity by giving it any specific value goes farther than POSIX actually
goes. Since it doesn't exist in the POSIX world view, you cannot say the
standard assigns a value to it. You can read the section on time conversion
to maybe imply this, but it's not explicit as leap seconds simply do not
exist in the POSIX time scale (the reading is by setting seconds to 60
which is the second after 59 which does translate to the first second of
the next day, but the POSIX standard makes no statement on the value of
leap seconds in a time_t because leap seconds don't exist in that time
scale: this is the crux of all the heartburn we have today with them).
POSIX totally punted on leap seconds, alas.

POSIX does not specify that time_t is 32-bit. It merely specifies it must
be an integer type (which is a narrowing of the allowed types from ISO C's
numeric type). There are many implementations that have 64-bit time_t. So
strictly speaking, it's not a POSIX 2036 problem, but rather a historic
representation of time_t problem. There are many system that are POSIX
compliant that don't have the 32-bit issues.

ELI likely should be specified relative to the receive timestamp. It would
be good to specify what happens in the next second after the leap second.
Some historic implementations kept these values on for some number of hours
after the transition because their upstream sources kept them on due to
bugs or ignorance. In the past, I've had to filter this data on the first
day of the month to prevent inferring a leap second that's not really
there, for example. This has been a decade ago, but the ambiguity stuck
with me. Adding that it SHALL be cleared after the leap second will
suffice, though it could be set to '11' as well (though given at least 3
months between leaps, clearing will give the right answer for the month).
It may be important to note as well if the ELI in this extension tracks the
LEAP INDICATOR or not, since '00' means we don't know the if there's a leap
at the end of the month, and the leap indicator is a SHOULD be cleared all
days but the last day of the month.

Sorry for the maybe nitpicky stuff here. Too many years of being on the
leap seconds mailing list...

Warner