Re: [Ntp] Finding leap-seconds.list

[Martin Burnicki <[e-mail]>]

Hal Murray wrote:
> [e-mail] said:
>> Agreed. But it would be the benefit of using the TZDIST protocol that this
>> could work similar to a combination of DNS and the NTP pool:
> 
>> A "root" TZDIST server could be provided with an update, so secondaries or
>> pool servers could grab the information and pass it on down the line to the
>> final clients. 
> 
> Is there code available?  Server?  Client?

During the discussion of the protocol there was a tzdist mailing list
hosted at IETF.
https://www.ietf.org/mailman/listinfo/tzdist

However, this original mailing list doesn't seem to exist anymore, but
the archive is still there:
https://www.ietf.org/mail-archive/web/tzdist/current/maillist.html

In the meantime, 2 new mailing lists have been created:

tzdist-bis      https://www.ietf.org/mailman/listinfo/tzdist-bis
tzdist-service  https://www.ietf.org/mailman/listinfo/tzdist-service

(I already knew about the first one, but just discovered the 2nd a
minute ago)

What I recall from memory is that there are test implementations for
client and server, and a test server was online. I don't know if it
currently still is.

Anyway, AFAICS there are still some problems to resolve: how to
integrate the data a client receives from a server.

Once I have a TZDIST server running, and a client that receives the
data, how to use the received data?

Can the TZDIST client update a local TZDB file on the fly?

If it can do this, can an application detect that the TZ rules may have
been updated, and seamlessly start using the new rules, or has the
application to be restarted to let the new TZ rules take effect?

In a recent discussion (I think it was on the TZ mailing list) someone
said that certain versions of IOS and Android may have some other ways
to update their timezone information, but the device has to be
*rebooted* to let the changes take effect.

Similar e.g. for ntpd and the leap second file: A current versions of
ntpd detects at runtime when the specified leap second file has been
updated, and re-reads the file, so the leap second and TAI information
can be updated on the fly.

However, a TZDIST client would need to be able to (re-)write a leap
second file if required, or some other mechanism needed to be invented
to pass the updated data to ntpd.

So IMO here's still much room for improvements.

Some time ago I proposed on some mailing list to try to get a "Google
Summer Of Code" project for some implementation, but that didn't happen.

I have to admit that lately I haven't followed the TZDIST discussions
very closely, so there might have been some progress in the mean time.

Sorry for the long post which is partly off topic here, but IMO there
are a number of things that need to be considered for an overall time
synchronization system.

> Should we ask IANA to run a server?

IMO This would only make sense if there are clients that interact and
integrate seamlessly with other time synchronization components.

Anyway, I think this is a very good approach, and the preferred
direction to go.

Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy