Re: [LEAPSECS] Ambiguous NTP timestamps near leap second

From: Rob Seaman <seaman_at_noao.edu>
Date: Thu, 16 Feb 2006 22:45:03 -0700

On Feb 16, 2006, at 4:46 PM, Warner Losh wrote:

> UTC rules state that the time sequence should be
>
> 23:59:59.75
> 23:59:60.0
> 23:59:60.25
> 23:59:60.50
> 23:59:60.75
> 00:00:00.00
> 00:00:00.25

Well, no. ITU-R-TF.460-4 says nothing whatsoever about the
representation of time using sexigesimal notation:

        "2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m
0s of the first day of the following month. In the case of a negative
leap-second, 23h 59m 58s will be followed one second later by 0h 0m
0s of the first day of the following month (see Annex III)."

Annex III contains two diagrams indicating the "dating of events in
the vicinity of a leap-second", specifically "30 June, 23h 59m 60.6s
UTC" and "30 June, 23h 59h 58.9s UTC", for a positive and negative
leap second, respectively. Note the explicit combination of a date
and time to represent a specific moment in history (ignoring the lack
of a year for these examples), not a time-of-day. And further, each
field of the date and time is expressed as a separate value.

> The problem is for time exchanges that cross the 0:00:00.00 boundary.

It is the word "boundary" that is the problem. The ITU
recommendation discusses the dating of historical events, not how to
divide one day from the next. We're not discussing an issue with
UTC, but rather with the NTP realization of same.

> Inventing a new notation that is not described in the ITU UTC
> definition is not helpful,
> even if lots of other people use it informally.

Um - I wasn't discussing the notation as any sort of aid in resolving
this problem with NTP. I like the idea of the server simply failing
to respond in the vicinity of a leap-second.

That "lots of other people" use some feature most certainly is an
issue when capturing the requirements for civil timekeeping. Nobody
is suggesting that NTP generate such timestamps - but the ITU cannot
keep people from specifying time any way they want. If two
representations are congruent, why should our standards care?

> It will create confusion because it has no precise definition in
> the UTC standard

As we've seen, the "UTC standard" (really, the ITU recommendation for
how UTC will be constituted in practice) does not address the
representation of time at all. Is this surprising? Sexigesimal
notation applies to multiple timescales, as well as to longitude and
latitude and other spherical coordinates.

> (note: NTP specifically states UTC, and no other standard).

Lots of standards reference other standards. Lots of standards get
it wrong.

Rob Seaman
NOAO
Received on Thu Feb 16 2006 - 21:46:05 PST