[LEAPSECS] Civil timekeeping before 1 January 1972

[Brooks Harris]

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 at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>