Re: [Ntp] Finding leap-seconds.list

[Warner Losh <[e-mail]>]

On Fri, Nov 9, 2018 at 8:47 AM Danny Mayer <[e-mail]> wrote:

> So the real question is whether or not we need to formalize the
> distribution of the leap-second file and how would we accomplish that?
> Also how would it be kept uptodate? For that matter is there an
> agreed-upon standard format for the contents of the leap-second file?
>

The format is "standardized" in a fashion. It's documented in the
leap-second file itself, and all NTP implementations use the same format.
I'd be surprised if the current ntp standard doesn't define it (I've not
checked).

There's at least 5 other formats this data exists in on the internet, but
ntp doesn't use them, nor do people grab that data and convert to the ntp
leap-second.txt format unless they happen to need it for other purposes and
get a 'twofer' by doing so.

It would be possible to generate the file from the archive of Bulletin-C's
that IERS publishes, coupled with the programs that are available at the
same web locations to add the SHA1 checksum data. Scraping them from the
IERS web site would be straight forward. To do it adequately, you run the
cron job Feb 1 and Aug 1 and you'll be able to generate the new file then.
To do it robustly, you may need to things monthly or weekly (as 460's
schedule for leap seconds allows the end of any month to have one), but
then you get into the crazy world of edge-case-hell that people that try to
guess from the current standards what future IERS edicts say get into. Do
you make it future proof, or do you assume that past practice is sacrosanct
and that any deviation from it will generate a new standard, or do you
assume they will follow 460's recommendations that people have, at best,
imperfectly implemented outside of June/December leap seocnds? When I was
younger, I'd say follow the published spec (and I did that at least twice
in my carer). Now I'd say follow existing practice and cope if they change
it. Testing of even the secondary dates showed that far too many things get
things wrong there (and some well known bugs where leap indications were
turned on too early lead some devices to bogusly assume it was the
march/september dates, even though the data in the data stream clearly
indicated the right dates).

As for what's best to do to keep it up to date? Beats me. It's more of the
tragedy of the time commons that Dr Allen referred to that something this
simple and basic has been so manual for so long.

Warner