Re: [Cbor] Encoding Arbitrary Time Ratios

[Emile Cormier <[e-mail]>]

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

> On Saturday, 3 April 2021 20:00:03 PDT Laurence Lundblade wrote:
> > What you propose seems useful in use cases of one C++ talking to another
> > when the protocol is not intended for broad use.
> >
> > LL
>
> Not really,. it's not. It's only useful if both sides already know what
> the
> other will send, otherwise you can't find a std::chrono::time_point
> specialisation to match the type. Note that the std::ratio specialisations
> that time_point are constructed on are compile-time constants. You can't
> match
> them unless you know before hand you may need to.
>

You are indeed correct that std::ratio is compile-time. But passing along
the ratio via CBOR allows the decoder to compute the values needed to store
it under a different compile-time std::ratio used by the receiving
application (as well as detecting overflow). If the destination ratio
happens to be the same, the decoder can bypass all the intermediate
calculations.


>
> For example, ii I sent a time point specifying a ratio of 14609700 : 864,
> I
> REALLY do not expect the receiver to find a matching type (that's an
> average
> century with 36524 and one quarter days). Another "useful" ratio is 1296 :
> 1000, the microfortnight.
>
>
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.


> So, no, let's be very clear that code meant to be interoperable should
> never
> use one of those. If we think it's useful to allow protocols to specify
> their
> own time points, sure, make it possible to encode them in a specific tag.
> I
> don't think it is.
>
> I would say only decimal powers of the second with values 0, -3, -6 and -9
> are
> meant to be used in interoperable protocols and therefore we should
> optimise
> for size for those and only those.
>
>
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.

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.

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? This would definitely be useful (and efficient) in C++ when both
ends use std::chrono::sys_date. Decoders for other languages could simply
multiply the value by 86400 and handle it the same way as tag 1.