[LEAPSECS] next leap second

[John Sauter]

On Thu, 2017-01-12 at 09:18 -0800, Michael Shields via LEAPSECS wrote:

> It might also be helpful if we understood better how these models are
> used to decide when to announce leap seconds.  I don't know currently
> what criteria the IERS uses, except the overall parameters of keeping
> > UT1-UTC| < 0.9 s and preferring to have leap seconds in June or
> 
> December instead of other months.
> 
> For example, here's Bulletin A from 2016-06-30:
> 
> https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxix-0
> 26.txt
> 
> 2016-12-31 (MJD 57753): -0.45079 s
> 2017-06-30 (MJD 57934): -0.73759 s
> 
> You might have expected either of these days to have leap seconds.
> The next week, Bulletin C Number 52 announced a leap second for
> 2016-12-31.  The actual value of UT1-UTC on that day was about
> -0.407858 s.
> 
> The predictions looked similar on 2014-06-26:
> 
> https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxvii-
> 026.txt
> 
> 2014-12-31 (MJD 57022): -0.46583 s
> 2015-06-26 (MJD 57199): -0.67258 s
> 
> Again, either December 2014 or June 2015 could have had leap seconds.
> But in this case the leap second was deferred.  It happened on
> 2015-06-30, when UT1-UTC was -0.6760362 s
> (https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/207/bulletinb-330
> .txt).

I tried to find an algorithm that would predict the IERS announcements
of leap seconds, but failed.  Here is the closest I was able to come:

Take a span of time in which the difference between UT1 and UTC is
continuously between 0.1 and 0.9.  This is the span in which a leap
second is permitted.  You can't do a leap second when the difference is
less than 0.1 because that would make the new difference greater than
0.9.

Within that span, look for a December 31 or June 30.  If you find
exactly one, that is the leap second date.  If you find more than one,
choose the one in which the difference between UT1 and UTC is closest
to 0.5.  It is in principle possible for there to be no December 31 or
June 30 within the span, though that hasn't happened yet.  If it does,
choose March 31 or September 30.  If they are also missing from the
span, choose the last day of any month.

That algorithm comes close to the actual schedule, but does not exactly
match.  Perhaps someone can improve the algorithm and we can apply it
to predict future leap seconds.  Keep in mind that the IERS may have
improved their algorithm since 1972, so we may be looking at a moving
target.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170112/fdf85503/attachment-0001.pgp>