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.