Subject: [Ntp] Leap second draft

From: Daniel Franke <[email-masked]>
Date: Wed, 27 Mar 2019 17:46:12 +0100

I'm writing up an I-D clarifying how NTP implementations are to behave
in proximity to a leap second and also introducing an extension field
that provides better leap-second-related information than is
expressible using header fields alone, including giving the TAI-UTC
offset.

Karen, you mentioned a possible CfA for
draft-stenn-ntp-extended-information if Harlan revises it to comply
with RFC 7822 (-04 does not appear to comply). Our two drafts are
partly redundant in purpose since they both provide TAI-UTC offset and
we won't want to adopt both. Of course I think mine is the one we
should adopt, but I'll strive to get a -00 submitted promptly so that
they can be considered side-by-side without unduly delaying Harlan's
CfA.

---

From: Daniel Franke <[email-masked]>
Date: Fri, 29 Mar 2019 20:57:42 +0100

I screwed up the datatracker submission by typoing my email address,
but here (attached) is draft 00 while I'm waiting for the secretariat
to get the submission unstuck.

---

From: Tony Finch <[email-masked]>
Date: Fri, 29 Mar 2019 23:37:05 +0000

I like the basic idea of this draft, and the introductory material is pleasingly thorough (though I confess I have not read it carefully).

There are a couple of problems with the details.

The specification for UTC allows leap seconds to occur at the end of any month, although June and December are preferred. This draft only allows them every six months, so it cannot implement TF.460 faithfully. (The reference to TF.460 in the draft seems a bit broken to me - the short name includes 1996 but the latest version of TF.460 is dated 2002.)

The draft only includes a leap warning for the future, not for the recent past. If a system is doing leap smear, and is rebooted shortly after a leap second, it might lose its smear state and be unable to reconstruct it by talking to its NTP servers, and instead think its clock is wrong. It will then reset its clock to a non smeared time, so it will be a few hundred milliseconds out of phase with the rest of its cluster.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Daniel Franke <[email-masked]>
Date: Fri, 29 Mar 2019 23:05:00 -0400

Good points all around. I'll incorporate these into the next draft.

---

From: Warner Losh <[email-masked]>
Date: Fri, 29 Mar 2019 22:17:58 -0600

At the inception may be hard to show they were equal due to historical
accidents that were papered over because TAI is a paper time scale not
realized in real time. At the epoch of TAI, the difference is accounted to
be zero. Also, prior to 1972 leap seconds weren't a thing. Instead
frequency offsets and small leaps kept things in sync. The delay at the
start of the era was 10 seconds to give the offset a whole number of
seconds.

Warner

On Fri, Mar 29, 2019, 9:05 PM Daniel Franke <[email-masked]> wrote:

> > I like the basic idea of this draft, and the introductory material is
> pleasingly thorough (though I confess I have not read it carefully).
> >
> > The specification for UTC allows leap seconds to occur at the end of any
> month, although June and December are preferred. This draft only allows
> them every six months, so it cannot implement TF.460 faithfully. (The
> reference to TF.460 in the draft seems a bit broken to me - the short name
> includes 1996 but the latest version of TF.460 is dated 2002.)
> >
> > The draft only includes a leap warning for the future, not for the
> recent past. If a system is doing leap smear, and is rebooted shortly after
> a leap second, it might lose its smear state and be unable to reconstruct
> it by talking to its NTP servers, and instead think its clock is wrong. It
> will then reset its clock to a non smeared time, so it will be a few
> hundred milliseconds out of phase with the rest of its cluster.
> >
> > Tony.
> > --
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "Dieter Sibold" <[email-masked]>
Date: Sat, 30 Mar 2019 11:21:55 +0100

Just a short note. At 1972-01-01 the difference between TAI and UTC was 
10s. You might introduce the link to
https://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history

- Dieter

Dieter Sibold
[email-masked]

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Mar 2019 09:12:04 -0400

