Re: [Cbor] Multiple ways of expressing the same time via draft-bormann-cbor-time-tag

Emile Cormier <emile.cormier.jr@gmail.com> Fri, 09 April 2021 19:13 UTC

Return-Path: <emile.cormier.jr@gmail.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 E769D3A2B80 for <cbor@ietfa.amsl.com>; Fri, 9 Apr 2021 12:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 a4sJetVArEFS for <cbor@ietfa.amsl.com>; Fri, 9 Apr 2021 12:13:53 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E69A3A2B82 for <cbor@ietf.org>; Fri, 9 Apr 2021 12:13:53 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id q10so4644402pgj.2 for <cbor@ietf.org>; Fri, 09 Apr 2021 12:13:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nx9rGM6jwN7bMRpDJCvQqMEKgRNj82Mcsm4KmVgjCuY=; b=s6PFxqSDzXsndv+OjacKeu/fszinWBLhwlUNDJc2L8GNx4zKNbIYSMNXJIPWuuGppq 8vD1sgN77C4D5KrEoQVpUpQP7GB/G0VRl1uQLe08k5ehnxKAxroSj9X1hcERHLxj68C/ lvKRnNzzoUG3csEH2kDW/SWd2j3PsMfw5bDw4JGT13L8yBzsOCctQ5RQ6g/J6KhWhoqG sS8H1vQIxRYpD5dIX7Nfqp9F81PxbTmgAPQbgDWuEaOwBiYWAESKNoTasBldDIGqEOQZ aD9K5JEbn2uWy4hjs2tIVpMDjiArmQcZZB59TBwGI++5RKiCdiredngq5UJVCXa+/XWN 8TVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nx9rGM6jwN7bMRpDJCvQqMEKgRNj82Mcsm4KmVgjCuY=; b=mf9iY328SMwExJOsv1UqWU1uX8aO6xFy6ymEEQi9m97bkd47vdvshWZkxiGfivHtnn 98u0XnMhcmudbc6EZ+DZBxME+/6flr0QGhRrPh94AU9K8/F5umHDeJd7ZqZhVSp7sgS0 p1BkNU6+AZDk9dXE9FImEzR7h9LwkAGVJkJG6bLzsHZQtUTNGXWUC5YH6rwfkmjqbSUd 3Dwjf/EcBCKo8tfKJRD6bLAaHCUJQje9kf2kKkbfHqgpO8ViwgIYFnVjwYITsAmjwqFs Iq3RYMMYwHcOPaGsVDa4SkzDysf96psH5nedE5RlvujwpQPE88quPYx4V9HBBRlAHAI/ A3Zw==
X-Gm-Message-State: AOAM533VBb8pO6CwD9NexPrYveBNA19xkr4xFLFctf7dF2FiZTODCx/I ODI+5gs95d6ytfOy7vlVhYALO+1cvvcLlIbTYsQ=
X-Google-Smtp-Source: ABdhPJyyLQjJVeQWgIk+6LL5XVYt8keblG9VtOZuMmiCxuVPs6RW0AuAAktlEOfUOhxSyCFHUq1htO97ACVguSg//Lw=
X-Received: by 2002:a63:3ec2:: with SMTP id l185mr14825144pga.45.1617995631187; Fri, 09 Apr 2021 12:13:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAM70yxBEvhN9VqbRpMedPMaSjnRf_GQcUAYcfna0kA5=7gRcdw@mail.gmail.com> <A1053C4F-11DB-474E-B73A-798D6FCE36AD@tzi.org>
In-Reply-To: <A1053C4F-11DB-474E-B73A-798D6FCE36AD@tzi.org>
From: Emile Cormier <emile.cormier.jr@gmail.com>
Date: Fri, 09 Apr 2021 16:13:40 -0300
Message-ID: <CAM70yxBdtZRCwVCXPO7506X_j8PB3fvS6i1bzKrE4EfbtMNq7g@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: cbor@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d85b3205bf8ef64c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/PGibjDXfASBFTHpuIH3E7jnqZH8>
Subject: Re: [Cbor] Multiple ways of expressing the same time via draft-bormann-cbor-time-tag
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: Fri, 09 Apr 2021 19:13:58 -0000

Hi Carsten,

