Dear Sir, That's right, the two date does not correspond. Because there was a discussion about expiration date, it was first decided to set it on June but we finally adopted the NIST convention which use to set it on December. But we forgot to change the expiration timestamp as well. This bug will be repared as soon as possible Sorry for this inconvenience Best Regards Olivier Becfker EOP-PC Observatoire de Paris Le Mardi 12 Janvier 2016 23:09 CET, Paul Eggert <eggert@cs.ucla.edu> a écrit:
In http://mm.icann.org/pipermail/tz/2016-January/023057.html Brian Inglis wrote:
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list The comment says 28 December 2016 but the expiry timestamp 3684182400 is actually 2016-09-30 00:00:00+0000
Ouch! That's definitely a bug in the leap-seconds.list file. I will BCC: this message to the webmaster for that web page.
A less-important issue: that web page has a Last-Modified time (reported via the HTTP header) of 2016-01-11 11:06:36 UTC, even though the web page's contents give a last update equal to 3661459200 NTP, i.e., 2016-01-11 00:00:00 UTC. I guess they have just one-day resolution for theirannouncements' time stamps, but hey! they're time nerds! The two time stamps should be identical.
so they must be fairly confident that current predictions of dUT1 remaining low until year end will be borne out, and Bulletin C 52 will announce no change in July.
If the actual expiry is 2016-09-30 they're giving themselves the opportunity to decide in July to insert a leap second at the end of
September, which is conservative: although the protocols allow leap
seconds to be inserted in September, it has never happened and is unlikely to happen this year.