[ntp:questions] Number of Stratum 1 & Stratum 2 Peers

Martin Burnicki martin.burnicki at meinberg.de
Tue Dec 16 11:48:57 UTC 2014

Brian Inglis wrote:
> It would be interesting to know what percentage of the pool servers even
> use
> a leapseconds file, and how many of those have a valid copy.
> I am certain that very few clients use a leapseconds file.
> OTOH the timezone/zoneinfo package uses its own leapseconds file (for
> "right"
> time - now zoneinfo-leaps), and distributes that and the original, a script
> that checks and converts it to their own format, and utilities that use it.

As far as I can see the the leap second file shipped with the tzdata 
package is generated automatically from a leap second file in NIST format.

However, there is an important limitation: the tzdata version of the 
leap second file is missing an expiration date, so even if a program 
like ntpd could use this file directly it would never know if no more 
leap second has been scheduled after the last one mentioned in this 
file, or if the file just hasn't been updated recently enough.

There is an ongoing discussion about a new "tzdist" protocol which could 
be used to deploy updated time zone rules as published by the tzdata 
package automatically, without the need to pull in a new tzdata package 
in the form of a software update.

This sounds like a very good extension to programs like ntpd:

- NTP (or PTP) takes cares that the computer's UTC time is correct

- tzdist takes care that the DST rules are updated automatically

The latter may not be too important for countries where the DST rules 
don't change very often, but can be *very* helpful for countries like 
Morocco, Egypt, or Israel, where these rules are changed every year, and 
the decisions on the beginning or end of DST are only published a few 
days before they actually happen.

Since the tzdist protocol also provides historical time zone information 
I have proposed on the tzdist mailing list also to include a list of 
leap second events in a generic format, which would also allow to 
compute accurate time intervals across past leap second events. Of 
course this proposal includes an expiration date.

Such leap second table could be used to provide programs like ntpd or 
ptpd with automatic updates from a tzdist client, without having to copy 
a file the exact name you may not know from an FTP or HTTP server of 
which you don't know if you are allowed to access it from your 
geographic location (there have been such restrictions in the past).

Unfortunately most participants in the discussion on the tzdist mailing 
list don't seem to accept the importance of a generic way to distribute 
a leap seconds table. Instead, they seem to prefer to accept a way to 
distribute the leap second file as provided by tzdata (without 
expiration date) in a binary format.

Beside this, IMO the IERS should be the authoritative source for a leap 
second file since it is the institution deciding whether a leap second 
is to be scheduled, or not. I've proposed this to the IERS folks, and 
the replied they would "think about this".


More information about the questions mailing list