Re: [Cbor] Encoding Arbitrary Time Ratios

Emile Cormier <> Sat, 03 April 2021 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6AF13A1269 for <>; Sat, 3 Apr 2021 12:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 EANAtCIzHMVf for <>; Sat, 3 Apr 2021 12:58:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C67D3A1267 for <>; Sat, 3 Apr 2021 12:58:56 -0700 (PDT)
Received: by with SMTP id t23so957716pjy.3 for <>; Sat, 03 Apr 2021 12:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dwsvfa1ysyCWglVZWpx44T/wwnV0H6jm3LatFmE2XkQ=; b=dunyBqxFW6+esjZv0lWmM4I7bKuHGiO5hbTnrsIC834ytsBqLKFqRyF65fSsK0r3OP DfHfunfWNPhnXYkE/vgsDUX3ROKcJ3CxaKTXl89M6QqHyNJtkSaSNKuJ2EVYVUeD9TqR 6ipQhZCvW1TfZM174Wl3056EqjjYtLseXtosiyzIZJxX6Mk9dVeDNZZhjQupTQQIULI4 B39FsDA+FYEeJqes8VXpXDk0vrdpL/DDLQTkh9+E3iYIyknH6lQfP/oSpDoZi27jiRNb 03DDDmI4gwHZnnDS0G6EoIX8/8bgxCboQSd7WtLtsCi3ZAS65ZE84T8scUJWrPeE2kdu OUoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dwsvfa1ysyCWglVZWpx44T/wwnV0H6jm3LatFmE2XkQ=; b=GpvWV+8HqU3ouVPLN2AxCw+PM1uzRh8HilODJBIXNW+zwwI1PqNE8ef8AxxfuR0NW6 YbmpZIH50KVgNp6c74AjVSD19/+ucp5G3/8BwPIa6qUprgSDCxot2hSA7CV/5bcuK1Kl 6QsualirQva/VmmZ24eb99uLZowvFSZ9E/GGgYVvnsOdU0TbV+FnDAb82Dr4vKJdijCB a8WdLe3dePHNuR9zBHOIJoEZTgRt36W3rU7+61OcGWyx7vHlP12FUEx6EuVORPxfeqgO NzYkIKqPhLt7o2l3SHAGVWUkHOK4WwAsbXo6Vab+Rrx/3+gm/2XJHc6fBaM22bkV2WNG UJjw==
X-Gm-Message-State: AOAM530Aj3BBAVkPfhRVC20Z2PbvxE+JWwxu7t1XNmyoG+eubvvjSOn6 cfMzoDrpQm5rimlldgbEW9BKcTmX481v/56OHgI=
X-Google-Smtp-Source: ABdhPJyEv5mbYq+iSEQ1pzt0G9drglaF9zdtLaTZfxeOgDf9cNB4Vo1v01UpxJM8Iu3rIYU6nrZ1CiIPTQ6DSsBi++g=
X-Received: by 2002:a17:90b:310e:: with SMTP id gc14mr4241283pjb.198.1617479935018; Sat, 03 Apr 2021 12:58:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Emile Cormier <>
Date: Sat, 03 Apr 2021 16:58:44 -0300
Message-ID: <>
To: Carsten Bormann <>
Content-Type: multipart/alternative; boundary="000000000000f54b9305bf16e4ce"
Archived-At: <>
Subject: Re: [Cbor] Encoding Arbitrary Time Ratios
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Apr 2021 19:59:01 -0000

On Sat, Apr 3, 2021 at 10:00 AM Carsten Bormann <> wrote:

> On 2021-04-03, at 03:39, Emile Cormier <> wrote:
> >
> > To allow the encoding any arbitrary time ratios, I propose a new CBOR
> tag wrapping an array of 1 to 3 values:
> >
> > [Count, Numerator, Denominator]
> Right.  We already have tag 30 for rational numbers of form n/d.
> So this would be c*n/d.
> I’d imagine that in many applications, n/d would be a “constant” (i.e.,
> available from the application’s context); prefix packing or simply a
> convention could handle this.
> > where Count is an integral or floating point number, and Numerator and
> Denominator are integers representing the ratio in seconds.The Numerator
> and Denominator would default to 1 if absent.
> Only the trailing elements really can be “absent” (they could be null as
> well, but why not simply encode the 1 then).  Not sure that the denominator
> is likely to be the one that one would leave out.

'null' could be the magic value that represents "ratio according to the
application context".

I've just had another idea... a denominator of zero (or possibly null)
could be a magic value used to indicate that the numerator is a base 10
exponent. This could allow a more compact representation when the ratio is
milliseconds, nanoseconds etc. Eg [123, -9, 0] instead of [123, 1,
1000000000] for expressing 123ns.

I'm also unsure about the denominator being more likely to be left out. I
think applications are more likely to transmit times as fractions of
seconds (e.g. Javascript Date in milliseconds, C++ std::chrono::sys_time in
nanoseconds), therefore it might be the numerator that's more likely left

> > CBOR tags 1001-1003 would be extended to allow this new CBOR tag as the
> value key. This would allow me to encode additional metadata on the
> std::chrono::time_point clock type (POSIX, UTC, TAI, GPS).
> Right, similar to the way we already handle 4 and 5 (and probably should
> add 30).
> Alternatively, there could be separate keys for numerator and denominator,
> so these could be freely left out and/or combined.

I prefer having a dedicated tag for time expressed as C*N/D so that I can
have a more compact representation when the clock is assumed to be POSIX
and the clock accuracy doesn't matter. This new tag could then be handled
in CBOR extended time the same way it handles tag 4 and 5 (as you hinted).

I'm wondering if a new C*N/D tag could be useful in application domains
outside of timekeeping. It could be called something like "scaled ratio".

> I’m not so familiar with the use cases of this except for a scale factor
> of 86400 (i.e., days).
Time points based on the 86400/1 ratio now have their own type alias in
C++: std::chrono::sys_date. They are now the recommended way to store and
compute dates in an efficient manner. Breaking them down into
year/month/day components is only recommended for display or data exchange

Many thanks for the feedback!