[ntp:questions] Re: ntp servers reporting leap second erroneously?

David L. Mills mills at udel.edu
Mon Oct 24 05:06:39 UTC 2005


No, no, no. The DUT1 sign bit indicates the sign of the quantity to add 
to the current TAI - UTC offset to yield UT1. As the offset increases, 
the DUT1 shows first a negative value and gradually increasing 
eventually to positive values. Some time before the field overlows the 
leap is inserted and the DUT1 starts out again from a negative value.

The same thing could work in reverse, should the offset begin to 
decrease, but there would have to be a way to tell from the timecode 
that a second is to be deleted. I have been told by NIST their radios 
can't do that. Of interest to me is whethere other radio services can do 
that. The NTP daemon and kernel can do that if given advance notice.

Why are we having this discussion? Better to consider the issue of doing 
away with leap seconds entirely and retrieving the current UT1 offset 
from IERS via national dissemination means.


Tom Van Baak wrote:

>>There is no provision in the NIST WWV/H/B timecode for a leap deletion
> This is not true. Let me explain in detail below.
>>nor is ther provision in the hardware timecode generators for that. The
> This is true.
>>DUT1 is a signed adjustment to the current UTC to produce UTC1. The
> Yes, and it's this same DUT1 sign bit that tells you
> if the leap second is to be inserted or deleted. Think
> about it... As DUT1 gradually goes from positive to
> negative in 0.1 second increments over the months,
> IERS announces a leap second, and the WWV* leap
> second pending bit is lit. User software reading the
> WWV* subcode can tell if the leap second is positive
> by the fact that the DUT1 sign is negative.
> By contrast if the Earth were to speed up for a while
> DUT1 will be gradually increasing, and as it climbs
> in 0.1 second increments into positive territory and
> approaches +0.9 s, IERS will be forced to declare a
> negative leap second, and WWV* will set the leap
> second pending bit. User software reading the WWV*
> subcode can tell if the leap second is negative by the
> fact that the DUT1 sign is positive.
> So it may be tricky, and not obvious on first reading,
> but the WWV* timecode format, as defined by NIST,
> is capable of handling negative leap seconds should
> they ever occur.
> You and I both know privately that the old transistor
> TCG in Ft Collins can't handle dropping a second at
> this time, but that's hardware. The point I'm trying to
> make is that the timecode format can handle both
> types of leap seconds.
> Provision for negative leap seconds is implicit in any
> timecode that contains both a boolean leap second
> pending bit and a DUT1 sign bit.
>>adjustment changes sign after a leap second to reflect the current
>>offset of UTC1 from UTC. The DUT1 sign has nothing to do with the
>>insertion/deletion of the leap.
> Think about it - the only reason we need leap seconds
> is that DUT1 is non-zero and has a sign. ;-)
> Perhaps code speaks clearer than words. Take a look
> at the WWVB TCG source code at:
> http://www.leapsecond.com/notes/wwvb1.htm
> and
> http://www.leapsecond.com/notes/wwvb2.htm
> Example of leap years, positive, and negative leap
> seconds are posted there.
> /tvb

More information about the questions mailing list