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 <[email protected]> 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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
