sla29970

During the discussions leading to the inception of the SI second the bigwig standards folks nixed the consideration of relativity, basically paraphrased as "If you physicists do not stop arguing about relativity we will never redefine time in a way that removes it from the astronomers."

Strange is what they said just after the CCIR incepted leap seconds at the SI subcommittee in charge of the subject: "The CCIR may have overstepped its remit in defining the UTC" and "The process that led to UTC may have been illogical, but it was effective"

Have a look at the rate of earth rotation over the past 250 years where it is unclear that there is long term acceleration or deceleration. https://www.ucolick.org/~sla/leapsecs/dutc.html

It is possible 8 weeks in advance to predict the difference between UTC and UT1 and keep it less than 0.9 seconds. Nothing more is required by international agreement.

Lack of agreement; "smearing" is completely normal for answering "What time is it?", and completely wrong for applications requiring precise time.

In that case UTC is the wrong answer to the question "What timescale will produce robust results for this application?" As soon as leap seconds were recommended by the CCIR in 1970 radionavigation system administrators announced they would switch to purely atomic TAI-10s and astronomical almanacs continued to use just plain UT. Proceedings of international standards bodies show them discussing how the new CCIR timescale with leap seconds (not yet officially named UTC) need not apply to anything other than radio broadcast time signals.

Look at the past 250 years where there is not really any clear indication of deceleration https://www.ucolick.org/~sla/leapsecs/dutc.html

Calculating time deltas between events is fundamental for GPS navigation, tracking an incoming missile, coordinating the action of robotic systems, synchronization of telecommunications, ...

"ignoring leap seconds" is equivalent to "using a time scale that does not conform to UTC". Time scales other than UTC have 86400 seconds in a day. UTC is the exception.

"My system clock is wrong, what action shall I take to correct it?" Common answers to that question are "step" or "smear". The notion that the clock could be wrong is not addressed in the design of most systems, and "smear" is widely accepted as the least harmful fix.

At the inception of leap seconds it was unclear how well they could be predicted, but the agreement required 8 weeks of notice as a minimum. Since the inception of leap seconds the rotation of the earth has accelerated, not slowed.

POSIX requires that we ignore leap seconds. POSIX had no alternatives to this choice because the information needed to do time right was not, and still is not, readily available via an authoritative and robust mechanism. No international recommendation has ever required the creation nor funding of a mechanism better than "This one agency in Paris will use the post office to send out letters to your national government time service agency at least 8 weeks in advance of a leap."

A detailed look at the negotiations that led to leap seconds shows that they were not for maritime celestial navigation. During the process several different times the celestial navigation folks set a limit on how far radio broadcast time signals could deviate from astronomical time, and every one of those limits was violated as the negotiations proceeded. By the time the draft recommendation was given to 12th Plenary Assembly of the CCIR it allowed for leaps of multiple seconds, and that draft was amended on the floor to leaps of only one second before they voted to approve.

In 1950 astronomers pointed out that there would have to be two kinds of time, one to agree with calendar days and one to be as uniform as possible. Arguments over subsequent decades inexplicably decided that there could only be one kind of time specified by international agreements, and we ended up with a choice of two out of three characteristics in what we now call UTC. https://www.ucolick.org/~sla/leapsecs/picktwo.html

Yes, roughly quadratic increase of LOD over the long term, but over short term more like a random walk. Right now the earth's crust is rotating faster than it did a century ago because things have speeded up. For a view over 2 millennia see plots of LOD at https://www.ucolick.org/~sla/leapsecs/dutc.html

Remember February 30 1712? https://en.wikipedia.org/wiki/February_30#Swedish_calendar

The ITU has 4 methods for dealing with leap seconds, and method D is to change nothing. See the lack of consensus for any change in last week's presentations at http://www.itu.int/en/ITU-R/conferences/wrc/2015/irwsp/2015/... especially the "Input Document WRC-15-IRWSP-15/8" presentation by Zuzek.

Dan Bernstein proposed it and Bradley White wrote the code in the time zone package used by Unix-like systems. The point of "right+gps" is that all of the pieces needed to implement such a scheme are already deployed and tested and with appropriate caveats anyone can decide to use that to avoid leap second issues.

Some delegates to the ITU-R process have argued in the above fashion. Other delegates have come representing countries which want UTC to remain as a valid count of days in the calendar (for 86400 SI seconds is not the same as one rotation of the earth). For over 10 years these two viewpoints have been at stalemate with no progress toward any compromise that might alleviate the problems that POSIX systems face at each leap second.

There have been many defintions of UTC http://www.ucolick.org/~sla/leapsecs/timescales.html#UTC which do not agree. When an API does not match what the providers supply, which definition qualifies as "official"?

Read between the lines of http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UT... about what systems of time distribution already exist and which of those are approved for use by national and international agencies.

Getting a TAI timestamp is impossible because the BIPM (the authority that defines TAI) does not want TAI used for such purposes. Without approval from the authority nobody will undertake to construct the technology to provide TAI to an operational system. Without a source for TAI, any system which claims to be using TAI is making the same mistake that POSIX made with UTC. To wit: Creating a new thing which has the name of an existing thing but does not have the properties of the existing thing. This is a recipe for confusion.