[ntp:questions] Re: Make NTP timestamps leap-second-neutral (like GPS time)

David L. Mills mills at udel.edu
Wed Jan 7 19:22:24 UTC 2004


The leapseconds table, including the current offset, is enclosed in an
extension field. Since it is not large, I didn't think it useful to have
a dedicated offset field nor to disturb the current NTP header format.


Terje Mathisen wrote:
> Danny Mayer wrote:
> > hack at watson.ibm.com (Michel Hack) wrote in message news:<61706c80.0401062158.720939a7 at posting.google.com>...
> >
> >>Proposal:
> >> ---------
> >>
> >> Currently, NTP timestamps are defined to represent UTC based on a sliding
> >> epoch such that UTC can be derived from seconds-since-epoch using simple
> >> Gregorian conversion (where each day has exactly 86400 seconds).
> >>
> >> I propose to redefine NTP to be tied to TAI (International Atomic Time)
> >> but referenced to 2000, so that:  NTP(2000) = UTC(2000) = TAI-32 = GPS-13
> >> and from now on:  NTP = TAI-32 = GPS-13
> >>
> >> This is a good time to propose such a change.  There have been no leap
> >> seconds since July 1999.  I wish I had done so sooner (this here is based
> >> on an internal memo I wrote a year ago).
> >>
> > You need to turn this into an RFC proposal and then argue it out with
> > Dave Mills who is the real expert in this area. Interoperability between
> > old and new protocols is essential for NTP to continue to work. In addition
> This is crucial part, I do like your suggestion that the TAI(NTP)-UTC
> offset should default to zero, unfortunately I'm afraid that we might
> not have any free room in the packets. :-(
> My suggestion would be to use some previously unused combination of the
> leap bits, and either simply forget about broadcast (at least for now),
> or send out two different versions of the broadcast packets, with the
> new format setup in such a way that they will look to be invalid to
> current clients.
> > if a proposal is put out I'm sure there are other features that people
> > might want to add to such a change in the protocol.
> Terje
> --
> - <Terje.Mathisen at hda.hydro.com>
> "almost all programming can be viewed as an exercise in caching"

More information about the questions mailing list