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

Magnus Danielson <> Fri, 11 December 2020 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E21643A0CEA for <>; Fri, 11 Dec 2020 08:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, 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 pZ4p0MrfxCe7 for <>; Fri, 11 Dec 2020 08:04:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CEEB3A0CE9 for <>; Fri, 11 Dec 2020 08:03:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADF3E3F439; Fri, 11 Dec 2020 17:03:56 +0100 (CET)
Authentication-Results:; dkim=pass (2048-bit key; unprotected) header.b=cDNs239q; dkim-atps=neutral
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rlNAx13BAmZL; Fri, 11 Dec 2020 17:03:55 +0100 (CET)
Received: by (Postfix) with ESMTPA id 202713F348; Fri, 11 Dec 2020 17:03:54 +0100 (CET)
Received: from machine.local (unknown []) by magda-gw (Postfix) with ESMTPSA id 309A29A0018; Fri, 11 Dec 2020 17:03:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=rubidium; t=1607702634; bh=WqRK+yY4EqWHpVqjXx1Se7Gca5uZv0f5Zkc4b6Z3fec=; h=Cc:Subject:To:References:From:Date:In-Reply-To:From; b=cDNs239qm8ERV4iHQowE5XXrU3iT5311/22NJC5rMIbgJI64QMPZU0a20vRXn+Tgs sdJwq03SGOgqR5EavRv8naTpE43e1wzqw1SuvGhKj9I9TWFy8Ryg6bI6m30+VG5EDj dgnmG6E280viHkKVjgrWl+F1TA/wZKvFfjdbWmEy9R+BRAia5+QgShnR9Uvtn2ee7a Jt9siAN9T+ouE6yH0bxG2B4WX4OO5ptiWJ5JyFRizvplhLxlwoFGsp247Erv5LjmSs COXDwIb8riXyNPCm8ZTv5GRPO/r4hUphCLGB9/uSCITmj3HkoJQ3FDFUvIia0AlKqA MG0KFglzV+r9w==
To: Ulrich Windl <>, "" <>
References: <> <20201209113003.GA2352378@localhost> <> <20201209134612.GC2352378@localhost> <> <> <>
From: Magnus Danielson <>
Message-ID: <>
Date: Fri, 11 Dec 2020 17:03:51 +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: Re: 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: Fri, 11 Dec 2020 16:04:05 -0000


On 2020-12-11 08:38, Ulrich Windl wrote:
>>>> Magnus Danielson <> schrieb am 10.12.2020 um 20:07 in
> Nachricht <>:
>> Ulrich,
>> 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
>> offset.
>> 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
> Actually no: if the T is in the past it's equivalent to "no leap event
> scheduled" (and vice versa).
>> 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.
Do read the complete sentence. There is many ways to have values "flag"
things. Each such ends up being problematic in the long run.
>> 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
>> fields.
> The only disadvantage I see is that T seeds some extra bytes.

Which is a relatively light weight price to pay for a robust mechanism
these days.

You can check the size of the fields for GPS in IS-GPS-200L. That is
carried over a 50 baud data-channel, and while only allowed to transmit
every 12,5 min, it have provided a robust mechanism since it's introduction.