Re: A quick ntp question!

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Sun, 2 Nov 2008 08:40:49 -0800 (PST)
Paul Goyette <paul%whooppee.com@localhost> wrote:

> Does anyone on the list know what date/time format is used by ntp?
> 
> In particular, I'm interested in knowing if ntp exchanges a simple 
> "seconds-since-epoch" value and leaves accounting of leap seconds to 
> end-systems, or if ntp exchanges actual yyyy/mm/dd_hh:mm:ss.fffff 
> values.
> 
The details are in RFC 1305 (and the Postscript version might be worth
getting).  Here's the relevant text:

        Since NTP timestamps are cherished data and, in fact, represent
        the main product of the protocol, a special timestamp format
        has been established. NTP timestamps are represented as a
        64-bit unsigned fixed- point number, in seconds relative to 0h
        on 1 January 1900. The integer part is in the first 32 bits and
        the fraction part in the last 32 bits. This format allows
        convenient multiple-precision arithmetic and conversion to Time
        Protocol representation (seconds), but does complicate the
        conversion to ICMP Timestamp message representation
        (milliseconds). The precision of this representation is about
        200 picoseconds, which should be adequate for even the most
        exotic requirements.


Also note this:

        Leap Indicator (sys.leap, peer.leap, pkt.leap): This is a
        two-bit code warning of an impending leap second to be inserted
        in the NTP timescale. The bits are set before 23:59 on the day
        of insertion and reset after 00:00 on the following day. This
        causes the number of seconds (rollover interval) in the day of
        insertion to be increased or decreased by one. In the case of
        primary servers the bits are set by operator intervention,
        while in the case of secondary servers the bits are set by the
        protocol. The two bits, bit 0 and bit 1, respectively, are
        coded as follows:


                --Steve Bellovin, http://www.cs.columbia.edu/~smb