[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