Re: [Cbor] Encoding Arbitrary Time Ratios

[Emile Cormier <[e-mail]>]

On Sat, Apr 3, 2021 at 10:00 AM Carsten Bormann <[e-mail]> wrote:

> On 2021-04-03, at 03:39, Emile Cormier <[e-mail]> 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