Steve Allen noted this as well as some other historical nits. He
forgot to copy the list; I've asked him to resend.

---

From: Steve Allen <[email-masked]>
Date: Sat, 30 Mar 2019 06:33:48 -0700

Daniel Franke notes that I did not send this and the
next message to the list.

Greetings Daniel Franke,
On Fri 2019-03-29T20:57:42+0100 Daniel Franke hath writ:

> Network Working Group                                          D. Franke
> Internet-Draft                                                    Akamai
> Updates: 5905 (if approved)                               March 29, 2019
> Intended status: Standards Track
> Expires: September 30, 2019

>    At their inception in 1972, UTC and TAI were equal.  Since then,

No, please look at the second plot on
https://www.ucolick.org/~sla/leapsecs/amsci.html
and at the third plot on
https://www.ucolick.org/~sla/leapsecs/deltat.html

As of 1972 TAI - UTC was reset to exactly 10 SI seconds
Since then there have been 27 leap seconds.

>    Both TAI and UTC are canonically represented by a count of days,
>    hours, minutes, and seconds (including fractional seconds) since
>    their epoch at solar midnight at the prime meridian on January 1,
>    1958.

The epoch of the TAI that we now have is 1961-01-01T20:00:00 UT2
see the reason why at
https://www.ucolick.org/~sla/leapsecs/taiepoch.html

There was also a step in that time scale on 1962-01-01
because of the change of the canonical formula for UT2 and
the change from FK3 catalog to FK4 catalog.
https://www.ucolick.org/~sla/leapsecs/seasonal.html

These events are documented in issues of Bulletin Horaire.

Also note that the rate of TAI was modified by a step
on 1977-01-01, and other rate changes have been applied.

>           While neither TAI nor UTC is formally defined for any date
>    earlier than the epoch, this nit is routinely ignored by allowing the
>    day number to be negative and by assuming the fiction that prior to
>    1958 Earth's rotation was always perfectly regular with respect to
>    proper time.

Which epoch?  POSIX epoch?
Any date at which there is general agreement among all parties
about when it happened is an epoch.  Please be specific and
never use merely "the epoch".

TAI was not defined until 1971-10-04 when the CGPM authorized it.
Before then there were only various atomic time scales of
various agencies.  It was the atomic time scale of the BIH that
became TAI.

UTC was not named by any official document until 1974-07 when the 13th
Plenary Assembly of the CCIR approved Recommendation 460-1.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Steve Allen <[email-masked]>
Date: Sat, 30 Mar 2019 06:35:55 -0700

This is the second message to Daniel Franke.

> never use merely "the epoch".

To expand on my objection here, I find these sentences to be
unconnectable to any concrete concepts.

There is a common strategy in time scales which are trying to be a
precision time scale now, but which also wish to extend themselves
simply to an era before there was precision.

As such time scales are extended backwards in time there is some
past epoch at which the scale switches tracks and connects itself
to just plain Universal Time.  So such time scales are counting
SI seconds now, but going into the past they switch to counting
mean solar seconds.

They do not presume that the mean solar seconds were perfectly
regular, they just change from one kind of second to the other.

For radio broadcast time signals the change happened 1972-01-01
because that is what the CCIR said in Recommendation 460.

For Microsoft Windows the change happened 2018-06-01 because
that is what Microsoft said is the date that they begin to
distribute TAI offset from UTC so that Windows boxes can
count subsequent leap seconds.

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 30 Mar 2019 15:57:37 +0100

