"Poul-Henning Kamp" <[email protected]> wrote: |-------- |In message <20150114115758.gvgcdclg%[email protected]>, Steffen \ |Nurpmeso write |s: |>"Poul-Henning Kamp" <[email protected]> wrote: |>|-------- |>|In message <[email protected]>, Magnus \ |>|Danielson writes:
|>|What would be really useful would be if they provided the current |>|leapsecond count and the date of the next (if known) via DNS. |>| |>|DNS because it has built in caching and works almost everywhere. |> |>Or a new NTP protocol, that would only require a software update |>of NTP servers. | |NTP is a much more specialized protocol than DNS and it is blocked |a lot of places. But you need to invent a new RR and update resolvers for that. Or do at least the latter if you use some existing type. Hmm, or you get that terrible politics going and define a new virtual A record that carries the necessary information, say 8-bit per label, least significant last. So i apologize, such a thing would indeed even be a great idea, fetchable via a simple getaddrinfo(3) / dig(1) call and automatically replicated from the DNS root servers down to the last zone! (Of course DNSSEC is horrible, in my humble opinion. And your scheme will have problems at and after the days which actually introduce leap seconds. But just as is today for those computers which get their leap information only via the TZ database.) |>The current one is obsolete anyway in ~20 years, Iirc NTP will get storage overflow problems in the mid (20)30s, but that could be changed with a new protocol version, and if there would be such a one then that could solve the problem with TAI / UTC and their offset at the same time, even though that would mean that some time providers would (possibly) be left behind (though the German DCF77 radio transmitter, for example, has seen some very strange retargeting in the last years, which could be re-redefined and then possibly transport the necessary changes). For most normal -- whatever that is -- consumers NTP is more than sufficient, and if it'd track all the necessary information with each and every packet to get at TAI and UTC then what else is needed for these clients? And it's worth noting that passing the leap offset as a regular part of a NTP packet can be compared with a locally stored value, just like a regulary saved NTP drift can. For example, to not reject a drift too large and possibly even apply a Markus Kuhn smear locally, if so configured. Anyway: options you don't have right now. Because you have none, and the ten thousand lobbyists that want to introduce marsian time on earth won't change that, really. Or scratch that last sentence if you want to. --steffen _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
