[LEAPSECS] D.H. Sadler in 1954

[Warner Losh]

On Sun, Mar 18, 2018 at 11:12 PM, John Sauter <
John_Sauter at systemeyescomputerstore.com> wrote:

> On Sat, 2018-03-17 at 22:52 +0000, Michael.Deckers via LEAPSECS wrote:
>
> >     So, the likely future is that the limit on |UT1 - UTC| will be
> > dropped,
> >     leap seconds will no longer be applied, and UTC will become a
> > fixed
> >     translate of TAI (so that dissemination of TAI - UTC becomes
> > unnecessary).
>
> I think you are reading too much into the recommendation.  There is no
> mention made of letting UT1 - UTC become unbounded, but only to
> "consider the present limitation on the maximum magnitude of UT1 - UTC"
> and to "improve further the accuracy of the prediction of UT1 - UTC".
>
> Allowing UT1 - UTC to increase from plus or minus 0.9 seconds to plus
> or minus 1.9 seconds would require changes in the protocols used to
> disseminate UT1 - UTC, but it is definitely possible.  Improving the
> accuracy of the prediction of UT1 - UTC is a good idea but may not be
> possible, since predicting the rotation of the Earth is like predicting
> the weather.
>
> In my opinion, the intended future is that the frequency of Bulletin C
> is decreased from twice a year to once a year, or once every two years.
>

As a developer of disconnected systems, I'd love it if they adopted this
change. There's nothing magic about 1s and it was selected for a number of
pragmatic reasons that no longer exist. While there may be a few other
newer reasons to keep it, having good UT1 - UTC mitigates most of them.
Having a loser tolerance means we could do things like having a leap second
every 18 months for the next decade which would help disconnected and
non-updated systems cope better. One of the biggest problems with
implementations getting UTC is that it's an irregular system based on
arcane observations rather than something more predictable like leap
years.  A known rule with a > 6month horizon would help compliance
significantly.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20180319/8fb1b4e4/attachment.html>