[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Data updates in debian packages

On 10/31/2016 09:07 AM, Ole Streicher wrote:
> Russ Allbery <rra@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.


Reply to: