[tz] leap_second.list not updated after latest IERS Bulletin C

[Hal Murray]

Paul Eggert said:
> Is there some reason we need a new TZDB release because of this? Do you use
> software that requires that this file come from a TZDB release, rather than
> from other sources such as the one mentioned above? 

Yes, NTP can use the leap file from other sources.  The idea of distributing 
it with TZDB is that it removes an operational step from running NTP with 
(hopefully) minimal work on the TZ team and OS distros since they are already 
distributing TZ info.

Debian's ntpsec.conf now contains:
  leapfile /usr/share/zoneinfo/leap-seconds.list


> I recall that traditionally ntpd needed leap-seconds.list and looked at  the
> expiration but am not up to date with what its successor NTPsec is  doing.

NTPsec uses the expiration date.

Long version:

GPS satellites distribute leap second info.  Some receivers pass that on to 
the clients.
So does NIST's ACTS phone/modem time service.
WWVB in US, JJY in Japan, MSF in UK, and DCF77 in Germany also provide leap 
second info.  I'm not sure how many receivers make that available.

NTP can get leap info from 3 sources: file, radio, and network.
  If it has a valid file, it believes that.
  If it doesn't have a file, next in line is a local refclock.
  With no file and no refclocks, it gets leap info from network time servers.

So a valid file when there is no leap pending will keep ntpd from believing 
buggy or malicious NTP servers on the net.

I think there was an event where a bunch of servers didn't stop advertising a 
leap.  It was many years ago.  I've forgotten the details.  I think the code 
was changed from believing one server to requiring a majority.


There is a subtle difference between no-known-leap and known-no-leap.  The NTP 
packet format doesn't have a way to indicate known-no-leap and that gap 
probably percolates through the code.  It may not actually work as I described 
above but that's the way it should work.



-- 
These are my opinions.  I hate spam.