Re: [Ntp] Roughtime time resolution and timestamp format

Tal Mizrahi <> Wed, 03 April 2024 05:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0250C14F74A for <>; Tue, 2 Apr 2024 22:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Status: No, score=-7.096 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 aXTJr-DsF3tD for <>; Tue, 2 Apr 2024 22:34:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 0EE8FC14F749 for <>; Tue, 2 Apr 2024 22:34:40 -0700 (PDT)
Received: by with SMTP id ca18e2360f4ac-7cc5e664d52so78068939f.0 for <>; Tue, 02 Apr 2024 22:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1712122480; x=1712727280;; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=q9eE2QmjWJGc1YwecBe+6Mo/6K8i4+R3BevV3hWOcT4=; b=fhSOfU/SQhwwroma77w1oYIajgzEHKWphTNb6qNDxLN3air0pfO1EvP7u9RDNDqoga CJolwf2WIyGcKsIU5ZY3poUzVSJHuvZ4EmNuy06GlzherL+OI1erLKOqsUkQt6iff4zU WnCrtyEdYyXIjmRYrqHwJfZIYqxV0NKVG5PNxqoNFEzJFrHRcvR9mNsualn6AfZACSI5 S2trLXhnjMgoytxzr4+RIQsQ1HLCFqr/UcvHA4ICtx5pmCXbouH+xze7ag2VM8cRYFHx ZL/nmz80ousP48U4bLdPZZswLZgwiTS/MPX6yM9TzyPx1etpuOhPT3H9HlFNbb4wkPZY sfwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1712122480; x=1712727280; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=q9eE2QmjWJGc1YwecBe+6Mo/6K8i4+R3BevV3hWOcT4=; b=VN0rQPRMrXZOYRBc+syv55apCfSssukthfkEwFjgBGFdn05oUxQu6dSp8kW0pkjmQM C+hYoFVB6S3D617aqa2BFNtW/id/cWAIskM9HgQRsg7imUl1wXx+aFYaYP+vrxlpDsij 6Rw+tdByt8tHTy3wOaRbk/Ge75Tn4qu0UXfR1pj1VFZcv8qffC232t/r2T9hD8vj0Gw6 6IWLKuwwQSLXwsbRtaQAE42XeIz/UwiLWTHw60tuxF/Dpg9FL4PSi3RjwnhpuLPyqoN8 bOmNN1ebXWKsCG+m46RJ2OpLOPO2taWD13Uvytty3ZzWRB5Setix8kJC/+nZtCVo0hg3 9FZA==
X-Gm-Message-State: AOJu0YxUueaqS5x6d/UvAzhgQeyrucicjDUdaSIgCFvge56p54woCAfL OcZeYMp5pLM/N9Q5yyddhmA4L9PgOKwiHIFIM5QdBJ1XdkYw0lROS8r2Pm/gbSmNnemlsi/52s7 OL/0crgU3OPbpoP+MH0KYBNh5u3uvEs1jdR8=
X-Google-Smtp-Source: AGHT+IGljG59JVKY64JUQVrwXg5Q5qWdL+PgyVVtEBkfYYzHtB+18ETJ9g/MTCPdj2sxm+sjgWnz7l2Mw4RjNMz5I64=
X-Received: by 2002:a6b:5907:0:b0:7c8:d514:9555 with SMTP id n7-20020a6b5907000000b007c8d5149555mr13868585iob.1.1712122479671; Tue, 02 Apr 2024 22:34:39 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tal Mizrahi <>
Date: Wed, 03 Apr 2024 08:34:27 +0300
Message-ID: <>
To: Marcus Dansarie <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] 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:34:46 -0000


In my opinion it is always best to reuse an existing timestamp format,
preferably one of the NTP timestamp formats or a derivative (for
example a subset of the bits of the NTP format).
Note that the number of bits in the timestamp defines the resolution,
which is not necessarily the accuracy of the protocol.

Anyway it is important to define the timestamp format in a clear way:


On Tue, Apr 2, 2024 at 10:42 PM Marcus Dansarie <> wrote:
> 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
> appropriate.
> 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,
> Marcus
> _______________________________________________
> ntp mailing list