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

[Martin Burnicki <[e-mail]>]

Hi,

Daniel Migault wrote:
> Hi,
>
> Regarding the discussion on the leap second, I would suggest we make it
> optional. If you strongly disagree or think that cannot be made
> optional, then feel free to propose some text we agree for version 05.

I'm actually a little bit disappointed that all of the discussion on 
leap seconds is only with regard to the "right" time zones.

I've been hoping the new tzdist protocol would be a good chance to 
simplify all kind of applications which have to deal with times, and 
rely on regular updates coming from human intervention, like changed DST 
rules for particular time zones determined by individual countries, or 
new leap second events scheduled by the IERS.

In my opinion the "right" time zones are basically a good idea, but this 
is only *one* specific application which uses a list of leap second 
dates, and a big minus here is that an expiration date is missing from 
the TZ DB's leap second table representation.


As a summary:

1.) We have the leap second table file provided by NIST, which is 
directly used by NTP (for now). This table *does* include an expiration 
date, and this is important since programs like ntpd can emit a 
*warning* to the user or admin if the file is outdated. It is *not* 
possible to generate such a warning only based on some version info, if 
you (ntpd in this example) can't figure out if a newer version is available.

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.

By the way, do I recall correctly that TZ DB should only be *one* of the 
possible providers for the data distributed via the tzdist protocol?

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, or not. I've proposed this to the IERS 
folks some time ago, and also proposed to include an expiration date.

If you look at the IERS web page at
http://hpiers.obspm.fr/iers/bul/bulc/

then actually there is an outdated Leap_Second_History.datsave file 
dated 2014-01-28
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.datsave

and also a newer Leap_Second_History.dat file dated 2014-09-30
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat

which contains some more comments in its header, plus an *expiration date*.

So TZ DB's leap second file can alternatively be derived from the IERS 
file, but neither a file in NIST format nor in IERS format can be 
derived from a file in TZ DB format some information being lost.

On the other hand it should be easy for a tzdist client program to 
retrieve a generic table of leap second events plus expiration date from 
a tzdist server, and convert it to one or more formats required by 
applications like the "right" timezones, ntpd, ptpd, or the Network Time 
Forum's General Timestamp (GTS) API.
http://nwtime.org/projects/timestamp-api/


The leap second table expiration date may not be too important for the 
API calls which have actually been implemented to deal with the "right" 
timezones since existing API calls may not provide a way to alert the 
user or application if the table is outdated.

However, programs like ntpd (which already does so) or ptpd could emit a 
warning if they see that the expiration date is approaching, and the GTS 
API could set a warning flag if this is the case.

In real life it is perfectly possible that a system doesn't receive 
updates automatically, maybe in an isolated network, or because a 
caching server has not been updated and provides its clients with 
outdated information.

So my proposal is to let tzdist provide a list of leap second events 
plus an expiration date, as a simple table of UTC dates like 2014-12-31. 
This should not be too hard to be implemented but provides a huge 
benefit for future timekeeping applications, even though this may not be 
directly related to iCalendar applications.

Providing the "right" timezones with its leap second file, eventually in 
binary format, can be a good supplement but in my opinion the primary 
goal should be to make this data available in a generic format.

Best regards,

Martin