[LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Martin Burnicki]

Brooks Harris wrote:
> On 2017-01-05 05:56 AM, Tony Finch wrote:
>> Martin Burnicki <martin.burnicki at burnicki.net> wrote:
>>> Please note that NTP servers not necessarily need to be providers for
>>> leap second files. There are some well known sites which provide this
>>> file, and the NTP software package from ntp.org comes with a script
>>> which can be used to update the file automatically.
>> I was thinking more that an NTP client or server would use its
>> leapseconds
>> file for validating LI bits from servers and for determining when they
>> should leap.
>>
>> My thinking is that routine software patching and security updates happen
>> often enough that maybe NTP can get leap second more reliably out-of-band
>> instead of using in-band leap indicators from upstream servers.
>> Lower-stratum devices could use their own leap second information to
>> correct for operational or implementation errors upstream.
>>
>>> The potential approach with tzdist or special DNS allowed for a
>>> distributed system, where the special DNS can only provide leap second
>>> warning and the current TAI offset, while tzdist also provides the leap
>>> second history, and a way to update time zone rules, so it could be
>>> generally used to keep also conversion to local time correct.
>> Oh, I forgot about the DNS publication scheme. That would also help a lot
>> if it were implemented. And maybe better than relying on sufficiently
>> frequent software updates.
> 
> So, thing is, since 1972, no common and official way to automatically
> obtain the Leap Seconds information has been adopted. Its an obvious
> missing link, missing for 4 decades! I'd find this just incredible
> except I've now come accept this sort of frustration where timekeeping
> is concerned. This has been discussed many times on LEAPSECS.

Hm, I think there was no such requirement when NTP was introduced. Folks
were happy that they could at all forward leap second announcements,
which was sufficient then.

The leap second file was introduced by Judah Levine in 2000, AFAIK, see:
http://tycho.usno.navy.mil/ptti/2000papers/paper34.pdf

This was probably because it became more important to know the history
of leap seconds, and thus the TAI offset. Ntpd's "autokey" feature was
(mis-)used to be able to pass the TAI offset down to clients.

As I wrote in another email, when autokey is obsoleted by NTS then
eventually another new NTP extension field is required to be able to do
this via the NTP protocol.

Anyway, it's quite a number of years.

> Ideally there would be one, and only one, TAI-UTC table, in some very
> well specified form, residing somewhere in cyberspace, administered and
> maintained by official rules and regulations by the IERS. There then
> could be many API's via many technologies to access the information.

Agreed.

> Today, there are many ways to get it, but they are all in different
> forms, not always so well specified, and all require some human
> intervention or oversight somewhere between the IERS announcements and
> the distribution. None of them are particularly "fast", imposing too
> much overhead on the receiver in some circumstances. And "many ways to
> get it" does not inspire confidence that each implementation will get
> everything the same.
> 
> I like the DNS publication scheme because you could imagine that IANA
> could take responsibility for maintaining it, especially if there were
> an official way to keep it automatically updated from a hypothetical
> official IERS source.

Yes, but if you have a greater view of the system then this fixes only
the leap table issue, which may be sufficient for many purposes.

The tzdist protocol, however, has the advantage that it can also
distribute updated time zone descriptions, so you can update everything
from the kernel/TAI up to user spaces applications dealing with local
time in a single service.

You could build up a tzdist server hierarchy similar to NTP stratums or
DNS root and secondary servers to distribute the information, and the load.

> One could imagine, and it would be straight forward, to have NTP servers
> provide the TAI-UTC table, announcements, and expiration via the same
> IPC transport mechanisms used by NTP. Again, hopefully, updated from a
> hypothetical official IERS source.
> 
> I've had the thought that Block-chain would be a good way to do it. It
> would have all the purported anonymity, security, and persistence
> qualities of Block-chain. In such a scheme, only IERS could make updates
> to it and everybody else could read it.
> 
> It makes sense that the Leap Second Table be combined with time zones,
> as it is in Tz Database, because you really need all the local time
> information together with Leap Seconds to achieve comprehensive
> timekeeping. It occurs to me Tz Database could also be maintained as
> Block-chain.
> 
> The typical methods used in NTP, GPS, and PTP of distributing only the
> upcoming Leap Second announcement has always seemed fragile and
> incomplete to me.

I don't fully agree here. The question is what you need.

tzdist is the latest protocol which can distribute the full leap second
history, if you need it.

PTP and GPS are older but provide at least the TAI offset and warning of
an upcoming leap second.

NTP by far the oldest protocol which basically only provides a leap
second warning, but has optional (not so obvious, and soon obsolete)
extensions which can distribute TAI offset to its clients.

> The lack of reliable automatic information from IERS
> means some human intervention must occur in the announcements, and the
> information is incomplete, only communicating the immediate upcoming
> current Leap Second. Many systems will need to go elsewhere to get the
> full table and expiration, and this leads to possible mismatches between
> information sources, as noted in this thread.

Human inventions will always been required to update the leap second
information. This can be a person at IERS, or some other folks.

The IERS just started to provide an own leap second file a few years
ago, after I had contacted them and asked them to do so since they are
the authoritative source for leap second decisions. Before that they
weren't even aware how important this stuff is.

> Meantime, all this is happening in an environment where the underlying
> specifications are difficult to understand, in some respects possibly
> controversial, and the de facto standards of Tz Database are unofficial
> and don't match Microsoft's world view.

Ouch. I don't know why TZ should adopt to Microsoft's world view. AFAIK
TZ recently had its 30th anniversay, it was invented in 1986.

The first Windows versions were also available at that time, but just as
a frontend to DOS which knew nothing about time zones and UTC.

Windows NT was the first Windows version where the system time ran in
UTC, and AFAIK NT was released in 1993, when TZ already existed for a
couple of years.

Martin