For my products I use an algorithm (Meeus; Astronomical Algorithms 1998) to 'predict' deltaT into the future. Does anyone have a good source for a more recent algorithm that takes into account IERS values since 1998? On 2019-07-26 21:27, Tim Parenti wrote:

NIST's leap-seconds.list was finally updated today.  Patch attached.

I'd reached out to Christian Bizouard of IERS a bit ahead of the announcement in the hopes that we could settle the outstanding issues from 2017 with adding a public domain copyright notice to the IERS version of the file, but no luck this time around.

-- Tim Parenti

On Thu, 4 Jul 2019 at 12:11, Kurt Roeckx <kurt@roeckx.be <mailto:kurt@roeckx.be>> wrote:

---------- Forwarded message ---------- From: IERS EOP Product Center <iers.eoppc@obspm.fr <mailto:iers.eoppc@obspm.fr>> To: bulc.iers@obspm.fr <mailto:bulc.iers@obspm.fr> Cc: Bcc: Date: Thu, 04 Jul 2019 15:06:25 +0200 Subject: Bulletin C number 58

     INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS)

SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE

SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel.      : +33 1 40 51 23 35 e-mail    : services.iers@obspm.fr <mailto:services.iers@obspm.fr> http://hpiers.obspm.fr/eop-pc

                                              Paris, 04 July 2019

                                              Bulletin C 58

                                              To authorities responsible                                               for the measurement and                                               distribution of time

                          INFORMATION ON UTC - TAI

 NO leap second will be introduced at the end of December 2019.  The difference between Coordinated Universal Time UTC and the  International Atomic Time TAI is :

     from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s

 Leap seconds can be introduced in UTC at the end of the months of December  or June,  depending on the evolution of UT1-TAI. Bulletin C is mailed every  six months, either to announce a time step in UTC, or to confirm that there  will be no time step at the next possible date.

                                            Christian BIZOUARD                                             Director                                             Earth Orientation Center of IERS                                             Observatoire de Paris, France

On 2019-07-26 22:49, Steve Allen wrote:

On Fri 2019-07-26T23:16:08-0400 David Patte hath writ:

...

For my products I use an algorithm (Meeus; Astronomical Algorithms 1998) to 'predict' deltaT into the future. Does anyone have a good source for a more recent algorithm that takes into account IERS values since 1998? at the moment we seem to be pretty close to "Matsakis parabolic" https://www.ucolick.org/~sla/leapsecs/year2100.html but there are no guarantees

We all know what a shock there was after the last break in regular leap second additions, and given short memories in popular development circles, expect similar reactions next year or whenever the next addition happens. Are there any sources providing pointers to explanations of recent changes in EOP parameters and their likely cause, or info about likely reasons for (rather than factors affecting) the current (and earlier) period(s) of reductions in dUT1 change? https://en.wikipedia.org/wiki/ΔT#References has an interesting comment: Stephenson, F. R. & Morrison, L.V. "Long-term fluctuations in the Earth's rotation: 700 BC to AD 1990". Philosophical Transactions of the Royal Society of London, Series A 351 (1995) 165-202. https://www.jstor.org/stable/54464. "Includes evidence that the 'growth' in Delta-T is being modified by an oscillation with a wavelength around 1500 years; if that is true, then during the next few centuries Delta-T values will increase more slowly than is envisaged." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

Another good paper on delta T from Stephenson, Morrison and Hohenkerk is "Measurement of the Earth's rotation: 720 BC to AD 2015". The paper's data, which includes projected values of delta T from the year -2000 to the year +2500, is at http://astro.ukho.gov.uk/nao/lvm/ Also, the IERS in their Bulletin A projects UT1-UTC a year in advance, and gives a formula for extending that projection. It is easy enough to convert UT1-UTC to delta T if you have a table of leap seconds. John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E

On 2019-07-27 06:54, Alois Treindl wrote:

On 27.07.19 05:16, David Patte wrote:

...

For my products I use an algorithm (Meeus; Astronomical Algorithms 1998) to 'predict' deltaT into the future. Does anyone have a good source for a more recent algorithm that takes into account IERS values since 1998?

In Swiss Ephemeris, we have an implementation of delta T which tries to be state of the art.

See documentation here https://www.astro.com/swisseph/swephprg.htm#_Toc11319101

and source code here https://www.astro.com/ftp/swisseph/src/

The delta T source code is in file swephlib.c https://www.astro.com/ftp/swisseph/src/swephlib.c

The implementation is complicated by the fact that we try to be consistent with different versions of JPL ephemerides, which use different values for the Moon's tidal acceleration.

All the code of Swiss Ephemeris is published under GPL.

A commercial license is available for those who do keep their projects free of the obligations arising from Gnu public license,

Many developers who wish to promote using their code as a standard choose instead to license under the BSD or MIT licences as an option to or instead of the GPL, any mention of which deters most commercial licensees from even looking. Commercial licensees would rather deal with a few comprehensive sources than a bunch of little bits and pieces. As in all forms of commodity publishing, the issue is not really about buying, it is getting anyone interested in any of a particular author's works: the publishing businesses take a statistical shotgun approach, in the hopes that buyers will like a few works by some of their authors. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

On 2019-07-27 08:21, Paul Eggert wrote:

Thanks, I installed that into the development version on GitHub.

I see that the updated file has a space at the end of the '#@ 3802291200' line that encodes the expiration (2020-06-28 00:00:00 UTC). I assume this was inadvertent. It doesn't break tzcode (which ignores that line), but the format of the line is not documented anywhere that I can see. I dropped Judah Levine a line about this.

leap-seconds.list tail says: # the following special comment contains the # hash value of the data in this file computed # use the secure hash algorithm as specified # by FIPS 180-1. See the files in ~/pub/sha for # the details of how this hash value is # computed. Note that the hash computation # ignores comments and whitespace characters # in data lines. It includes the NTP values # of both the last modification time and the # expiration time of the file, but not the # white space on those lines. # the hash line is also ignored in the # computation. # #h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30 so only the NTP values in the special comments lines and the data lines are significant: all non-special comments lines may be ignored, as can comments in data lines, only the digits in the data and special comments lines are significant for the hash; and only the hex digits in the hash line are significant for validation. Strictly speaking, the file should also follow the format and naming documented for NTP source crypto files, as it is part of and distributed using those mechanisms, but that is not enforced anywhere. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.