Re: [Ntp] Leap second draft

[Daniel Franke <[e-mail]>]

On Sat, Mar 30, 2019 at 1:46 PM Warner Losh <[e-mail]> wrote:
> 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've already fixed this, and that's the document I've been working
from the whole time. The citation was messed up because I forgot to
change some copypasta that I took from the xml2rfc citation library.

> 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.

No, these details aren't strictly necessary, but neither do they
excessively complicate things and I think keeping them in leads to
better ontological clarity. I'd especially like to keep the
map/territory distinction between TAI and TT intact.

> 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.

The existing text already characterizes this as a "fiction". And I do
think it's important to mention, considering that the NTP epoch
predates 1972 and the reader needs to be able to make sense of that.

> 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)"

Already on my to-do list; I've promised an email to the RFC editor
about getting it included in the citation library.

> 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 in fact specify exactly what I claim. The definition of
`struct tm` provides for tm_sec to range over [0..60], and in section
"4.16 Seconds Since the Epoch" it specifies how this is to be
translated into a time_t. There's some further discussion in the
rationale volume, section A.4.16.

> 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.

I'm already qualifying with "32-bit systems", which to be slightly
more correct I'll revise to say "systems that use a 32-bit time_t".

> 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.

I think I'm already saying all this, am I not?

"The current month is the Gregorian calendar month determined by the
Receive Timestamp".

"The Leap Indicator SHALL be set to 01 while a inserted leap second is
in progress, and then cleared only after the leap second has ended."
-- okay, I guess I can put a second SHALL in there and/or drop the
word "only", but you'd have to be pretty dense to think some other
behavior was acceptable.

"the semantics of 00 also differ: a 00 in the ELI is an affirmative
statement that no leap second is coming, while a 00 in the LI might
indicate lack of data."