On Fri, Mar 29, 2019 at 08:57:42PM +0100, Daniel Franke wrote:
> 3.  The Leap Data and Era Number extension field
> 
>    The Leap Data and Era Number extension field SHALL be formatted as
>    shown in Figure 1.
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |          Field Type           |            Length             |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |ELI|F|R|X| res |                   Era Number                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         TAI-UTC Offset                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    .                             Padding                           .
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>          Figure 1: Leap Data and Era Number extension field format
> 
>    The fields are defined as follows:
> 
>       Field Type: MUST be set to [[TBD]].
> 
>       Length: The length of the extension field as specified by
>       [RFC7822].
> 
>       ELI: The Extended Leap Indicator, as specified below.
> 
>       F: When set, indicates that the Reference Timestamp was captured
>       during a leap second.
> 
>       R: When set, indicates that the Receive Timestamp was captured
>       during a leap second.
> 
>       X: When set, indicates that the Transmit Timestamp was captured
>       during a leap second
> 
>       res: These three bits are unused and reserved.  Senders MUST set
>       them to 0.  Receivers MUST igonre them.
> 
>       Era Number: The era, as defined in [RFC5905], during which the
>       Receive Timestamp was captured, given as an unsigned 24-bit
>       integer in network byte order.
> 
>       TAI-UTC Offset: The value DTAI as defined in [ITU.T4.1996],
>       expressed as a 32-bit signed two's-complement integer in network
>       byte order, as of the time reflected by the Receive Timestamp.  If
>       the Receive Timestamp is captured during a leap second, the given
>       TAI-UTC SHALL be as of just prior to the beginning of that leap
>       second.

In some other mail you wrote:
> However, I do note that the current draft implements only part of what
> I recommended, and I think it would be further improved by doing the
> rest of it as well. To reiterate what I recommended, in place of the
> current LEAP tag, provide the following three tags:
> 
> MRLS - a TAI timestamp representing the time at which the
> most-recently published leap second ends. This may be in either the
> future or the past.
> 
> LSDI - A bit indicating whether the leap second given in MRLS is an
> insertion or a deletion.
> 
> UTCO - What the TAI-UTC offset was or will be as of the time given
> in MRLS.

So I'm wondering why this MRLS is not part of this draft and that
ELI is 2 bits instead of the 1 bit LSDI.

Using that combination would at least avoid the comments about it
being possible to have a leap second every 1 or 6 months.

Kurt

---

From: Warner Losh <[email-masked]>
Date: Sat, 30 Mar 2019 09:02:05 -0600

The only things I see missing from these very good notes were the rubber
leap second era from 1962 to 1972. And that different timescales tick at
different rates. It's implicit in the last draft, but also important to
call out that 1 second is an ambiguous term once you get away from UTC and
TAI.

The most common universal time today is UTC. UT1 is only common to the
extent that UTC is steered to it. Legal time is defined as mean solar many
places, but UTC is the defacto legal time most places, but few have it
codified in law (most, including the US, do it in regulations).

And Steve's email touched only on a small fraction of early time keeping
causing small steps here and there. In addition to the different formulas
for UT, there were mistakes made when the actual royal observatory moved
and other historical trivia. I mention it because times from before 1972
are fraught with issues like this and a whole slew of others. So any time
stamp before UTC was defined has a lot of issues around its use. Of course,
Steve has all the details of these 9n his web site.

Warner

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 30 Mar 2019 16:23:54 +0100

On Fri, Mar 29, 2019 at 08:57:42PM +0100, Daniel Franke wrote:
>    When a deleted leap second or any portion of an inserted leap second
>    intervenes between when the Receive Timestamp is captured and when
>    the Transmit Timestamp is captured, the result is likely to be
>    misinterpreted by any receiver which does not implement the Leap Data
>    and Era Number extension field.

I'm not really sure what you mean here exactly. But I think that
for an insert, either the receive or transmit happening during
the leap second can cause problems if this extension is not used.

As far as I understand, during a remove the bits would not be set,
because it's clear what the time of the fields is. In theory we
could assume that client should know about the leap second
happening, and so it should perfectly understand both timestamps
without this extension. But I guess in practice we can't assume
this, and I think not sending a reply does make sense.

I would recommend adding examples for all possible cases.

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 30 Mar 2019 16:29:48 +0100

> Since then there have been 27 leap seconds.
[...]

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.

