Eliot Lear wrote:
I think the maintainer (Paul, CC'd) does tend to give it some priority.
Some priority, but not higher priority than other changes, and in
particular we don't necessarily generate a tz release immediately after
each IERS announcement.
For some perspective on this, here is a time line for the most recent
leap second:
1. 2016-07-06 announced by IERS
2. 2016-07-08 installed by NIST into
ftp://time.nist.gov/pub/leap-seconds.list
3. 2016-07-19 NIST file copied into the development repository at
https://github.com/eggert/tz/blob/master/leap-seconds.list
4. 2016-09-13 released as part of tzdb 2016g
5. 2016-12-31 leap second occurs
(2)'s date is estimated, as ftp://time.nist.gov/pub/leap-seconds.list is
a flaky FTP server mirror farm. Sometimes it works, sometimes it
doesn't. When it doesn't work, it doesn't work for what seems like days.
(It's been this way for years.) I got leap-seconds.list from someone
else who retrieved it (someone who I trusted).
We cannot use the IERS announcement directly in the tz database because
of copyright restrictions on the IERS files. We can use the NIST
leap-seconds.list file because it is in the public domain. The delay
between (1) and (2), and to some extent between (2) and (3), is due to
NIST. The delay between (3) and (4) is because there was no sense of
urgency until a few weeks before a predicted change - any
automated-update procedure that relies on tzdb should be able to turn
the crank in less than a month, because that's all the notice we often
get for time zone and daylight savings changes anyway.
I don't know why anyone would need more lead time for tzdb leap-second
updates (as opposed to time zone and DST updates). However, if there is
a need, they can get leap-seconds.list from the development repository
on GitHub, or from NIST if NIST is up, or simply by editing their
leap-seconds.list file by hand. It would be nice if leap-seconds.list
were distributed more reliably, of course.