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

[Carsten Bormann <[e-mail]>]

One other nugget of information that might be useful to minimize confusion is that the tag-100 date number for a date referenced to UTC, TAI, TT or similar, is the MJD (Modified Julian Date) number of the day to the same reference minus 40587.

Grüße, Carsten


> On 2020-04-22, at 06:15, Carsten Bormann <[e-mail]> wrote:
> 
> Hi Mike,
> 
> thanks for submitting the draft!
> I’d include the value zero (i.e., 1970-01-01 itself), not just positive or negative values.
> (Throughout the CBOR related work, we have avoided “positive” and usually said “unsigned”, which includes zero.)
> 
> s/applicaitons/applications/
> 
> Grüße, Carsten
> 
> 
>> On 2020-04-22, at 03:27, Mike Jones <Michael.Jones=[e-mail]> wrote:
>> 
>> I've posted https://tools.ietf.org/html/draft-jones-cbor-date-tag-01, which includes the numeric date tag proposed by Jörg.  I'll plan to join the CBOR call tomorrow and would be glad to talk about this draft for a few minutes, if there's room to do so in the agenda.
>> 
>> 				Best wishes,
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: CBOR <[e-mail]> On Behalf Of Richter, Jörg
>> Sent: Monday, March 16, 2020 12:33 PM
>> To: Mike Jones <[e-mail]>
>> Cc: [e-mail]; Carsten Bormann <[e-mail]>; Anthony Nadalin <[e-mail]>
>> Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values
>> 
>>> 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?
>> 
>> Sorry, I missed this one.
>> 
>> You can use [e-mail] (pdv Financial Software GmbH). I got no blog or webpage.
>> 
>> Thanks,
>> 
>> - Jörg
>> 
>> ________________________________________
>> Von: Mike Jones <[e-mail]>
>> Gesendet: Montag, 16. März 2020 19:52:38
>> An: Richter, Jörg
>> Cc: [e-mail]; Carsten Bormann; Anthony Nadalin
>> Betreff: Re: [Cbor] CBOR tag for RFC 3339 full-date values
>> 
>> Jörg - please respond to my request below for co-author information.
>> 
>>                               Thanks,
>>                               -- Mike
>> 
>> -----Original Message-----
>> From: Mike Jones <Michael.Jones=[e-mail]>
>> Sent: Wednesday, March 11, 2020 3:11 PM
>> To: Carsten Bormann <[e-mail]>; "Richter, Jörg" <Joerg.Richter@pdv-FS...de>
>> Cc: [e-mail]; Mike Jones <[e-mail]>; Anthony Nadalin <[e-mail]>
>> 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 <[e-mail]> On Behalf Of Carsten Bormann
>> Sent: Wednesday, March 11, 2020 2:09 PM
>> To: "Richter, Jörg" <[e-mail]>
>> Cc: [e-mail]; Mike Jones <Michael.Jones=[e-mail]>; Anthony Nadalin <[e-mail]>
>> Subject: [EXTERNAL] Re: [Cbor] CBOR tag for RFC 3339 full-date values
>> 
>> 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
>> 
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
>> 
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
>> 
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor