Re: [tz] [Tzdist] Getting to closure Re: [tzdist] #31 (service): Include leap seconds?
On 12/17/2014 06:55 AM, Martin Burnicki wrote:
2.) We have the leap second file from TZ DB. This file has a different format than the NIST file, but as far as I can see is simply generated from a file in NIST format by a script which is part of the TZ DB package. Unfortunately the expiration date is *not* migrated into the TZ DB's leap second file, so some important information is lost.
Thanks for reporting this. I have installed the attached fix in the experimental tz sources on github and it should appear in the next tz release. I am cc'ing the tz mailing list to give them a heads-up.
3.) We have a leap second file from IERS, which is once more in a different format than the ones mentioned above.
In my opinion the IERS should be the authoritative source for a leap second file (or table) since this is the institution deciding whether a leap second is to be scheduled,
I would prefer this also. However, the IERS file is copyrighted. That is why the tz database reproduces the NIST file (the NIST file is public domain). Other distributors of the IERS file might want to keep this in mind. Amusingly enough, the NIST file's expiration date disagrees with the IERS's. As a practical matter the NIST's date is more conservative and is a better choice for applications like tz and tzdist and this is another argument for using the NIST file. Perhaps someday the IERS will address these two concerns.
Paul Eggert wrote:
On 12/17/2014 06:55 AM, Martin Burnicki wrote:
2.) We have the leap second file from TZ DB. This file has a different format than the NIST file, but as far as I can see is simply generated from a file in NIST format by a script which is part of the TZ DB package. Unfortunately the expiration date is *not* migrated into the TZ DB's leap second file, so some important information is lost.
Thanks for reporting this. I have installed the attached fix in the experimental tz sources on github and it should appear in the next tz release. I am cc'ing the tz mailing list to give them a heads-up.
Great, thanks.
3.) We have a leap second file from IERS, which is once more in a different format than the ones mentioned above.
In my opinion the IERS should be the authoritative source for a leap second file (or table) since this is the institution deciding whether a leap second is to be scheduled,
I would prefer this also. However, the IERS file is copyrighted. That is why the tz database reproduces the NIST file (the NIST file is public domain). Other distributors of the IERS file might want to keep this in mind.
We (maybe I) could contact the IERS folks once more. Maybe they are just not aware that this copyright limits the files usage for TZ DB and/or tzdist. On the other hand, the intention of the file should be to use it, or the information it provides, so why should there a problem extracting data from it using a script and feeding the result to TZ DB and/or tzdist?
Amusingly enough, the NIST file's expiration date disagrees with the IERS's. As a practical matter the NIST's date is more conservative and is a better choice for applications like tz and tzdist and this is another argument for using the NIST file.
Agreed. If the expiration date is only e.g. 2 days before the next potential leap second then alerting may be too late, except if the application alerts let's say 2 weeks (or whatever) before the current date reaches the expiration date.
Perhaps someday the IERS will address these two concerns.
Shall I contact the IERS folks with regard to this? Martin
On 12/19/2014 08:49 AM, Martin Burnicki wrote:
On the other hand, the intention of the file should be to use it, or the information it provides, so why should there a problem extracting data from it using a script and feeding the result to TZ DB and/or tzdist?
Yes, we can do that in the United States. But we cannot reproduce the input file from the IERS; all we can do is reproduce the output data. Which, effectively, is what we're doing now, using the NIST file as an intermediary. From our point of view it would be better if the IERS's file were explicitly placed in the public domain or under a free-software license like the GPL or the BSD license, so that we could distribute the file as part of the tz distribution.
Amusingly enough, the NIST file's expiration date disagrees with the IERS's. As a practical matter the NIST's date is more conservative and is a better choice for applications like tz and tzdist and this is another argument for using the NIST file.
Agreed. If the expiration date is only e.g. 2 days before the next potential leap second then alerting may be too late, except if the application alerts let's say 2 weeks (or whatever) before the current date reaches the expiration date.
Perhaps someday the IERS will address these two concerns.
Shall I contact the IERS folks with regard to this?
Sure, please feel free; you can cite this thread.
Martin Burnicki said:
We (maybe I) could contact the IERS folks once more. Maybe they are just not aware that this copyright limits the files usage for TZ DB and/or tzdist.
On the other hand, the intention of the file should be to use it, or the information it provides, so why should there a problem extracting data from it using a script and feeding the result to TZ DB and/or tzdist?
There is no copyright issue in using the data; only the presentation in the IERS file is copyright.
Amusingly enough, the NIST file's expiration date disagrees with the IERS's.
Since IERS set the rules, that's the date that matters. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
participants (3)
-
Clive D.W. Feather -
Martin Burnicki -
Paul Eggert