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

David L. Mills mills at udel.edu
Mon Oct 24 21:12:17 UTC 2005


Geeze, did I send that many messages? TMI.

The DUT1 sign in my last is incorrect, as Tom points out in a private 
message. The DUT1 is now negative, not positive, and after the leap will 
by postive, not negative.

Interesting factoid: a there is no provision in the WWV/H/B timecode to 
designate a delete second, but there is in the CHU timecode and the NIST 
ACTS timecode. As a weekend project, somebody should make a driver that 
simulates the ACTS service and native timecode. There may be places 
somewhere in the world where that would be useful.


David L. Mills wrote:
> Tom,
> 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.
> Dave
> 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