"M. Warner Losh" wrote on 2006-02-14 21:18 UTC:
> ntp time stampes are ambiguous at leap seconds (the leap indicator
> bits aren't part of the time stamp, exactly), which is a good reason
> to change them. However, the cost to change them could be quite high
> if done in an incompatible manner.
No, this ambiguity alone is surely not a good enough reason to change.
It can be fixed trivially in a backwards compatible way, without
introducing TAI or leap-second status bits. Simply add to the NTP
specification the paragraph:
No reply from an NTP server shall ever represent any point in time
between 23:59:60 and 24:00:00 of a UTC day. If a client requests an
NTP timestamp and the response would represent a point in time during
an inserted leap second, then this request shall be ignored.
Rationale: NTP runs over UDP, and therefore must be (and is perfectly)
able to cope with occasionally dropped packets. Dropping NTP server
reply packets for one second every few years will hardly affect any
application, because NTP clients already implement robust retry
and filtering mechanism today.
NTP is actually one of the simple cases, where no harm is done by simply
going offline very briefly near a leap second. In other applications,
e.g. streaming media, things are not that easy, and other workarounds
are needed if one wants to remain backwards compatible with existing UTC
practice while minimizing the chance of leap-second induced
malfunctions. UTC-SLS is what I'd recommend for most of these cases (but
not for the NTP protocol itself).
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Received on Thu Feb 16 2006 - 11:13:08 PST