tzdata for 2016 leap seconds
Hi Paul et al, We heard that the tzdata for 2016 leap seconds would be published around Oct. Is there anyway that this can be published sooner? Many of our upstream vendors won't release their tzdata update until the official tzdata is published. Thanks, Jimmy
Jimmy Wang (jcwang) wrote:
Is there anyway that this can be published sooner? Many of our upstream vendors won't release their tzdata update until the official tzdata is published.
This topic has come up recently on the mailing list; please see the threads containing these messages: http://mm.icann.org/pipermail/tz/2016-September/024031.html http://mm.icann.org/pipermail/tz/2016-August/023914.html Briefly, I don't know why end users need leap seconds to be pushed out more urgently than other tzdata changes. Perhaps you could let us know why Cisco's end users need this?
Hello, On 09/02/2016 04:38 PM, Paul Eggert wrote:
Jimmy Wang (jcwang) wrote:
Is there anyway that this can be published sooner? Many of our upstream vendors won't release their tzdata update until the official tzdata is published.
This topic has come up recently on the mailing list; please see the threads containing these messages:
http://mm.icann.org/pipermail/tz/2016-September/024031.html http://mm.icann.org/pipermail/tz/2016-August/023914.html
Briefly, I don't know why end users need leap seconds to be pushed out more urgently than other tzdata changes. Perhaps you could let us know why Cisco's end users need this?
We (SUSE) have already released update due to demand from customer with extraordinarily long patch deployment cycles. In most configurations, however, the leap second announcement is actually received through the ntp protocol from reference clocks, rather than being inserted from a local database. This may vary for appliances but even those should be synced via ntp? Andreas -- Andreas Stieger <astieger@suse.com> Project Manager Security SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Fri, Sep 2, 2016 at 10:47 AM, Andreas Stieger <astieger@suse.com> wrote:
Hello,
On 09/02/2016 04:38 PM, Paul Eggert wrote:
Jimmy Wang (jcwang) wrote:
Is there anyway that this can be published sooner? Many of our upstream vendors won't release their tzdata update until the official tzdata is published.
This topic has come up recently on the mailing list; please see the threads containing these messages:
http://mm.icann.org/pipermail/tz/2016-September/024031.html http://mm.icann.org/pipermail/tz/2016-August/023914.html
Briefly, I don't know why end users need leap seconds to be pushed out more urgently than other tzdata changes. Perhaps you could let us know why Cisco's end users need this?
We (SUSE) have already released update due to demand from customer with extraordinarily long patch deployment cycles. In most configurations, however, the leap second announcement is actually received through the ntp protocol from reference clocks, rather than being inserted from a local database. This may vary for appliances but even those should be synced via ntp?
Just to clarify, the leap-second table in the tzdata is only for running in "right" mode, where clocks tick through leaps and so don't need any indication that leaps happen. Indeed, if you were using "right" mode you would need to modify your NTP stack so that the NTP timestamps and the local-clock timestamps could even be compared.
On Sep 2, 2016, at 11:42 AM, Bradley White <bww@acm.org> wrote:
Just to clarify, the leap-second table in the tzdata is only for running in "right" mode, where clocks tick through leaps and so don't need any indication that leaps happen.
This may be your only use of the leap-second table, but it is not my use. Here is working code for me: #include "chrono_io.h" #include "tz.h" #include <iostream> int main() { using namespace date; using namespace std::chrono_literals; auto t0 = to_gps_time(sys_days{2017_y/jan/1} - 500ms); auto t1 = to_gps_time(sys_days{2017_y/jan/1} + 500ms); std::cout << t1 - t0 << '\n'; } This should output: 2000ms which indicates the insertion of a leap second into my gps_clock a few months from now. Unfortunately it currently (and incorrectly) outputs: 1000ms Howard
I am guessing that leap seconds typically receive more attention because it¹s impacting everyone, where as tzdata impacts just a certain regions? Regards, Jimmy On 9/2/16, 7:38 AM, "Paul Eggert" <eggert@cs.ucla.edu> wrote:
Jimmy Wang (jcwang) wrote:
Is there anyway that this can be published sooner? Many of our upstream vendors won't release their tzdata update until the official tzdata is published.
This topic has come up recently on the mailing list; please see the threads containing these messages:
http://mm.icann.org/pipermail/tz/2016-September/024031.html http://mm.icann.org/pipermail/tz/2016-August/023914.html
Briefly, I don't know why end users need leap seconds to be pushed out more urgently than other tzdata changes. Perhaps you could let us know why Cisco's end users need this?
Howard Hinnant wrote:
Here is working code for me:
Sure, but that uses library code for parsing the tz database source, 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. 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.
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@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
On Fri, Sep 2, 2016 at 11:47 AM, Howard Hinnant <howard.hinnant@gmail.com> wrote:
On Sep 2, 2016, at 11:42 AM, Bradley White <bww@acm.org> wrote:
Just to clarify, the leap-second table in the tzdata is only for running
in "right" mode, where clocks tick through leaps and so don't need any indication that leaps happen.
This may be your only use of the leap-second table, but it is not my use.
Here is working code for me:
#include "chrono_io.h" #include "tz.h" #include <iostream>
int main() { using namespace date; using namespace std::chrono_literals; auto t0 = to_gps_time(sys_days{2017_y/jan/1} - 500ms); auto t1 = to_gps_time(sys_days{2017_y/jan/1} + 500ms); std::cout << t1 - t0 << '\n'; }
This should output:
2000ms
which indicates the insertion of a leap second into my gps_clock a few months from now. Unfortunately it currently (and incorrectly) outputs:
1000ms
Sure, you may use *a* leap-second table. But tzdata only includes one to generate "right" zoneinfo files. Aside: It would be unfortunate, for any expression X, if ((X + 500ms) - (X - 500ms)) was not 1000ms.
On Fri, Sep 2, 2016 at 1:36 PM, Bradley White <bww@acm.org> wrote:
On Fri, Sep 2, 2016 at 1:31 PM, Bradley White <bww@acm.org> wrote:
Aside: It would be unfortunate, for any expression X, if ((X + 500ms) - (X - 500ms)) was not 1000ms.
I missed a call there, oops. (f(X + 500ms) - f(X - 500ms)) I can say nothing about.
Just like a "right" tz's (time2posix(t + 1) - time2posix(t - 1)) does not necessarily return 2.
On 02/09/16 17:53, Steve Allen wrote:
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.
Standards. Wonderful things, that is, things full of wonder. Or something. Posix mandates that there are 86400 seconds in a day while still allowing struct tm to have its tm_sec field in [0,61). The rationale for this seems to be that programmers expect sleep(60) to sleep for a minute (notwithstanding some implementations waking early). It wriggles out of the dichotomy by saying that the epoch that time(2) returns seconds since is only approximately 1970-01-01 and doesn't require gmtime(3) et al to ever return a value with tm_sec == 60. Indeed, given that there are exactly 86400s in a day it's not possible to feed an integer to gmtime(3) et al to get 23:59:60. As you say, though, Steve, different platforms have different non-standard ways of dealing with this. Linux and *BSD's ntp_gettime will return a specific value if you are in a leap second so a wily implementation of gmtime_now() can use that to actually return 23:59:60 when it happens and anyone who wants to store that as a timestamp had better not try to convert it to seconds-since-the-epoch :) jch
participants (7)
-
Andreas Stieger -
Bradley White -
Howard Hinnant -
Jimmy Wang (jcwang) -
John Haxby -
Paul Eggert -
Steve Allen