Re: Predictable Internet Time Sun, 01 January 2017 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CFF7126BF7 for <>; Sun, 1 Jan 2017 07:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tc_xYipWvEZC for <>; Sun, 1 Jan 2017 07:58:55 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 122721200A0 for <>; Sun, 1 Jan 2017 07:58:55 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 6C0616001104 for <>; Sun, 1 Jan 2017 07:58:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :from:to:in-reply-to:subject:date:content-type:mime-version; s=; bh=9y31okB+R+3FJ86mOp5qLHR/lJY=; b=fzguV6f9Gn7WbWOdI fdrRIXSzuGM4xlaB5ouQWnjJWnqI7kW/ku3V7/LO30ui33mRf2/py+2aCTsktVsJ qSadVpWAri+yomqytB7JCKNWY5DksQBcCgVfg0uuCELBd4odc/GdPJzTNYIKgrIU hcn07UU8myyTSxna5DOg8xBUGE=
Received: from localhost ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 62CC36001103 for <>; Sun, 1 Jan 2017 07:58:54 -0800 (PST)
Message-Id: <>
To: IETF Discussion Mailing List <>
X-Mailer: Atmail 7.5.3
in-reply-to: <>
Subject: Re: Predictable Internet Time
Date: Sun, 01 Jan 2017 10:58:54 -0500
Content-Type: multipart/alternative; boundary="=_1fd680ae7b443263b98f7d3c38e5a3b7"
MIME-Version: 1.0
Archived-At: <>
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: Sun, 01 Jan 2017 15:58:56 -0000

   The (human) universe has competing time standards.  How much of
this problem is mitigated by time services?  I mean, if every device
that cared about a common time was kept in synch by timeservers, and
all the timeservers updated together, wouldn't that fix the problem? 
if so, the problem is really that not everything has access to
timeservers.  Many devices aren't always on the net, and when they
are they have better things to spend bandwidth on than constant time
   How much of this problem can be solved by better time services,
and how much of the problem cannot be?

Sandy Wills
interested lurker

----- Original Message -----
From: "Phillip Hallam-Baker" <>
To:"IETF Discussion Mailing List" <>
Sent:Sat, 31 Dec 2016 16:32:20 -0500
Subject:Predictable Internet Time

Well the astronomers are at it again. They are messing about with time
which is a terrible idea. Specifically they are adding another leap
There are many arguments against leap seconds and the arguments in
favor really amount to the astronomers declaring that they are going
to rub our noses in it for as long as we let them. So here is an
alternative proposal.
The single biggest problem with UTC is that the decisions to add
seconds are made by a committee a few months in advance of the change.
And this results in time becoming unpredictable because it is never
possible to know if we are dealing with a corrected or uncorrected
time. For this reason, I have been using TAI as the basis for time
representation in my recent protocol proposals. This reduces but does
not eliminate the confusion.
Leap seconds occur at a rate of roughly ten per 25 years. So not
correcting means a drift of 40 seconds over a century

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.
PIT = TAI + delta (y) where
Where Delta (y) = int (37 + 0.4 * (y -2016) ) for y < 2116= 77 +
(UTC-Delta (y-100))
For values above 2116, PIT would make use of the table of UTC
corrections with a delay of one century. This would enable
manufacturers to build devices with built in correction tables for a
design life of one century which should meet everyone's needs except
Danny Hillis who is building a clock anyway.

A conversion to PIT would be feasible for most governments as it is
highly unlikely that the variance between UTC and PIT would ever be
greater than a few seconds.
The big problem with planning such a transition in the past is that
the alternatives on the table have been stopping further leap seconds
completely and continuing the UTC scheme. That would be a recipe for
disaster unless the EU and US both adopted TAI+36 seconds or whatever.
We could end up with a situation in which one side digs in its heels,
refuses to change and we end up with a 'give us back our eleven days'
type correction.
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.
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.
While a variance of a second or three between New York and London
might be inconvenient, the inconvenience is going to be a lot worse
for the side not using PIT who have all the inconvenience of
unpredictable leap seconds plus the inconvenience of the difference.
The pressure on other governments to adopt PIT over is going to be
significant. It is hard to see that there would be any real
constituency for the UTC approach, the astronomers are much more
interested in buying telescopes than time in any case.

We could tweak the definition so that the corrections kick in sooner
but it should be possible to build for a minimum of a fifty year
service life.