Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

Philip Prindeville <philipp@redfish-solutions.com> Tue, 05 January 2021 20:11 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 0D6333A11B1 for <ntp@ietfa.amsl.com>; Tue, 5 Jan 2021 12:11:22 -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 9f12UzNsKzyg for <ntp@ietfa.amsl.com>; Tue, 5 Jan 2021 12:11:20 -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 CEBB93A11AE for <ntp@ietf.org>; Tue, 5 Jan 2021 12:11:20 -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 105KBKt0354535 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Jan 2021 13:11:20 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Philip Prindeville <philipp@redfish-solutions.com>
In-Reply-To: <35c4be55-b6af-82b5-aacd-d5a591383dec@rubidium.se>
Date: Tue, 05 Jan 2021 13:11:19 -0700
Cc: Miroslav Lichvar <mlichvar@redhat.com>, ntp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <99468545-A9B8-443B-91CC-887DBABC9B42@redfish-solutions.com>
References: <20210102081603.1F63C40605C@ip-64-139-1-69.sjc.megapath.net> <cecaf661-92af-8b35-4c53-2f025c928144@rubidium.se> <20210104164449.GE2992437@localhost> <b1e61f7d-6cea-5e99-69f0-7eae815d9e19@rubidium.se> <20210105083328.GA3008666@localhost> <ba5d2cde-6b5e-d9b6-1877-c4060bf43e80@rubidium.se> <20210105144225.GH3008666@localhost> <35c4be55-b6af-82b5-aacd-d5a591383dec@rubidium.se>
To: Magnus Danielson <magnus@rubidium.se>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-Scanned-By: MIMEDefang 2.84 on 192.168.1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/DPsOdP4_GPNFkkGs8ecjvrHS4JE>
Subject: Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)
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: Tue, 05 Jan 2021 20:11:22 -0000


> On Jan 5, 2021, at 8:51 AM, Magnus Danielson <magnus@rubidium.se> wrote:
> 
> I lean towards pushing the conversion requirement onto the NTP source
> nodes just to achieve the intended cleanness of the rest of the
> infrastructure.


I’m going to push back against that.

I think that many protocols embed human-readable time notation unnecessarily.  Take the syslog protocol.  Is there a reason why it couldn’t just have used TAI time in seconds and milliseconds (or microseconds), and left it to some browser to do the rendering or “presentation” into a human-preferred format?

Take video security cameras.  Do they need to know that a particular timestamp corresponds to a minute/day/month/year/leap-second?  I don’t think so.  I think the browser there, too, could do the conversion.

Has anyone ever tried to run a “make” on a large code base just as a second leaped?  It’s a mess.  A lot of things get rebuilt unnecessarily.  And that’s with forward leaps.  If we ever need to shorten a day, I can’t begin to image how badly things will break.

This wouldn’t happen if we let machines deal with a representation of time that’s optimal for them (i.e. simple and unambiguous) and held off on conversion to human-readable format until it was actually necessary.

As a postmaster for 30 odd years, I’ve had to struggle with Received: lines having local dates and times that require me to pay attention to the UTC offsets to be aware of when DST took place (if it took place at all) for each timezone that a server lived in as it handled a message.  It’s a mess.  RFC-822 should have mandated UT or Zulu time (as that was the best we had at the time).

Or having logs sent to me, or logging into remote machines, and having to know the timezone of the provenance of those logs, then doing the math in my head to match that up with other events elsewhere.

Simple, unique, unambiguous, and universal time is what machines need.

Conversion to something that’s convenient for humans should be deferred until absolutely necessary (and it may never be!).