On 10/31/2016 09:07 AM, Ole Streicher wrote: > Russ Allbery <r...@debian.org> writes: >> The required timeliness depends a lot on what you're using leap seconds >> for, and in particular if you need to know about them far in advance, or >> if it's only necessary to have an updated table before the leap second >> itself arrives. > > We need it to put correct time on astronomical registrations, so it is > most important to have them once they are effective. Having them in > advance would be an additional plus, however, since f.e. a computer may > be disconnected during/after the observation, if that happens on a place > without internet connection.
Data might help here, so I've looked at the past 3 leap seconds that were introduced (I don't think it makes sense to go further back, because the one before that was 2009, and that's probably too long ago to draw conclusions): Leap second | Jun 2012 | Jun 2015 | Dec 2016 ------------+------------------+------------------+----------------- IERS ann. | 2012-01-05 | 2015-01-05 | 2016-07-06 tzdata rel. | 2012a 2012-03-01 | 2015a 2015-01-29 | 2016g 2016-09-13 sid | 2012b 2012-03-06 | 2015a 2015-01-31 | 2016g 2016-09-28 stable | 2016c 2012-05-05 | 2015a 2015-02-01 | 2016g 2016-10-03 stable PR | 2012-05-12 | 2015-09-05 | not yet | | (now oldstable) | oldstable | (Lenny EOL) | 2015c 2015-04-17 | 2016h 2016-10-26 "stable" means stable/updates (former volatile), "stable PR" means the stable point release that gathered up the all stable/updates, stable-security and stable/proposed-updates and "oldstable" means squeeze-lts and wheezy-security. (In both cases they were already LTS, no leap second in the last 6 years has fallen into a window where we had oldstable not being LTS.) Note that the "stable PR" metric just shows you that you don't want to run a system that needs up to date leap seconds data without having stable/updates enabled, just because point releases are too infrequent. (But that would apply to a new package tracking just the leap seconds data from IERS as well.) What this does say is that stable/updates and oldstable (LTS) had updated leap seconds information slightly less than 3 months before the leap second, in some cases even a bit earlier. If we are going to assume that in a perfect storm this might be a bit worse, then I think one can say that roughly 2 months in advance of a leap second any officially supported Debian version will have updated an tzdata package. (If you enable the proper repositories.) (Btw. leap-seconds.list was only introduced upstream in 2013, and packaged in the binary package in 2015; before that only the binary rules files for each time zone contained the leap second info. See <https://bugs.debian.org/775166>. However, since this is used by DSA, this is going to be kept around.) Hope this information helps in you evaluating this. Regards, Christian