[LEAPSECS] W1K GPS rollover for some time servers

[Steve Allen]

Like the TymServe 2100 units there will probably be other systems that
fail because of a lack of leap seconds.  That means that 45 years ago
the CCIR put us all into a Catch-22 situation, and the ITU-R inherits
the undesired responsibility of doing or not doing something about it.

On Tue 2015-05-05T21:37:48 -0600, Warner Losh hath writ:
> Engineering is the choice of which consequences you want to have.

It should be an informed choice, and an individual choice, and a
choice.  What gets broadcast in the radio time signals is none of
those, and that is presumably a major motivation for the adoption of
IEEE 1588 (PTP).  IEEE 1588 gives those system managers a way to
choose to disregard certain international standards in favor of a
system with guaranteed robust behavior.  Such use of PTP is evident in
older documents and recent press releases by the financial markets
which basically read "We know our systems will be robust but we're not
sure about yours, so we're changing the trading hours on June 30."

> Leap seconds are nearly impossible to implement correctly.

As have been way too many time zone changes when the governing
agencies have decided to change the rules so late that it was not
possible to patch and distribute the tzdata files to the systems
which need to know when planes are taking off and landing.
Again we have no choice, unless we move to Arizona with Rob.
We change our clocks whether or not we like doing that.

If we believe their press releases, the financial market people
are sure that they have got the leap second implemented correctly.
We could all learn something from them.

> It is time to look at other solutions to the synchronization problem
> that can be implemented correctly.

It will be a failure if the result of WRC-15 does not change the radio
broadcast time signals to have a purely atomic time scale.  There are
billions of machines that have been told that time works in the
fashion of purely atomic time scales, and millions of system managers
who through no fault of their own have to deal with systems that have
self-inconsistent rules which can not work properly when they
encounter a leap second.

That makes WRC-15 into a choice about the name of the time scale,
but even there the delegates are being denied an informed choice.

Last year around this time the web server logs went several months
with thousands of hits on a two-week periodicity from dozens of
participants who were using a blogging system for discussions that
linked to my web pages.  When all those web hits were done happening
the Draft CPM document for WRC-15 Agenda Item 1.14 had appeared.
Nowhere in its options A1,A2,B,C1,C2 is mention that simply abandoning
leap seconds means redefining the notion of calendar day such that it
is no longer related to the rotation of the earth.

I take that to mean that some of the CPM delegates so fiercely want to
deny the implications of the ITU-R options that they refused any
consensus for a Draft CPM document which contained words about
redefining the calendar day.

There is another solution to the synchronization problem with code
already implemented and tested.  The longstanding IANA tzdata and
tzcode can handle leap seconds.  The new tzdist protocol can handle
leap seconds
https://datatracker.ietf.org/doc/draft-ietf-tzdist-service/
We choose to use those for time zones, and if at WRC-15 the ITU-R
chooses to preserve the rotation of the earth as the basis for the
calendar day then we can choose to use those protocols for leap
seconds.

--
Steve Allen                 <sla at ucolick.org>               WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046          Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/    Hgt +250 m