Re: [Ntp] Leap second draft

[Warner Losh <[e-mail]>]

On Sat, Mar 30, 2019 at 12:24 PM Daniel Franke <[e-mail]> wrote:

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

I've read that several times. It does not specify what a leap second is
encoded as, because leap seconds do not exist in POSIX time_t timescale.
Section A.4.16 just talks about encoding the broken down time into a
time_t. Since leap seconds do not exist in the posix world (and are not
mentioned in A.4.16). The relevant bit is not the formula, but the
following text:

"How any changes to the value of seconds since the Epoch are made to align
to a desired relationship with the current actual time is
implementation-defined. As represented in seconds since the Epoch, each and
every day shall be accounted for by exactly 86400 seconds."

Since leap seconds involve an actual time not handled by time_t, how they
are mapped to seconds since the epoch are implementation-defined. This
point has been well litigated in the leap-second mailing list. There is no
canonical encoding of leap seconds in posix. Many implementations do what
you say, but it is not a standard's defined behavior. There are several
implementations that map the leap second to the last second of the day as
to preserve the day of week of the leap second which properly occurs on the
day of the leap second, not the day following (FreeBSD does this, for
example). Days with leap seconds have 86401 seconds as well, which is at
odds with the seconds since epoch. This is the crux of the problem with
leap seconds: there's many interpretations and no proper way to encode the
leap second. Since POSIX forces multiple seconds to be mapped to the same
value, there's no way for a naive application to get things right if it
assume things like time is monotonic.

I'd love for there to be a single, unambiguous mapping here, but that's
simply not how it's actually implemented. It's a common mistake. I'll have
to check the archives of the leap second mailing list to find where Guy
Steele posted about how the committee explicitly rejected the notion of the
leap second having a prescribed value because time_t doesn't have leap
seconds in it at all.

It's a common reading of thee standard, but POSIX since stays silent about
leap seconds (apart from the one reference to 1 value going to 60), it's
really undefined. It's a fundamental problem, imho, with the standard.

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

Ah yes. That's there. I'm not sure how I missed it the first time through.

Warner