Re: [Cbor] Encoding Arbitrary Time Ratios

Laurence Lundblade <lgl@island-resort.com> Sun, 04 April 2021 03:00 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF2E3A1083 for <cbor@ietfa.amsl.com>; Sat, 3 Apr 2021 20:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N1fN0jUdrjm for <cbor@ietfa.amsl.com>; Sat, 3 Apr 2021 20:00:05 -0700 (PDT)
Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1243A1081 for <cbor@ietf.org>; Sat, 3 Apr 2021 20:00:05 -0700 (PDT)
Received: from [192.168.1.49] ([76.167.193.86]) by :SMTPAUTH: with ESMTPSA id SszblmoCAbSa5SszblYWQJ; Sat, 03 Apr 2021 20:00:04 -0700
X-CMAE-Analysis: v=2.4 cv=OIDiYQWB c=1 sm=1 tr=0 ts=60692bb4 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=1MSDjx2PAAAA:20 a=pGLkceISAAAA:8 a=gKmFwSsBAAAA:8 a=48vgC7mUAAAA:8 a=8wvRfdDZSjcQj26y3oYA:9 a=QEXdDO2ut3YA:10 a=xshDYo_HSl4r5RLtWnoA:9 a=T4gXUGBNC9afoNAl:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <45AF20FB-886E-4BB7-9565-FC02E6BD694D@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DD4ED031-EF87-42FF-B6ED-878D8487179F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Sat, 03 Apr 2021 20:00:03 -0700
In-Reply-To: <CAM70yxCaOps1n7pLo_BPR0_ggZ_QbJnY-jsNPw2NYPfP=psihg@mail.gmail.com>
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org
To: Emile Cormier <emile.cormier.jr@gmail.com>
References: <CAM70yxBF2XeewhsXOGv06kTVitz1kNHkYLHGqm3gX0Vyc2c2YA@mail.gmail.com> <A96FD12B-2F8B-495B-83F1-4A0F50DAA12C@tzi.org> <CAM70yxCaOps1n7pLo_BPR0_ggZ_QbJnY-jsNPw2NYPfP=psihg@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfNm6YqNzrw36eB4uGsM7y2PifaTs674q/prkz+VWnxvBCtmTTh3nc3CR2XcQZ98iU9kRK5B6PKlWRpdeUbu2OqvxUt3igf9aXwlSkBSKR2AY35hgZMbb cAOxg9PKfrAsQTN3wTV5lo8hgcB6F3dTnENPe4cTpqbBfkmv7YAOK2vuHl2PLKct+lAeA2mzmy3YWdiyqXLVS5wY6o30jUJIs0HdTJnGU1BcqweLAJXbmeD4 2DvPJQXJXE6WdhhFbmv7bg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/HE2KbzcbhBmm455jFo3SbBlsymE>
Subject: Re: [Cbor] Encoding Arbitrary Time Ratios
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Apr 2021 03:00:10 -0000

Here’s a CBOR time FAQ that I wrote a few years ago: https://github.com/laurencelundblade/QCBOR/blob/master/doc/TimeTag1FAQ.md

If designing a protocol that’s to be implemented by lots of folks in many programming languages, then tag 1 epoch time seems like it covers most of the use cases to me. I think it is even good to exclude float from tag 1 because it doesn’t add much above a 64-bit epoch time value for human activity (see FAQ). 

It would be good for the C++ CBOR encoder/decoder to translate from tag 1 epoch time to/from C++ time points since tag 1 epoch is what you’ll find in most CBOR-based protocols.

What you propose seems useful in use cases of one C++ talking to another when the protocol is not intended for broad use.

LL


> On Apr 3, 2021, at 12:58 PM, Emile Cormier <emile.cormier.jr@gmail.com> wrote:
> 
> 
> 
> On Sat, Apr 3, 2021 at 10:00 AM Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
> On 2021-04-03, at 03:39, Emile Cormier <emile.cormier.jr@gmail.com <mailto:emile.cormier.jr@gmail.com>> 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 out.
>  
> 
> > 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 purposes.
> 
> Many thanks for the feedback!
> 
> Cheers,
> Emile
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org <mailto:CBOR@ietf.org>
> https://www.ietf.org/mailman/listinfo/cbor <https://www.ietf.org/mailman/listinfo/cbor>