On 2015-03-09 02:10 PM, Tom Van Baak wrote:
leap59 and leap61 are Leap Second announce signals, set 12 hours prior
to the insert. There has been discussion about when the official
announcements and expiration should be announced. ITU Rec 460 says
"...at least eight weeks in advance". PTP can't do that, a point to keep
in mind.
Hi Tom,
You've got to be kidding. Who on earth decided on only 12 hours notice?
IEEE 1588, I guess. Remember, 1588/PTP is intended primarily for
synchronization via "TAI-like" PTP Time over LAN networks. It requires
special switches supporting the various "Profiles" to have it work
correctly with high resolution. It can carry UTC metadata but it looks
all the world to me to have been a secondary consideration in the
design. You've seen some of my comments about how I think it's
definition of its epoch is flawed or misleading.
And 8 weeks is wrong too, for a different reason.
That's in the primary document ITU-R Rec 460 we generally base part of
our "UTC specification" knowledge on, and the very document at the heart
of the "kill Leap Seconds" discussion. It says - "The IERS should decide
upon and announce the introduction of a leap-second, such an
announcement to be made at least eight weeks in advance.". This they
generally do as far as I know, as Bulletin C. I've never been able to
locate any official IERS policy that defines any schedule or rules about
when they will in fact issue Bulletin C.
You can have 8 weeks of notice (or 6 months or 100 weeks) as long as you are
given the actual future date of the leap second, as is done with GPS. You can
get away with single warning bits too, as long as they apply to current month
only, as is done with WWVB. Both of these are models on how to send out leap
second notifications correctly.
Ah, well, "correctly" I guess - they can "work", but their promised
schedule is not the *same*.
But allowing 8 weeks without a way to know which month it will occur in is
wrong. For bit-only leap second warnings 4 weeks is the limit.
Many timekeeping systems seem to be designed for only indicating "now"
counting forward, including NTP, POSIX, and PTP, taking short-cuts to
avoid supplying full Leap Second and local-time metadata. I've never
been able to understand why that practice persists despite the obvious
need to be able to fully represent the entire post-1972 UTC timescale.
The policy and forms of the announce signals and Leap Seconds table are
obvious missing links, and its regrettable no official attempt has been
made since 1972 to rectify those inadequacies.
I think ITU-R will have no choice but to stay with current policies
because UTC with Leap Seconds is now too deeply embedded in timekeeping
legacy and can't realistically be excised. Their decision would be
easier if some credible proposal(s) had emerged, and its too bad the
"kill Leap Seconds" argument has diverted all attention and resources
from any effort to fix the situation. But I'd bet its still going to be
necessary.
-Brooks
/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
