[tz] tzdata for 2016 leap seconds
sla at ucolick.org
Fri Sep 2 16:53:31 UTC 2016
On Fri 2016-09-02T09:41:31 -0700, Paul Eggert hath writ:
> whereas I was asking about end-user applications that need
> months-in-advance notice of leap seconds. As Bradley writes, most of
> the world that cares about leap seconds uses NTP and does not depend
> on tz-derived leap seconds information.
I think anything which handles a leap second is a hack which is
violating a standard from one agency or another, the implementors are
not wont to describe that or how they are violating a standard, there
is inconsistency between implementations, and no generalization
applies to how the information is being used.
> Changing the subject slightly, ICANN is not able to provide leap
> second data to billions of clients directly, as we don't have the
> capacity. For example, widely-used client code should not poll
> ietf.org or iana.org (or github.com!) to grab the "latest" leap
> second data. I'm sure you know this; I'm just stating the obvious
> for readers who may not be aware of the practical limitations.
Of course one of the problems is that no agency has ever undertaken
the infrastructure needed to robustly perform that task. The regulation
remains worded and implemented as if urgent telecomms rely on telegrams.
Steve Allen <sla at ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
More information about the tz