Re: Predictable Internet Time

Paul Eggert <> Tue, 03 January 2017 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9A50129795 for <>; Tue, 3 Jan 2017 13:59:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u9ixQoxEADfa for <>; Tue, 3 Jan 2017 13:59:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5627A12973A for <>; Tue, 3 Jan 2017 13:59:16 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2826B16005F; Tue, 3 Jan 2017 13:59:16 -0800 (PST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10032) with ESMTP id jp5u6FXJpmnq; Tue, 3 Jan 2017 13:59:15 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0820316006F; Tue, 3 Jan 2017 13:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id zeT6E81j8cJ2; Tue, 3 Jan 2017 13:59:14 -0800 (PST)
Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU []) by (Postfix) with ESMTPSA id DD79816005F; Tue, 3 Jan 2017 13:59:14 -0800 (PST)
From: Paul Eggert <>
Subject: Re: Predictable Internet Time
To: Eliot Lear <>, Patrik Fältström <>
References: <> <> <> <> <> <> <> <>
Organization: UCLA Computer Science Department
Message-ID: <>
Date: Tue, 03 Jan 2017 13:59:10 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: Phillip Hallam-Baker <>, IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2017 21:59:18 -0000

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

3. 2016-07-19 NIST file copied into the development repository at

4. 2016-09-13 released as part of tzdb 2016g

5. 2016-12-31 leap second occurs

(2)'s date is estimated, as 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.