Re: Ambiguous NTP timestamps near leap second

[Rob Seaman]

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