IETF Logo Mail Archive

Re: [Ntp] Antw: [EXT] Re: Timescales

Hal Murray <hmurray@megapathdsl.net> Wed, 09 December 2020 23:13 UTC

Return-Path: <hmurray@megapathdsl.net>
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 52F3D3A0045 for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 15:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GKgW90Za_fGr for <ntp@ietfa.amsl.com>; Wed, 9 Dec 2020 15:12:59 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id A82203A003E for <ntp@ietf.org>; Wed, 9 Dec 2020 15:12:58 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id B88F140605C; Wed, 9 Dec 2020 15:12:53 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Magnus Danielson <magnus@rubidium.se>
cc: ntp@ietf.org, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Magnus Danielson <magnus@rubidium.se> of "Wed, 09 Dec 2020 23:11:27 +0100." <af1b8734-3b75-0b79-5384-0f98190d527d@rubidium.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 09 Dec 2020 15:12:53 -0800
Message-Id: <20201209231253.B88F140605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jaiCeQqIT5ofuzsbS96a5bXWPIM>
Subject: Re: [Ntp] Antw: [EXT] Re: 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: Wed, 09 Dec 2020 23:13:00 -0000

magnus@rubidium.se said:
> There is one particular notion that I want to make sure is captured, in that
> the TAI-UTC leap second difference should be available such that unambigous
> interpretation into TAI, UTC, UNIX/POSIX, LINUX time-scales can be provided
> as the norm. 

That introduces an interesting tangle.  The raw data for when the next leap 
second happens is something like the "end of next December".  If we use that 
approach, it only takes 3 bits to describe when the next leap second will 
happen: 6 states for the next 6 months and 2 more states for none, and 
I-don't-know.  That drags in a calendar package.  (Yes, you need another bit 
somewhere for insert/delete the leap.)

I think the API to most kernels is leap-tonight.  That leaves the day/month 
logic outside the kernel.  I haven't poked around to see how "tonight" gets 
converted into a second.  Probably by dividing by 86400.



-- 
These are my opinions.  I hate spam.

v2.23.0 | Report a Bug | By Email