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

FYI, I did a quick implementation of the single tag proposal that Carsten made. The implementation doesn’t try to do conversion from one form to the other. It just returns a string for one for and an integer for the other. I don’t think it needs to do the conversion.  The implementation was done as an addition to QCBOR that already handles tag 0 and 1.

The implementation was very simple and easy. The two tag proposal that Mike made is just as simple and easy.

LL

> On Mar 16, 2020, at 11:52 AM, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:
> 
> Jörg - please respond to my request below for co-author information.
> 
> 				Thanks,
> 				-- Mike
> 
> -----Original Message-----
> From: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org> 
> Sent: Wednesday, March 11, 2020 3:11 PM
> To: Carsten Bormann <cabo@tzi.org>; "Richter, Jörg" <Joerg.Richter@pdv-FS.de>
> Cc: cbor@ietf.org; Mike Jones <Michael.Jones@microsoft.com>; Anthony Nadalin <tonynad@microsoft.com>
> Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values
> 
> The point of having the tag is that the code knows what follows.  If a polymorphic tag were used, in which two unrelated representations of dates are legal, then the code doesn't know what follows.  And it also opens up questions that it would be cleaner to never have to consider - questions such as "If the polymorphic tag is adopted, must Mobile Driver's Licenses accept both representations?"  And "Will interoperability be harmed if some Mobile Driver's Licenses use one representation and some use the other?"  (The answer to that one is probably "Yes, interoperability will be harmed".)
> 
> Carsten, I take your point about both integers and floats being acceptable for tag 1.  But those are closely related (numeric) representations of the same thing.  Whereas a date string versus number of days relative to the Epoch are nearly unrelated representations, with fairly complicated conversion rules between them (involving leap years, leap centuries, leap 400th years, etc.).
> 
> Given that Jörg stated below that he's OK with using different tags, I propose that we move forward with using tag 1004 (requested) for RFC 3339 full-date values and tag char('d') (requested) for integer number of days relative to the Epoch.  If I don't hear objections soon, I'll publish that draft.
> 
> Jörg - I'll also add you as a co-author.  What affiliation and e-mail address for you should I use?  And is there a URL for a blog or Webpage you'd also like me to include for you?
> 
> 				Cheers,
> 				-- Mike
> 
> -----Original Message-----
> From: CBOR <cbor-bounces@ietf.org> On Behalf Of Carsten Bormann
> Sent: Wednesday, March 11, 2020 2:09 PM
> To: "Richter, Jörg" <Joerg.Richter@pdv-FS.de>
> Cc: cbor@ietf.org; Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>; Anthony Nadalin <tonynad@microsoft.com>
> Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values
> 
> On 2020-03-11, at 21:31, Richter, Jörg <Joerg.Richter@pdv-FS.de> 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
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor