Re: [Cbor] Encoding Arbitrary Time Ratios

[Thiago Macieira <[e-mail]>]

On Monday, 5 April 2021 15:09:37 PDT Emile Cormier wrote:
> Now, now, no need to get snarky. ;-)  I concede that ratios other than
> 86400:1 (days) or 1:10^3N are contrived examples and probably have no
> practical use over an interoperable protocol.
> 
[cut]
> I think dates expressed as a number of days since the epoch would also be
> useful. Tag 0 (date/time string) has a numeric counterpart under tag 1. I
> think tag 1004 (date string) should also have a numeric counterpart under
> one form or another.

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.

> If tag 30 (rational number) were allowed to express time in seconds, it
> could be used to represent integral days with a range of +/-2^61 / 86400 =
> +/-26687997791825 days, which corresponds to +/-73069256156.73 years.
> That's 5.3 times the age of the universe.

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.

> Of course, seconds since epoch (tag 1) could also be used to exchange a date
> as days*86400, but the semantics of the value (a date) would be lost.
>
> How about just a new tag for a date expressed as the number of days since
> the epoch? 

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.

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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering