Re: Predictable Internet Time

Jared Mauch <jared@puck.nether.net> Tue, 03 January 2017 17:07 UTC

Return-Path: <jared@puck.nether.net>
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 00EFF1296AC for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 09:07:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.3
X-Spam-Level:
X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 JXPkaVj1ygMx for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 09:07:41 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id C57DF129629 for <ietf@ietf.org>; Tue, 3 Jan 2017 09:07:41 -0800 (PST)
Received: from [10.233.128.213] (c-69-136-137-113.hsd1.mi.comcast.net [69.136.137.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 3301354056C; Tue, 3 Jan 2017 12:07:39 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail-0200DE6A-52E3-439A-A90C-A25F4D79CC7F"
Mime-Version: 1.0 (1.0)
Subject: Re: Predictable Internet Time
From: Jared Mauch <jared@puck.nether.net>
X-Mailer: iPhone Mail (14C92)
In-Reply-To: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com>
Date: Tue, 03 Jan 2017 12:07:38 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <9F0F8841-BC1D-4C27-83EF-8F93F33FB021@puck.nether.net>
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0LiiDAqnLvPbdtOW4qNjD4wUJmU>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
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: Tue, 03 Jan 2017 17:07:43 -0000

I'd be interested to see your proposal in the NTP WG, at Chicago or earlier. 

I agree this is an area where there is need for improvement and assistance is welcome. 

Jared Mauch

> On Dec 31, 2016, at 4:32 PM, Phillip Hallam-Baker <phill@hallambaker.com> 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.
> 
> 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.