Re: [Cbor] CBOR tag for RFC 3339 full-date values

[Carsten Bormann <[e-mail]>]

On 2020-03-11, at 21:31, Richter, Jörg <[e-mail]> wrote:
> 
> (Replying to more than one message here)
> 
> Carsten Bormann: 
>> Is that a good way forward?
> 
> I am fine with the suggested procedure. 

Great!

> 
>> What I like about Mike’s draft is that he references RFC 3339, which already is 
>> an established specification for how to write dates textually
> 
> ISO 8601 also defines this format for dates. It is mentioned in the "Detailed Semantics" 
> section of my proposal.

ISO 8601 is very “flexible”.  RFC 3339 uses ISO 8601, but helps by restricting this to commonly used cases.
So I think referencing RFC 3339 is strictly better than just naked ISO 8601.

> Mike Jones:
>> I'm fine merging Jörg's numeric date tag into my draft, provided that the result is 
>> not a polymorphic tag, in which the value could be either a number or a string.  
>> We should allocate separate tags for string date and numeric date, just as tags 
>> 0 and 1 are different, and not polymorphic.
> 
> I've got the impression that using a polymorphic tag would be no major problem.
> We can even specify that decoders might only support one representation of the tag.
> I think it would have the same effect if a decoder supports only one of the two tags.
> But either way I would have no objections to using two tags.

I’m not sure I like the term “polymorphic” here too much — in any case, the “value” would be a date.  The content could be both text and number.  Tag 1 already does this (integer vs. floating-point), so we already have to deal with these (i.e., allow applications to not just say “Tag 1”, but “Tag 1 with integer content”).  But we did separate Tag 0 and Tag 1, mostly because the semantics of the value are subtly different.  Are they here?

> Laurence Lundblade:
>> I’d suggest the numeric date be restricted to integers. No floats, bignums,
>> decimal fractions… 
> 
> Yes, that was the plan. Only major types 0 and 1. 

Finer granularity between dates would be times, which we already have, so this naturally should be integers.

>> Fractions of days can be represented by tag 0 or tag 1 using
>> hours, minutes, seconds. 64-bit integer counts of days are large enough.
> 
> This I don't understand. The proposal only handles whole days as one number.

Right.  Only full days.  (The related observation is that these are always in the local time of some context that is not expressed, which is rather different from our time tags.)

> Another thing to consider:
> We should mention that this tag(s) use the proleptic Gregorian calendar. So that 
> dates before the Gregorian calendar have a unique semantics.

Good point.  In 7049bis, we just say:

Negative values (major type 1 and negative floating-point numbers) are
interpreted as determined by the application requirements as there is
no universal standard for UTC count-of-seconds time before
1970-01-01T00:00Z (this is particularly true for points in time that
precede discontinuities in national calendars).  […]

That is less of a problem on the date-only side (as long as dates change on local midnight… and not noon), so we may be able to be more specific.

Grüße, Carsten