Predictable Internet Time

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 31 December 2016 21:32 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F361295AC for <ietf@ietfa.amsl.com>; Sat, 31 Dec 2016 13:32:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AR3hI38C7HF for <ietf@ietfa.amsl.com>; Sat, 31 Dec 2016 13:32:23 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEC01294A3 for <ietf@ietf.org>; Sat, 31 Dec 2016 13:32:22 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id t79so380557414wmt.0 for <ietf@ietf.org>; Sat, 31 Dec 2016 13:32:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=jpcP7h24aI3K7Tpdca79KEkm6BIXTh4AxiIFecE12yU=; b=LsmE3P5zv6I+XNBk9stYCbF3zL/mgYINj7RNPhMlMJDeCw5nKKZMcCfJ0kzPokiMhr 4otVxN95f12ZE0BHJQYnvCeMAVv2FVPB3Mh0+YAZBdc/L0ATwQlaG2SpRu6svMOCP3+R eZjP+h4bLXDHL5qpfp8N0ewimnBL0pdSEYo5PHXxG7Ialul4ZZu0s1ZH+kgr6pSh97rs Cn4Q2XPSIAbRHHVRWxPnZdYkpUrQHEG7sl3jUFE9im8Q5l1qoWKxkzsDFYivnAVnX1AU niubej2Ga4ldeBuHrbXWNdxxvQKH86irK6PupqmkBHDtfTOKeCj7sKW9XqklDZTFLGjj orEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=jpcP7h24aI3K7Tpdca79KEkm6BIXTh4AxiIFecE12yU=; b=ESnAr/eqPWCBtBDYSo/g3A6ZEaMkbzf6UewASrLd+sXBnfh8tm6m2lD2om0c8zhnEL EfCXExcRmSSrj3521eE4673vWHFb4SDEm7qRJs2NuqJNQx8Xe3IGDf7FxnCd7tFFTBCW LxdYwD2wonYQZxxE0WZI1etth7QALd1YszFuueVSrci4zANAbugpByzRtWHrsPSFZb/U vMWxlm8RCAc+6XyXNrTjGLhZmgqTfiSuReXGa7nsh8fiPEwzSYQhoJV6a64uKxr/QQkM tKMHCiM6q3Tk8aCTVUPVkyxbe0TbsrMvy71MJaNnaeMvYiOAbNyMHVCK8Ed/gxDKj8Fp UqXg==
X-Gm-Message-State: AIkVDXKHan9pgg9RBSErxta9HEY8h9GDF19rb62sIX8keefVzj+bEy8erodPmgygIzk3U1IyZH0hgQAlFTwawQ==
X-Received: by 10.28.4.195 with SMTP id 186mr42391661wme.13.1483219940662; Sat, 31 Dec 2016 13:32:20 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.83.101 with HTTP; Sat, 31 Dec 2016 13:32:20 -0800 (PST)
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 31 Dec 2016 16:32:20 -0500
X-Google-Sender-Auth: rJSbCD63QLBjDVl3UyPvGkh4YAw
Message-ID: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com>
Subject: Predictable Internet Time
To: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141f028afe9730544fb0dea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/To8dZTn9uBJLnzqIvEDPpNnA1rc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Dec 2016 21:32:24 -0000

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.

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.