Re: [Cbor] Encoding Arbitrary Time Ratios

[Emile Cormier <[e-mail]>]

On Mon, Apr 5, 2021 at 7:28 PM Thiago Macieira <[e-mail]>
wrote:


> I can accept indicating the number of days. I don't find that a
> particularly
> useful encoding, since it does little to save space, but does add
> complexity.
> I don't find saving 2 bytes because we can encode the whole number of days
> until June 2149 a compelling value.
>

My main motivation is not to save space. It's to save the computational
cost of an intermediate ISO8601 date string when both ends simply want to
exchange a std::chrono::sys_date (while preserving the date semantic). It's
the same motivation (presumably) as for tag 1. Not only is the Y/M/D to
days computation complex, you also have to check for invalid dates (e.g.
January 32nd, February 29 on a non-leap-year, etc).


> Please don't require rational numbers or BigFloat to represent time. The
> only
> valid encodings should be integers and floating point, and maybe not even
> the
> latter.
>

I can support that (no rational nor BigFloat), as long as there's a
mechanism to exchange dates as the number days since epoch without losing
the 'date' semantic.

I'm afraid the ship has already sailed regarding floating point
representation of time in the existing CBOR time tags. Javascript
'natively' handles time as floating point milliseconds. In Python, it's
floating point seconds.

We _could_ constrain a new, proposed "numeric date" tag to have an
integer-only data item, but it would not be consistent with the other
existing time tags which support both integer and floating point.
Javascript folks might complain about the lack of floating point.


> Semantically indicating a date without time would be far more valuable,
> regardless of how it gets encoded. Simply expressing a time point that
> happens
> to be midnight UTC on a particular date is not that. So I support this
> idea.
>

I'm also not fond of expressing dates as time-date values that coincide
with midnight.

I'm glad to hear about support for a numeric date tag in the same spirit as
tag 1. I'm happy to drop my "scaled ratio" idea if I can at least
efficiently transfer a std::chrono::sys_date without performing Gregorian
calendar conversions. All other likely use cases for
std::chrono::time_point (in seconds, ms, us, or ns) can be handled by the
existing tags.

Similarly, it would be useful to have just a time within a day.
>

That could be expressed with the CBOR duration tag (1002) as the duration
since midnight. Of course, the application would have to know to interpret
this duration as the time of day. std::chrono::duration is the recommended
way to store the time of day efficiently in C++. The new
std::chrono::hh_mm_ss in C++20 is intended more for display purposes.

Perhaps a key could be added in tag 1002 to indicate that the duration
represents a time of day?

Cheers,
Emile Cormier