Re: [Cbor] Encoding Arbitrary Time Ratios

Carsten Bormann <cabo@tzi.org> Sun, 04 April 2021 08:38 UTC

Return-Path: <cabo@tzi.org>
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 D99533A1D37 for <cbor@ietfa.amsl.com>; Sun, 4 Apr 2021 01:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 XT6cy0MIcWmx for <cbor@ietfa.amsl.com>; Sun, 4 Apr 2021 01:38:04 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705EC3A1D36 for <cbor@ietf.org>; Sun, 4 Apr 2021 01:38:04 -0700 (PDT)
Received: from [192.168.217.152] (p548dc178.dip0.t-ipconnect.de [84.141.193.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FCnHF3JLfzyX0; Sun, 4 Apr 2021 10:38:01 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A04D340E-49FE-497F-A123-1C10C20337A1"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAM70yxCaOps1n7pLo_BPR0_ggZ_QbJnY-jsNPw2NYPfP=psihg@mail.gmail.com>
Date: Sun, 04 Apr 2021 10:38:00 +0200
Cc: cbor@ietf.org
Message-Id: <C354E68B-0B1A-4644-AB38-67453F8A52C3@tzi.org>
References: <CAM70yxBF2XeewhsXOGv06kTVitz1kNHkYLHGqm3gX0Vyc2c2YA@mail.gmail.com> <A96FD12B-2F8B-495B-83F1-4A0F50DAA12C@tzi.org> <CAM70yxCaOps1n7pLo_BPR0_ggZ_QbJnY-jsNPw2NYPfP=psihg@mail.gmail.com>
To: Emile Cormier <emile.cormier.jr@gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/WWrOutzcWJXEfaEXBLgvUmNcPsE>
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 08:38:08 -0000

> 
> 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.

We already have decimal fractions (tag 4), so this is covered.
There is also key -9 etc. for tag 1001, if you want to separate the seconds and their fractional parts.
(I’m not a big fan of encoding magic values in the data items themselves, either.)

> 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".

Probably.
Making it amenable to cbor-packed suffix (or circumfix!) compression would make this a quite versatile tool.

> 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.

Right, so seconds (and their decimal fractions) and days are the most important scaling factors.

Grüße, Carsten