From nobody Sun Apr 4 01:38:09 2021 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Sun, 4 Apr 2021 10:38:00 +0200 Cc: cbor@ietf.org Message-Id: References: To: Emile Cormier X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 08:38:08 -0000 --Apple-Mail=_A04D340E-49FE-497F-A123-1C10C20337A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 > 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=E2=80=99m 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=E2=80=99m not so familiar with the use cases of this except for a = scale factor of 86400 (i.e., days). >=20 >=20 > 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=C3=BC=C3=9Fe, Carsten --Apple-Mail=_A04D340E-49FE-497F-A123-1C10C20337A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=99m= 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=E2=80=99m 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=C3=BC=C3=9Fe, Carsten

= --Apple-Mail=_A04D340E-49FE-497F-A123-1C10C20337A1--