Kurt

---

From: Steve Allen <[email-masked]>
Date: Sat, 30 Mar 2019 08:41:11 -0700

> we need all that historic information in the draft.

In that case I recommend text something like this:

Although the NTP era and time stamps use pre-existing notation for
time and can represent time before the existence of the first
implementation of NTP, the correspondence between NTP time stamps and
any external time scale is not defined for dates before [insert date
here].

---

From: Warner Losh <[email-masked]>
Date: Sat, 30 Mar 2019 09:42:38 -0600

On Sat, Mar 30, 2019 at 9:29 AM Kurt Roeckx <[email-masked]> wrote:

> > > Internet-Draft
> Akamai

We definitely need that it was exactly 10s in 1972, as opposed to 0. And we
need statements that things were messy before 1972. This information is
'out there' but hard to find and difficult to properly interpret.

And it's less obscure than the crazy notion that leap seconds could happen
any time other than June and December as a practical matter. TF.460 says
those are the primary dates, with March / September being the secondary
dates though at the end of any month is possible. Given the large number of
bugs we hit every single leap second in June and December, March and
September just might work in enough places not to sow chaos, but a leap
second at the end of February would be pure chaos. At least as a practical
matter. Untested code is buggy code.

Warner

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Mar 2019 13:00:43 -0400

> being possible to have a leap second every 1 or 6 months.

The MRLS/LSDI representation I recommended before is better and easier
to work with when you're using TAI timestamps everywhere, and when
that's the case you have a better world overall. So for Roughtime
where the existing deployed base is negligible so we can pretty much
do what we want, that was my recommendation. But NTP uses (pseudo-)UTC
timestamps and I don't want to go back and mess with the semantics of
existing fields. This draft is what I see as the cleanest way to
retrofit better leap second handling onto the existing protocol and
existing buggy implementations of it.

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Mar 2019 13:05:49 -0400

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.

---

From: Warner Losh <[email-masked]>
Date: Sat, 30 Mar 2019 11:45:48 -0600

> 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

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Mar 2019 14:24:16 -0400

On Sat, Mar 30, 2019 at 1:46 PM Warner Losh <[email-masked]> 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."

---

From: Warner Losh <[email-masked]>
Date: Sat, 30 Mar 2019 13:43:48 -0600

On Sat, Mar 30, 2019 at 12:24 PM Daniel Franke <[email-masked]> 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 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.

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

> statement that no leap second is coming, while a 00 in the LI might

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

Warner

---

From: Steve Allen <[email-masked]>
Date: Sat, 30 Mar 2019 12:44:28 -0700

> map/territory distinction between TAI and TT intact.

Note that TT was not defined until 1991.  NTP was already in use.

Note that the definition of TAI did not match the definition of
TT until 2018-11 when CGPM 26 approved Resolution 2.
Note that TT and TAI are now defined at the geopotential level
W_0 = 62 636 856.0 m^2 s^-2
and that chronometers at other potentials run at different rates.

Note that effective 2019-05-20 Resolution 1 of CGPM 26 redefines the
SI such that the fundamental unit is the hertz [Hz] and that the
second [s] will be a derived unit.

So long as civil calendar days are based on measurements of the
rotating earth the long-term behavior of simple differences between
time stamps of UTC and NTP match the mean solar second, not the SI
second.

Are you sure that you want to specify that NTP uses the SI second?

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Mar 2019 16:06:24 -0400

> Are you sure that you want to specify that NTP uses the SI second?

NTP is already specified to use UTC, and trying to change that is far
outside the scope of this draft. UTC is specified in terms of TAI, and
TAI is specified in terms of the SI second. So, as statement of fact,
NTP uses the SI second. All references in the draft to SI are in the
background section, which describes the world as it is without the use
of any normative language. I'm comfortable with the risk that at some
future date, UTC might get redefined with some other basis, and
confident that if this ever happens the normative intent of the draft
will still remain clear.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 30 Mar 2019 13:42:44 -0700

