[tz] [Tzdist] Getting to closure Re: [tzdist] #31 (service): Include leap seconds?

[Paul Eggert]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-leapseconds.awk-NEWS-Also-output-expiration-date-com.patch
Type: text/x-patch
Size: 1175 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20141217/0360fe29/0001-leapseconds.awk-NEWS-Also-output-expiration-date-com.patch>