[tz] Bulletin C 51: No leap second in June 2016, but new leap second file

[Becker Olivier]

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 at 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.