On Sat, Mar 30, 2019, 8:43 AM Warner Losh <[email-masked]> wrote:

> We definitely need that it was exactly 10s in 1972, as opposed to 0. And
> we need statements that things were messy before 1972. This information is
> second at the end of February would be pure chaos.. At least as a practical

Especially in 2020!

---

From: Steve Allen <[email-masked]>
Date: Sat, 30 Mar 2019 16:01:51 -0700

> 'out there' but hard to find and difficult to properly interpret.

Due to ongoing activities like the CGPM meeting last November
specifying things like "9,192,631,770" become obsolete in less than 8
weeks.  For the same reason saying that TAI is like TT risks
obsolescence because of changes in the notion of the geoid, or the
standard geopotential, or some other tweak to the external definition
like the ones that have been made by one or more of IAG, IAU, or CGPM.

The lifetime of an IETF document may be improved by limiting the
amount of reiteration.  Do describe the important and presumed
unchanging properties of the external definition so that if changes
happen in the future the readers can make a judgement about whether to
abandon the existing implementation or ignore the new external
definition.  Then rely on simply citing which external agencies are in
charge of external definitions that are being used by NTP.

Unfortunately for this origins of this subject matter the principals
who were involved with the inception of leap seconds were not happy
with the result.  The contributions to the CCDS meeting of 1972 show
they had decided not to use UTC with leap seconds in their own
systems, they believed that others would be best doing likewise, and
they agreed not to talk about it outside of the folks who had been at
the meetings which resulted in leap seconds.  Their silence left the
story to be told without explanation of reasons and motivations; thus
it became hard to find and interpret.

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 31 Mar 2019 00:52:49 +0100

> Are you sure that you want to specify that NTP uses the SI second?

You seem to be looking NTP time as continues timescales, which
it's not, and that's the reason why this draft exists. In the
parts that it's continues, NTP's seconds are (currently) SI seconds.

Anyway, I think we should avoid defining what things like NTP
time, UTC and TAI is. They should all have external definitions
we can just point to.

Kurt

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Mar 2019 20:35:50 -0400

> time, UTC and TAI is. They should all have external definitions

Where the definitions are normative, sure. But as Steve's infodumps in
this thread rather vividly illustrate, readers need a comprehensible
summary; we can't just incorporate the whole body of relevant
standards by reference and leave it at that. The statements in the
background section aren't normative, and should be accurate but don't
have to be comprehensive. And I won't be worried if, for example, the
quoted definition of an SI second gets superseded a month after the
RFC is published, because the quote isn't there to be authoritative;
it's there to illustrate what such a definition can look like.

---

From: Warner Losh <[email-masked]>
Date: Sat, 30 Mar 2019 21:01:42 -0600

> it's there to illustrate what such a definition can look like.

The current definition doesn't help. A reference to the BIPM with the
latest definition doc at the time of publication would suffice. The hard
part is getting the right pointers.

It doesn't matter what a SI second is. NTP counts them and exchanges that
count. They could be anything. People have done GPS times (also SI seconds)
and UT1 times (solar variable length seconds). They've even done Julian
Time NTP. Now obviously these different time scales won't interoperate, but
they are fine so long as everybody exchanging time agrees on the rules for
the time scale. That brings us to UTC. It's the odd man out. It ticks at a
fixed rate, and occasionally has seconds inserted into it. UTC is related
to TAI by a stepwise function that always increases or decreases by 1. This
increase or decrease historically has always been December or June, but
technically could be at the end of any month. UTC is synchronized to UT1
every so often based on a set of rules. The current rule is that | DUT1 |
must remain < .9s so you move it when you think it might exceed .9 before
the next chance to move it. Other rules are possible, but just like leaps
at the end of any other month than December or June not likely.

So, it makes sense to just hit these points, and give pointers to the
underlying details, which don't matter.

Warner