Re: [Cbor] I-D Action: draft-ietf-cbor-time-tag-04.txt

[Emile Cormier <[e-mail]>]

On Wed, Jan 18, 2023 at 6:02 PM Carsten Bormann <[e-mail]> wrote:

> This is what key 4 (base 10) and key 5 (base 2) already do.
> Putting in a tag 1002 duration into the uncertainty/guarantee values gives
> us access to these formulations.
>

Yes, I agree it's better not to reinvent another definition of "Duration"
for the Uncertainty and Guarantee attributes.

My only remaining concern at this point is whether there should be a clause
that says decoders may discard nested clock quality attributes within the
Uncertainty and Guarantee attributes. My decoder will discard them
regardless of what the RFC says, but I guess that doesn't matter to anyone
much while it remains closed-source.

What about the ability to encode a local time having an unspecified time
zone? The C++ std::chrono::local_time duration is computed from the date
time of day the same way as std::chrono::sys_time (POSIX), except that the
time zone is unspecified instead of UTC. All that would be needed is a
"Local" time scale to be added to the time scale registry. I already
understand that you want to launch the time tag RFC with only the UTC and
TAI time scales for now.