Guys,
Tom pricked my gasbag with an intriguing observation. The sign of the
DUT1 is indeed a predictor of the leap second insert/delete. If the sign
goes from negative to positive, insert; otherwise, delete. I was too
full of gas to recognize that wrinkle.
David L. Mills wrote:
Guys,
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.
Dave
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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
