Re: FreeBSD handles leapsecond correctly

In message: <20060101111945.GA42228_at_cirb503493.alcatel.com.au>
            Peter Jeremy <PeterJeremy_at_optushome.com.au> writes:
: On Sun, 2006-Jan-01 10:59:14 +0100, Poul-Henning Kamp wrote:
: >http://phk.freebsd.dk/misc/leapsecond.txt
: >
: >Notice how CLOCK_REALTIME recycles the 1136073599 second.
: 
: Thank you (and others) for your efforts in getting FreeBSD to this point.
: 
: I did find what appears to be two hosts that both held the leap
: indicator as "01", well after the leap second, until I unpeered them.

That's OK.  The 'ins' indicator is only used on June 30 and December
31.  The leap second indicators will stay on as long as the up-stream
servers have them turned on.  Also, there's a 1024 second polling
interval to consider, which can make the indicator persist for hours
depending on the network topology, etc.

: My firewall reset the leap indicator bit at 0030 UTC and the 5.4 host
: reset it at about 0106 UTC.  Neither the 6.0 nor 7.0 systems reset the
: leap bit until I unpeered them at 0500 UTC.  I suspect that both
: systems saw the leap indicator bit in the NTP packets from each other
: and held each other's leap indicator set.  Once I unpeered them, both
: reset their leap indicator bits.

To be pedantic about what NTP does, it will keep the leap bit on so
long as at least one of the peers with a lower stratum has its bit
on.  As I said above, it doesn't matter until June sometime.

Yes, the June and December dates are hard wired into ntpd.  The
primary times are June 30 and December 31.  The backup dates are March
31, September 30, but very few things implement those dates at all
(more devices implement a more generic 'do leap second at the end of
DOY #xxx).  There won't be leap seconds on the alternative dates for
at least tens of years (2030 to 2050 were the time frames that 2x year
leap seconds won't be enough in projections that I've seen).

Warner