Re: [Ntp] Timescales

Philip Prindeville <philipp@redfish-solutions.com> Thu, 10 December 2020 00:33 UTC

Return-Path: <philipp@redfish-solutions.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF73A03F5 for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 16:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Lk7VUUsfzGWC for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 16:33:11 -0800 (PST)
Received: from mail.redfish-solutions.com (mail.redfish-solutions.com [45.33.216.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E4B3A03F2 for <ntp@ietf.org>; Wed, 9 Dec 2020 16:33:11 -0800 (PST)
Received: from [192.168.3.4] ([192.168.3.4]) (authenticated bits=0) by mail.redfish-solutions.com (8.16.1/8.16.1) with ESMTPSA id 0BA0X8ru216581 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 9 Dec 2020 17:33:08 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <20201209162923.GO2553@ucolick.org>
Date: Wed, 09 Dec 2020 17:33:08 -0700
Cc: NTP WG <ntp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F1027EF-4ED3-4C54-873F-D9912F03CEDA@redfish-solutions.com>
References: <20201209101830.7CB0240605C@ip-64-139-1-69.sjc.megapath.net> <058712d2-d031-65a6-d816-0b28c56cf87b@rubidium.se> <20201209162923.GO2553@ucolick.org>
To: Steve Allen <sla@ucolick.org>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/iN7D8heJP9nDwJBOrogWVBeW7NY>
Subject: Re: [Ntp] Timescales
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2020 00:33:13 -0000


> On Dec 9, 2020, at 9:29 AM, Steve Allen <sla@ucolick.org> wrote:
> 
> On Wed 2020-12-09T14:06:50+0100 Magnus Danielson hath writ:
>> The most robust solutions is creating a time-scale that is some
>> well-defined shift from TAI, and then provide the TAI-UTC difference
>> explicitly along with a pre-warning system. Look at for instance GPS [1]
>> and PTP [2]. I've chosen this path myself and it has worked very nicely.
>> 
>> So, this is not a crazy idea, it's robust engineering proven in battle.
>> 
>> What is problematic is able to support backward compatibility to the
>> classical NTP time-scale as this needs to be handled in all time-stamps.
> 
> The extended discussion in the NTPWG now is strikingly similar to the
> arguments in the late 1960s which resulted in leap seconds.
> A 1969 report analyzing the options pointed out that leap seconds
> would cause problems in precise timing systems used for navigation.
> Backward compatibility concerns forced the international agreement to
> have leap seconds.  Before the first leap second the technical members
> of the committees proceeded to change their operational systems to use
> purely atomic time with no leaps, and that choice was repeated for
> GPS, Galileo, BeiDou, etc. because it was the only robust way.


Maybe I’m just slow, but I’m not getting any of this discussion.

It seems to me that time advances, only, and at a fairly constant rate (barring relativistic shifts as the earth accelerates as it moves in the same direction as the sun’s trajectory, vs. decelerating when the earth’s orbit takes it in the opposite order as the sun’s trajectory, etc.).

It simply goes “tick tock tick tock”… and that’s all it does.

Anything relating to mapping to dates and times on a calendar is a purely “presentational” thing, like preferring decimal over octal or hex or binary…

It seems to me we’re overthinking things.

Or worse, assuming we’re the only ones that really understand time, and deciding “we” should fix it “here” because we understand it, rather than letting “them” fix it “there” because we don’t trust others to do so adequately.

What am I missing?

-Philip