Re: [Cbor] Encoding Arbitrary Time Ratios

Thiago Macieira <> Mon, 05 April 2021 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA83F3A1F2D for <>; Mon, 5 Apr 2021 08:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ei3JKZgF-SLr for <>; Mon, 5 Apr 2021 08:57:50 -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 AE9293A1E06 for <>; Mon, 5 Apr 2021 08:57:34 -0700 (PDT)
IronPort-SDR: gKGnFw8ENNcYfCaOMx2RkzzlE6s3vq/8TKatoa9YaYPuW0cmAi6sfOKdw/8snjNmODbBfgDyF8 5t6AWpqtuUwQ==
X-IronPort-AV: E=McAfee;i="6000,8403,9945"; a="172338050"
X-IronPort-AV: E=Sophos;i="5.81,307,1610438400"; d="scan'208";a="172338050"
Received: from ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2021 08:57:33 -0700
IronPort-SDR: UV50OnJIA9kTzukk3DHdH79l3c8mxMVjQLYusMPbbevox0337koDvo5KXlidNPKdAuITZT8sii J+ZgjrWHUOPA==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.81,307,1610438400"; d="scan'208";a="440545262"
Received: from ([]) by with ESMTP; 05 Apr 2021 08:57:32 -0700
Received: from tjmaciei-mobl1.localnet ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 5 Apr 2021 16:57:31 +0100
From: Thiago Macieira <>
Date: Mon, 05 Apr 2021 08:57:28 -0700
Message-ID: <2403465.MzrCfxQRY8@tjmaciei-mobl1>
Organization: Intel Corporation
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Originating-IP: []
X-ClientProxiedBy: ( To (
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: Mon, 05 Apr 2021 15:58:02 -0000

On Saturday, 3 April 2021 20:00:03 PDT Laurence Lundblade wrote:
> What you propose seems useful in use cases of one C++ talking to another
> when the protocol is not intended for broad use.
> LL

Not really,. it's not. It's only useful if both sides already know what the 
other will send, otherwise you can't find a std::chrono::time_point 
specialisation to match the type. Note that the std::ratio specialisations 
that time_point are constructed on are compile-time constants. You can't match 
them unless you know before hand you may need to.

For example, ii I sent a time point specifying a ratio of 14609700 : 864, I 
REALLY do not expect the receiver to find a matching type (that's an average 
century with 36524 and one quarter days). Another "useful" ratio is 1296 : 
1000, the microfortnight.

So, no, let's be very clear that code meant to be interoperable should never 
use one of those. If we think it's useful to allow protocols to specify their 
own time points, sure, make it possible to encode them in a specific tag. I 
don't think it is.

I would say only decimal powers of the second with values 0, -3, -6 and -9 are 
meant to be used in interoperable protocols and therefore we should optimise 
for size for those and only those.

Thiago Macieira - thiago.macieira (AT)
  Software Architect - Intel DPG Cloud Engineering