Re: [Ntp] [EXT] Roughtime time resolution and timestamp format

"Windl, Ulrich" <> Wed, 03 April 2024 05:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD3A4C14CE39 for <>; Tue, 2 Apr 2024 22:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mypbtBy8BLjr for <>; Tue, 2 Apr 2024 22:59:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B7C9C14F60E for <>; Tue, 2 Apr 2024 22:59:41 -0700 (PDT)
X-CSE-ConnectionGUID: fq2NloexRYuafeeipFs+HQ==
X-CSE-MsgGUID: 4c+4X51TSSCTROc12HeH0w==
X-ThreatScanner-Verdict: Negative
X-IronPort-AV: E=McAfee;i="6600,9927,11032"; a="716525"
X-IronPort-AV: E=Sophos;i="6.07,176,1708383600"; d="scan'208";a="716525"
Received: from unknown (HELO ukr-excmb02.ukr.local) ([]) by dmz-infcsg01.ukr.dmz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2024 07:59:38 +0200
Received: from ukr-excmb03.ukr.local ( by ukr-excmb02.ukr.local ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.37; Wed, 3 Apr 2024 07:59:37 +0200
Received: from ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0]) by ukr-excmb03.ukr.local ([fe80::1cb4:6e0c:6da4:a8a0%4]) with mapi id 15.01.2507.037; Wed, 3 Apr 2024 07:59:37 +0200
From: "Windl, Ulrich" <>
To: Marcus Dansarie <>, "" <>
Thread-Topic: [EXT] [Ntp] Roughtime time resolution and timestamp format
Thread-Index: AQHahTX4oRIxi8e0pk6FYo6rSeWp7rFWDGcw
Date: Wed, 03 Apr 2024 05:59:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Ntp] [EXT] Roughtime time resolution and timestamp format
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2024 05:59:48 -0000


Personally I think that "date" (calendar triple) is a very bad time scale for computers.
Seconds since some starting date seems more natural. Considering the time of invention,
A starting date of 200001-02 should be "early enough", for example.
Given the fact that almost any recent CPU is 64 bit capable, a 64-bit quantity looks like a good choice IMHO.
Whether the split to fractional seconds has to be 32:32 (as for NTP) is another question: Maybe 10 or 20 bits for fractional seconds would be enough. Maybe even 8.

Kind regards,

-----Original Message-----
From: ntp <> On Behalf Of Marcus Dansarie
Sent: Tuesday, April 2, 2024 9:36 PM
Subject: [EXT] [Ntp] Roughtime time resolution and timestamp format

Dear all,

I looked over the latest Roughtime draft this weekend. One of the things 
that struck me was that the protocol's time resolution has changed three 
or four times in the nine drafts so far. I discussed this off-list with 
Watson and he suggested that we check with the list what people think is 

In the current draft, resolution in both time and accuracy is one 
second. This means that the lowest possible interval reported by a 
Roughtime server will be two seconds (i.e. plus/minus one second). The 
midpoint can be off by as much as half a second from the server's best 
time estimate. The resolution in previous drafts has been microseconds.

Related to this is the question of how time should be formatted in the 
protocol. In the current draft, time is transferred as the "count of 
seconds since the Unix epoch in UTC". Previous drafts have used either 
microseconds since the Unix epoch or modified Julian date and 
microseconds since midnight.

Personally, I think that single-second resolution is too low. Indeed, a 
user could look at two devices that have successfully used Roughtime to 
get time and visibly see that they do not match. Also, a second is eons 
in computer time. At the very least, we should specify decisecond 
resolution and preferably millisecond. I am also hesitant towards using 
the Unix epoch, considering the history of problems involving 
conversions to and from it, not to mention leap seconds. The time 
transferred with Roughtime should be clear and unambiguous. For that 
reason, I prefer the date and time-since-midnight format. The date could 
be either days since an epoch or year-month-day.

To summarize, these are the two questions that we would like to hear 
your opinions (and eventually reach consensus) on:

* What resolution of time and time accuracy should Roughtime use?

* What should the Roughtime timestamp format look like?

Kind regards,

ntp mailing list