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

Kurt Roeckx <kurt@roeckx.be> Wed, 06 January 2021 10:48 UTC

Return-Path: <kurt@roeckx.be>
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 2A1093A12BC for <ntp@ietfa.amsl.com>; Wed, 6 Jan 2021 02:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 iuyd1ds05l-z for <ntp@ietfa.amsl.com>; Wed, 6 Jan 2021 02:48:53 -0800 (PST)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a05:7300:0:100::3]) (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 4146B3A12BB for <ntp@ietf.org>; Wed, 6 Jan 2021 02:48:52 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 1A83BA8A0062; Wed, 6 Jan 2021 10:48:49 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id D5BA41FE0E02; Wed, 6 Jan 2021 11:48:48 +0100 (CET)
Date: Wed, 06 Jan 2021 11:48:48 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Martin Burnicki <martin.burnicki=40meinberg.de@dmarc.ietf.org>
Cc: Magnus Danielson <magnus@rubidium.se>, Miroslav Lichvar <mlichvar@redhat.com>, ntp@ietf.org
Message-ID: <X/WVkNLUB3q+7BhK@roeckx.be>
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> <f8a1b9fa-887f-3402-d6e9-19dd4fa98e33@meinberg.de> <75348282-d6aa-e1f1-0ab1-4dfbc1379ff4@rubidium.se> <39e28d2c-454d-43f1-ee58-b136187212b1@meinberg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <39e28d2c-454d-43f1-ee58-b136187212b1@meinberg.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/MlVMKV697ysJKVHnWCIOwauWzdo>
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: Wed, 06 Jan 2021 10:48:55 -0000

On Wed, Jan 06, 2021 at 11:24:21AM +0100, Martin Burnicki wrote:
> > 
> > Indeed. I am confident that the client can be very simple and provide
> > the right time, even with leap seconds occurring.
> 
> Of course. But the limitation is in the server. Right now, it is
> sufficient to have a time source like DCF77. If you enforce using of
> TAI, that's not sufficient anymore.

If you combine it with the leap second info, you can get TAI and
UTC from DCF77.

> AFAIK, there's no current OS that doesn't support UTC.

I would argue that no OS really supports UTC. They support
something like UNIX time, which is not the same as UTC since it
can't represent the leap second.

If the OS has TAI support, you can calculate UTC from it if you have
leap second information. But the OS or libraries don't support UTC,
it's currently up to the application to make UTC from TAI.


Kurt