[tz] [Tzdist] Getting to closure Re: [tzdist] #31 (service): Include leap seconds?
Martin Burnicki
martin.burnicki at burnicki.net
Fri Dec 19 16:49:39 UTC 2014
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
More information about the tz
mailing list