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

Magnus Danielson <> Thu, 10 December 2020 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D9493A11E4 for <>; Thu, 10 Dec 2020 11:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yUvg28K_qQGQ for <>; Thu, 10 Dec 2020 11:07:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A3553A11DB for <>; Thu, 10 Dec 2020 11:07:56 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DFB93F6C4 for <>; Thu, 10 Dec 2020 20:07:30 +0100 (CET)
Authentication-Results:; dkim=pass (2048-bit key; unprotected) header.b=XDK8TwwJ; dkim-atps=neutral
X-Virus-Scanned: Debian amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VMS8VFIHDo-g for <>; Thu, 10 Dec 2020 20:07:29 +0100 (CET)
Received: by (Postfix) with ESMTPA id 136DE3F672 for <>; Thu, 10 Dec 2020 20:07:28 +0100 (CET)
Received: from machine.local (unknown []) by magda-gw (Postfix) with ESMTPSA id B75B29A004E; Thu, 10 Dec 2020 20:07:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=rubidium; t=1607627272; bh=/YavO4ltpAQpbwQyykUovNGEmN0nEuu1yhn8U7SdL30=; h=Cc:Subject:To:References:From:Date:In-Reply-To:From; b=XDK8TwwJhgQs7VLw+pg0SrgxwqXZF08H4f+A8KIKRlOIkZ9bVZUWVPP06dhGwH9SB b0p0hXNJMc7P1lV3U2Ebr+Owu8tX3H2rX027vr6rRl9coe4IDN0Bit7EEIrWjpx8wX t23C+/nxfI4P543h7L4R/eh/bnnParUoWyTCPZMecM7jbb8w5d2bQa9xjooGzyQLCN DnTAVda7nDrdEAZc5wOBKqxIqYoX2T9AdseBUrYKitj8HVet2l+L4/dplwrMTKYYXY QkOpcUVfNRyLEygE2dkEqXVnPtbRL+PhXv0PpUWFZJfB0GKur6KoK9zqb+kKyhtMZ/ stE+BOtTd5z7A==
References: <> <20201209113003.GA2352378@localhost> <> <20201209134612.GC2352378@localhost> <>
From: Magnus Danielson <>
Message-ID: <>
Date: Thu, 10 Dec 2020 20:07:50 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ntp] Antw: [EXT] Re: Timescales
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Dec 2020 19:08:04 -0000


On 2020-12-10 07:59, Ulrich Windl wrote:
>>>> Miroslav Lichvar <> schrieb am 09.12.2020 um 14:46 in
> Nachricht <20201209134612.GC2352378@localhost>:
>> On Wed, Dec 09, 2020 at 02:29:32PM +0100, Ulrich Windl wrote:
>>> However you could see the leap indication flag also as "leap confirmation"
>>> flag (actually there will be a leap event). With only DCF‑77 clocks this 
>> could
>>> be a problem. As said earlier, it would be best if NTP could reliably 
>> transfer
>>> the leapsecond table, or at least the relevant part of it to make clients 
>> know
>>> in advance that and when a leap event is scheduled.
>> There is the tzdist (RFC7808) protocol designed for that.
>> NTP could distribute a leap‑second table (it already did it with
>> Autokey, right?), but isn't NTP about distributing current time,
>> rather than reconstructing time in the past or future?
> Hi!
> You all seem to have missed my point: In the recent past there was a lot of
> discussion and confusion what the LI (Leap Indicator) means:
> Leap second today, leap second at the end of the month, leap second soon. So
> having the definite time of the next leap event would all make this easier.
> Actually it could make the LI even obsolete.

No, not really. I did see that, but there is a subtle point to it.

You have two scenarios:

1) You know the current TAI-UTC offset, and there is no know upcoming

2) You know the current TAI-UTC offset, and you know there is a upcoming
new offset introduced at Time T to become offset O.

As you provide the T and O values, you need to know if those fields is
valid or not, for that you typically use a separate flag to indicate
that, rather than put restrictions on how to interpret those values to
mean that. So, I think it is provides a much better function to have
such a flag.

Separate from that, people have suggested that a flag should indicate a
particular occurrences time. Unfortunately, that has proven the source
of nasty bugs, and also, it can put implications of for how long before
it can be announced, and you end up knowing that you know there is an
upcoming leap second, but the distribution mechanism does not allow you
to announce it yet because it would be interpreted for the wrong time.
Whenever possible, it is therefore advisable to always supply the
time-stamp at which time the future event will occur, as it then leaves
no room for misinterpretation. In the similar sense, it is advisable to
not use interpretation of the fields to know if they provide a future
event or not, but only indicate the facts about the future event which
occurrence is flagged with a dedicated bit.

Being able to compress things does not make it wise, in fact it has
turned out to be very unwise to do so, as it is not future-proof at all.

So, this is why I advocate for a flag to indicate upcoming leap-second,
a field to indicate the current TAI-UTC difference, upon the flag being
set the values of future time-stamp and new TAI-UTC offset becomes valid