As always, thank you for your invaluable insights. I'll proceed with my C++
implementation assuming that my option #1 is what's preferred for the
sender. I did indeed strike me that the POSIX timespec struct, with its
separate fields for seconds and nanoseconds, seemed to be the inspiration
behind the specification.

The "penalty" for the division/modulo operation, for sending a
std::chrono::time_point via tag 1001, is probably insignificant. I'm sure
it's orders of magnitude faster than converting it to ISO8601 text.

By the way, my "scaled arbitrary ratio" idea from before turned out to be
useful as an internal, intermediate representation between various
application time types (like std::chrono::time_point, time_t, timespec,
etc...) and the various JSON/CBOR-like codecs that my library supports.

Cheers,
Emile Cormier

On Fri, Apr 9, 2021 at 6:18 AM Carsten Bormann <cabo@tzi.org> wrote:

> Hi Emile,
>
> On 2021-04-06, at 22:35, Emile Cormier <emile.cormier.jr@gmail.com> wrote:
> >
> > I'm implementing tags 1001 and 1002 in my C++ library to exchange time
> points and durations (refer to
> https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html)
> >
> > I'm in the situation where I''m not sure which is the "expected" way to
> encode time as nanoseconds since the Unix epoch. I'm specifically referring
> to std::chrono::system_clock::time_point, which is a 64 bit integer. There
> are currently three ways I could encode such a value.
> >
> > 1. The whole number of seconds under Key 1, with the remaining
> nanoseconds under Key -9.
> >
> > 2. The total number of nanoseconds under Key -9, with a value of zero
> under Key 1.
> >
> > 3. The total number of nanoseconds expressed as a Decimal Fraction under
> Key 4.
>
> Oh.  You are pointing out a deficiency of the current text.  The
> *intention* was that Key 1 is an integer and Key -3*n is supplying the
> fractional part.  E.g., like UNIX struct timeval for -6 (old) and struct
> timespec for -9 (new) do.
> So that would be your Option 1.
>
> But since you raise it, we probably should entertain the question.
>
> The issue really is whether the onus is on the sender/encoder or the
> recipient/decoder.
>
> Restricting the value for key -3*n to be less than 10**(3*n) places the
> onus on the sender, who would need to do a modulo if that is not the way
> the data is already represented on the sender’s platform.
> Not adding this restriction places the onus on the recipient, who would
> then need to do the modulo in case the recipient’s platform representation
> is like one of the UNIX ones.
>
> > Option #2 is the easiest and most efficient because it doesn't involve a
> division/subtraction calculation.
>
> … for the sender.
>
> > However, a receiver that discards Key -9 will end up with zero seconds.
> At least with option #1, the receiver will know the number of whole seconds
> if Key -9 is ignored.
>
> Which indeed maybe also is a concern.
>
> > Option #3 requires that the sender and receiver understand Tag 4
> (Decimal Fraction), or at least the concept of decimal fractions within the
> context of tags 1001-1003.
>
> That would seem to be the easier case; “understanding” Tag 4 in this
> context is limited to being able to parse the 4([-6, microseconds])
> arrangement, unless the sender’s code looks for trailing zeros and does
> stunts like 4([-5, tens-of-microseconds]) in these cases, which of course
> cannot be excluded.
>
> > I'm guessing that option #1 is the "canonical" way, but I'm not entirely
> sure. Some guidance would be appreciated. Perhaps a few words concerning
> this should be added to the standard's text?
>
> Definitely, either way.
>
> I think I’m mildly in favor of placing the onus on the sender, i.e.,
> Option 1.
>
> etime = #6.1001({
>   ...
>   1: int,
>   ? (
>     -3: uint .lt 1000 //
>     -6: uint .lt 1000000 //
>     -9: uint .lt 1000000000 //
>     -12: uint .lt 1000000000000 //
>     -15: uint .lt 1000000000000000 //
>     -18: uint .lt 1000000000000000000
>   )
>   ...
> })
>
> > On the receiving side, my library would ideally handle all three
> scenarios. It's on the sending side I'm more concerned about when I need to
> interoperate with CBOR decoders other than mine.
>
> Right, be conservative…liberal…
>
> Thanks for bringing this up!
>
> One always learns a lot from implementation efforts.
>
> Grüße, Carsten
>
>