FYI, per IERS Bulletin C57, there will be no leap second on 2019-06-30. Unfortunately, NIST is affected by the partial shutdown of the US government <https://www.commerce.gov/news/blog/2018/12/shutdown-due-lapse-congressional-...> which has been ongoing since 2018-12-22 00:00 -05, so most of their website is unavailable, meaning it will likely be some time before they publish an updated leap-seconds.list. But since the current NIST file doesn't expire until 2019-06-28, we've got some time before we have to deal with that. Last we had left the problem of being able to take the equivalent file directly from the IERS at https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, some lines had been added to https://hpiers.obspm.fr/iers/bul/bulc/README on 2017-04-11, but the exact text did not make any assertions about surrounding files, and we would prefer the notice be added to leap-seconds.list itself. (There are a few other typos therein which I spotted as well.) See: https://mm.icann.org/pipermail/tz/2017-April/024990.html https://mm.icann.org/pipermail/tz/2017-April/024988.html In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc@obspm.fr> Date: Mon, 7 Jan 2019 at 10:56 Subject: Bulletin C number 57 To: <bulc.iers@obspm.fr> 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 http://hpiers.obspm.fr/eop-pc Paris, 07 January 2019 Bulletin C 57 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 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
The IERS is not furloughed, so why isn't this on their website? https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html On Mon, Jan 7, 2019 at 11:28 AM Tim Parenti <tim@timtimeonline.com> wrote:
FYI, per IERS Bulletin C57, there will be no leap second on 2019-06-30.
Unfortunately, NIST is affected by the partial shutdown of the US government which has been ongoing since 2018-12-22 00:00 -05, so most of their website is unavailable, meaning it will likely be some time before they publish an updated leap-seconds.list. But since the current NIST file doesn't expire until 2019-06-28, we've got some time before we have to deal with that.
Last we had left the problem of being able to take the equivalent file directly from the IERS at https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, some lines had been added to https://hpiers.obspm.fr/iers/bul/bulc/README on 2017-04-11, but the exact text did not make any assertions about surrounding files, and we would prefer the notice be added to leap-seconds.list itself. (There are a few other typos therein which I spotted as well.)
See: https://mm.icann.org/pipermail/tz/2017-April/024990.html https://mm.icann.org/pipermail/tz/2017-April/024988.html
In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable.
-- Tim Parenti
---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc@obspm.fr> Date: Mon, 7 Jan 2019 at 10:56 Subject: Bulletin C number 57 To: <bulc.iers@obspm.fr>
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 http://hpiers.obspm.fr/eop-pc
Paris, 07 January 2019
Bulletin C 57
To authorities responsible for the measurement and distribution of time
INFORMATION ON UTC - TAI
NO leap second will be introduced at the end of June 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 Mon 2019-01-07T13:48:14-0500 Marshall Eubanks hath writ:
The IERS is not furloughed, so why isn't this on their website?
https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
IERS Observatoire Paris Meudon is distinct from IERS Central Bureau Frankfurt am Main. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On 2019-01-07 11:48, Marshall Eubanks wrote:
On Mon, Jan 7, 2019 at 11:28 AM Tim Parenti wrote:
FYI, per IERS Bulletin C57, there will be no leap second on 2019-06-30.
The IERS is not furloughed, so why isn't this on their website? https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
The files under the Bulletin C metadata Source URL: https://hpiers.obspm.fr/eoppc/bul/bulc/?C=M;O=D were updated earlier today, but the FTP site: ftp://ftp.iers.org/products/eop/bulletinc/ and the announcements and files at: ftp://ftp.iers.org/products/eop/bulletinc/bulletinc-057.txt https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt https://datacenter.iers.org/versionMetadata.php?filename=mt/bulletinc-057.tx... were just updated later today.
In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable. EU Open Data Portal Licensing Assistant
https://www.europeandataportal.eu/en/content/show-license suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied. Which of these are preferred by the masintainer? -- 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 Mon, 7 Jan 2019 at 23:01, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
EU Open Data Portal Licensing Assistant
https://www.europeandataportal.eu/en/content/show-license
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied.
Which of these are preferred by the masintainer?
To avoid rehashing the prior discussion, I think the intent was that the CC-BY 4.0 statement already added to https://hpiers.obspm.fr/iers/bul/bulc/README be added to the leap-seconds.list file itself, and/or to update the existing statement by s/This file/The files in this folder, and its sub-folders, are/. -- Tim Parenti
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied.
Which of these are preferred by the masintainer?
The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic.
Paul Eggert wrote:
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied.
Which of these are preferred by the masintainer?
The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic.
Maybe one of you should make a concrete proposal to Christian Bizouard and tell him which text should be added in which places to meet your requirements. I'm not familiar with those licensing details, and I'm afraid the folks at IERS aren't, either. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ 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 Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
With the partial shutdown of the US government having ended approximately 2019-01-25 21:30 -05, the NIST file appears to have been updated this morning; proposed patch attached. On Tue, 8 Jan 2019 at 03:09, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Maybe one of you should make a concrete proposal to Christian Bizouard and tell him which text should be added in which places to meet your requirements.
That is on my to-do list for the coming days, and I'll keep Paul in the loop on that as well. I'd much rather we start taking this file from https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list -- Tim Parenti
On 1/8/19 12:02 AM, Martin Burnicki wrote:
Maybe one of you should make a concrete proposal to Christian Bizouard and tell him which text should be added in which places to meet your requirements.
I'm not familiar with those licensing details, and I'm afraid the folks at IERS aren't, either.
I looked into this while the US federal government was shut down, and it turns out that it's more complicated than merely adding a notice in the IERS file. One cannot simply translate the IERS file to the NIST file, as the NIST file has information that the IERS file lacks, namely, the last time that the data were changed. Although this could be worked around, the workaround would add complexity that I'd rather avoid. So any proposal should involve not only adding a liberal copyright notice, but also changing the IERS file's data format, which would be a bigger deal. I don't know whether the IERS would go along with that.
Paul Eggert <eggert@cs.ucla.edu> wrote:
One cannot simply translate the IERS file to the NIST file, as the NIST file has information that the IERS file lacks, namely, the last time that the data were changed.
Isn't that always 5ish months before the last leap second? :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Lands End to St Davids Head including the Bristol Channel: Northeast 6 to gale 8, backing north 5 to 7. Slight or moderate in far east, otherwise rough or very rough, becoming moderate or rough. Wintry showers. Good, occasionally moderate.
On Fri, 1 Feb 2019 at 07:44, Tony Finch <dot@dotat.at> wrote:
Paul Eggert <eggert@cs.ucla.edu> wrote:
One cannot simply translate the IERS file to the NIST file, as the NIST
file
has information that the IERS file lacks, namely, the last time that the data were changed.
Isn't that always 5ish months before the last leap second? :-)
Well, both have a #$ line, but the purpose is slightly different. For NIST, the value is the last time that only the data were changed (currently 2016-07-08T00:00:00Z), but for IERS it's the last time the file as a whole was updated, including the metadata (currently 2019-01-07T14:19:26Z). I would imagine, yes, IERS wouldn't be keen on adopting NIST's practices for this line, but I don't necessarily see the reverse change being particularly disruptive, if we were to take IERS' file as-is. In the worst case, anyone relying on the less-often-updated NIST version of the line would just end up pulling the same, unchanged data once every six months. -- Tim Parenti
Tim Parenti wrote:
On Fri, 1 Feb 2019 at 07:44, Tony Finch <dot@dotat.at <mailto:dot@dotat.at>> wrote:
Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> wrote: > > One cannot simply translate the IERS file to the NIST file, as the NIST file > has information that the IERS file lacks, namely, the last time that the data > were changed.
Isn't that always 5ish months before the last leap second? :-)
Well, both have a #$ line, but the purpose is slightly different. For NIST, the value is the last time that only the data were changed (currently 2016-07-08T00:00:00Z), but for IERS it's the last time the file as a whole was updated, including the metadata (currently 2019-01-07T14:19:26Z).
Basically the difference shouldn't matter much as long as the data in the file is correct, and the file has not expired. If the "last update" time changes whenever *any* of the information in the file has been updated you can always figure out which is the latest version of the file, even if an updated file becomes available for some reason in the middle of the interval between 2 bulletin Cs. So I'd even say the IERS way to do it makes more sense.
I would imagine, yes, IERS wouldn't be keen on adopting NIST's practices for this line, but I don't necessarily see the reverse change being particularly disruptive, if we were to take IERS' file as-is. In the worst case, anyone relying on the less-often-updated NIST version of the line would just end up pulling the same, unchanged data once every six months.
Jep. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ 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 Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 2019-02-01 05:43, Tony Finch wrote:
Paul Eggert wrote:
One cannot simply translate the IERS file to the NIST file, as the NIST file has information that the IERS file lacks, namely, the last time that the data were changed. Isn't that always 5ish months before the last leap second? :-)
Normally within 10 (exceptionally 15) workdays after six months before the previous leap second. For NIST source, this should be same as the numeric suffix of the real name of the file symlinked from leap-seconds.list and the internal update timestamp, which are only updated when a new leap second is announced in Bulletin C and inserted into the file. After every Bulletin C which does not announce a leap second, only the expiry timestamp and file modified date are updated some time later. For IERS and USNO sources, this is updated by Bulletin C every six months, so the real name numeric suffix and the internal update timestamp reflect that. File real name numeric suffix and the internal update timestamp used to be rounded to the UTC day but the IERS now sets those to arbitrary actual times. All expiry timestamps are set to the 28th of the month before the possible following leap second in the next Bulletin C announcement (allowing for future possible quarterly or monthly leaps). -- 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-01-07 23:39, Paul Eggert wrote:
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied. Which of these are preferred by the masintainer? The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic.
Publications Office of the European Union Open Data Portal Helpdesk says "After careful consideration of your request, we are sorry to inform you that these datasets are produced by an international specialised body so we are unable to publish them in ODP." -- 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.
Brian Inglis wrote:
On 2019-01-07 23:39, Paul Eggert wrote:
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied. Which of these are preferred by the masintainer? The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic.
Publications Office of the European Union Open Data Portal Helpdesk says "After careful consideration of your request, we are sorry to inform you that these datasets are produced by an international specialised body so we are unable to publish them in ODP."
When I asked the IERS folks some years ago to make a leap second file in this format available they agreed to do it, but I bet they just did it without much thinking about the licensing. I'd really expect they would do what is required to make sure the file is in the public domain. The file was created for public usage, and they wouldn't have to put it on their public server if they had created it only for their own, internal usage. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ 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 Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 2019-02-01 08:10, Martin Burnicki wrote:
Brian Inglis wrote:
On 2019-01-07 23:39, Paul Eggert wrote:
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied. Which of these are preferred by the masintainer? The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic. Publications Office of the European Union Open Data Portal Helpdesk says "After careful consideration of your request, we are sorry to inform you that these datasets are produced by an international specialised body so we are unable to publish them in ODP." When I asked the IERS folks some years ago to make a leap second file in this format available they agreed to do it, but I bet they just did it without much thinking about the licensing. I'd really expect they would do what is required to make sure the file is in the public domain. The file was created for public usage, and they wouldn't have to put it on their public server if they had created it only for their own, internal usage.
Probably not top of mind or high on the priority list for government funded atomic-/astro-/geo-physicists, or most others, most places in the world: if anyone publishes stuff for use, you can use it, and that's normal. -- 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 Feb 1, 2019, at 11:22 AM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
[EXTERNAL EMAIL]
On 2019-02-01 08:10, Martin Burnicki wrote:
Brian Inglis wrote:
On 2019-01-07 23:39, Paul Eggert wrote:
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied. Which of these are preferred by the masintainer? The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic. Publications Office of the European Union Open Data Portal Helpdesk says "After careful consideration of your request, we are sorry to inform you that these datasets are produced by an international specialised body so we are unable to publish them in ODP." When I asked the IERS folks some years ago to make a leap second file in this format available they agreed to do it, but I bet they just did it without much thinking about the licensing. I'd really expect they would do what is required to make sure the file is in the public domain. The file was created for public usage, and they wouldn't have to put it on their public server if they had created it only for their own, internal usage.
Probably not top of mind or high on the priority list for government funded atomic-/astro-/geo-physicists, or most others, most places in the world: if anyone publishes stuff for use, you can use it, and that's normal.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Yes, that is quite logical. But intended for general use has no legal connection to copyright status. For example, most open source code is, by definition, intended for everyone to use at no charge. But it is covered by copyright. The TZ files are rather unusual in that respect because they are explicitly released into the public domain (no copyright). The question here is about copyright status of the files, not their intended use. paul
On 2019-02-01 10:59, Paul.Koning@dell.com wrote:
On Feb 1, 2019, at 11:22 AM, Brian Inglis wrote: On 2019-02-01 08:10, Martin Burnicki wrote:
Brian Inglis wrote:
On 2019-01-07 23:39, Paul Eggert wrote:
Brian Inglis wrote:
suggests CC-PDM, CC0, ODC-PDDL, OGL, or EUPL may be suitable depending on which explicit permissions are required and whether obligations should be applied. Which of these are preferred by the masintainer? The intent of the tzdb (see Internet RFC 6657 section 7) is that it be in the public domain, so CC-PDM sounds like it's the most-appropriate. CC-BY 4.0 places more requirements than what RFC 6657 would allow, so it would be more problematic. Publications Office of the European Union Open Data Portal Helpdesk says "After careful consideration of your request, we are sorry to inform you that these datasets are produced by an international specialised body so we are unable to publish them in ODP." When I asked the IERS folks some years ago to make a leap second file in this format available they agreed to do it, but I bet they just did it without much thinking about the licensing. I'd really expect they would do what is required to make sure the file is in the public domain. The file was created for public usage, and they wouldn't have to put it on their public server if they had created it only for their own, internal usage. Probably not top of mind or high on the priority list for government funded atomic-/astro-/geo-physicists, or most others, most places in the world: if anyone publishes stuff for use, you can use it, and that's normal. Yes, that is quite logical. But intended for general use has no legal connection to copyright status. For example, most open source code is, by definition, intended for everyone to use at no charge. But it is covered by copyright. The TZ files are rather unusual in that respect because they are explicitly released into the public domain (no copyright). The question here is about copyright status of the files, not their intended use.
Kind of hard to use them without downloading them as they are intended to be. -- 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 1/7/19 8:27 AM, Tim Parenti wrote:
In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable.
Likewise. I'd rather use the IERS file directly. In the meantime perhaps we could forge the NIST leap-seconds.list file (including a comment that it's a forgery and why we're doing the forgery), and then substitute the real thing whenever it shows up. I'd rather have a script to do that than do it by hand, though. We'd need that script anyway if we start basing our distribution on the IERS file, as so many users now grab the NIST file from us rather than from the NIST.
participants (8)
-
Brian Inglis -
Marshall Eubanks -
Martin Burnicki -
Paul Eggert -
Paul.Koning＠dell.com -
Steve Allen -
Tim Parenti -
Tony Finch