Re: Predictable Internet Time

Nico Williams <> Tue, 28 March 2017 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DACD21297ED for <>; Tue, 28 Mar 2017 12:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.796
X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bNJnFe7-vxOu for <>; Tue, 28 Mar 2017 12:16:59 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A82F129686 for <>; Tue, 28 Mar 2017 12:16:59 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 952BA1406B20; Tue, 28 Mar 2017 12:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s=; bh=BFrujY9Kk3yxCv+4nIifUeBNhE4=; b=X3inlM0bLTF 6DQzQ5apjkphi7rCw3Sj8YwWUetMdpG57R30aXpoelxVoBzS4XFIf46bsoD5Mqe+ HBHj+6PtjDcJRPhP4WjoSAF7l4gfVg90ZJ+S+SOG31yeH404LAQHE0bxQSGinByL 6S0WigmC2dJH6apSm8KPacL0nGKS5fV4=
Received: from localhost ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 49D9E1406B1F; Tue, 28 Mar 2017 12:16:58 -0700 (PDT)
Date: Tue, 28 Mar 2017 14:16:55 -0500
From: Nico Williams <>
To: Phillip Hallam-Baker <>
Cc: IETF Discussion Mailing List <>
Subject: Re: Predictable Internet Time
Message-ID: <20170328191654.GH7490@localhost>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Mar 2017 19:17:01 -0000

On Sat, Dec 31, 2016 at 04:32:20PM -0500, Phillip Hallam-Baker wrote:
> Well the astronomers are at it again. They are messing about with time
> which is a terrible idea. Specifically they are adding another leap second.
> [...]
> So to remove the confusion entirely, while preventing the need for a
> discontinuous adjustment of the drift between UTC and TAI, I propose the
> Predictable Internet Time (PIT) as follows.

We have two kinds of time today: UTC on the one hand (has leaps) and
TAI (and POSIX) on the other (has no leaps).  Converting between the two
requires a leap second history.

Leap seconds are not that predictable.  Significant seismic events
(e.g., the 2004 earthquake and tsunami) can measurably alter the speed
of Earth's rotation on its axis.

You propose a new kind of time that lies between UTC and TAI.
Conversions between this new type and TAI would still need adjustment as
leap second rates change, while conversions to UTC would still need a
leap second history _and_ said adjustments.

I imagine many would code-inject PIT at run-time as being POSIX time.

> Nor is changing the definition of UTC to effect simultaneous change a
> feasible solution because to do so would be to demand the astronomers
> accept a diminution in their own prestige.

Or a new time "data type" just for them, but leaving UTC = TAI + 36
after a certain date because UTC has been used widely for non-astronomy-
related purposes.

> With a suitable definition, PIT could create a condition in which it would
> only take a decision by one major government to force a change on the
> astronomers. The commercial advantages of PIT over UTC are obvious - fewer
> things are going to break for no good reason. That is an argument that
> every politician is willing to listen to.

Do we have this much influence?  If we do, why not just... lobby for
fixing UTC and creating an TAC (tempt astronomique coordiné) to serve,
for astronomers, the function that UTC serves today.

> While a variance of a second or three between New York and London might be
> inconvenient, [...]

For some apps that could be terrible.  Now developers will have to think
about 200% more time conversions.  Not exactly thrilling.