Bulletin C 51: No leap second in June 2016, but new leap second file
The International Earth rotation Service (IERS) has just published bulletin C 51, announcing that *no* leap second will be introduced at the end of June 2016: ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat The IERS now also makes a leap second file available for use with NTP: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list This new file has the expiration date set to 28 December 2016, so users who have configured ntpd to use the leap second file should upgrade their local copy of the file. The leap second file does not only announce leap seconds, it also provides ntpd and thus the OS kernel with the current TAI/UTC offset, which is helpful for applications working with TAI. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 (0)5281 9309-14 Fax: +49 (0)5281 9309-30 Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Web: http://www.meinberg.de
Thanks for the heads-up. The NIST's version of this data has not been updated yet, so we'll wait for that before copying it to leap-seconds.list. There's no rush, as that file's listed expiration date is currently 2016-06-28.
On 2016-01-11 04:51, Martin Burnicki wrote:
The International Earth rotation Service (IERS) has just published bulletin C 51, announcing that *no* leap second will be introduced at the end of June 2016: ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
The IERS now also makes a leap second file available for use with NTP: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
This new file has the expiration date set to 28 December 2016, so users who have configured ntpd to use the leap second file should upgrade their local copy of the file.
The leap second file does not only announce leap seconds, it also provides ntpd and thus the OS kernel with the current TAI/UTC offset, which is helpful for applications working with TAI.
The comment says 28 December 2016 but the expiry timestamp 3684182400 is actually 2016-09-30 00:00:00+0000, 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. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
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.
Paul Eggert wrote:
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.
I've been in touch with Olivier Becker from IERS who has actually created the file. In the original file the expiration date was in fact set to 30 September 2016, due to a misunderstanding of what should be a proper date. I've then asked them to change this to late December, and they did, but obviously they only changed the human readable date but not the expiry timestamp, and I didn't check this. :-( I'll contact Olivier and ask him to fix this.
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.
I don't think so. the bulletin still says it's published every 6 months. I'm sure this is only a problem with the leap second file. Martin
A fixed version of the IERS leap second file is now available, with the same expiration date 28 December 2016 both in the human readable comments and in the machine readable time stamp. Martin Martin Burnicki wrote:
Paul Eggert wrote:
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.
I've been in touch with Olivier Becker from IERS who has actually created the file. In the original file the expiration date was in fact set to 30 September 2016, due to a misunderstanding of what should be a proper date.
I've then asked them to change this to late December, and they did, but obviously they only changed the human readable date but not the expiry timestamp, and I didn't check this. :-(
I'll contact Olivier and ask him to fix this.
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.
I don't think so. the bulletin still says it's published every 6 months. I'm sure this is only a problem with the leap second file.
Martin
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.
On 2016-01-12 15:09, Paul Eggert wrote:
In http://mm.icann.org/pipermail/tz/2016-January/023057.html Brian Inglis wrote:
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.
They're time nerds, not necessarily IT nerds who know how to propagate time stamps thru whatever process results in the publication of the file on the public facing web site. Whether that process involves Unix cp, scp, or internal FTP put, these operations do not normally propagate file timestamps.
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.
I read that as giving themselves just 12 weeks leeway rather than the normal 24 weeks over the normal July update timeframe in case some event(s) are expected to increase dUT1 divergence more than the -0.4s currently predicted for year end in Bulletin A. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
participants (5)
-
Becker Olivier -
Brian Inglis -
Martin Burnicki -
Martin Burnicki -
Paul Eggert