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

[Mike Jones <[e-mail]>]

Let's discuss whether to add a non-normative reference to the Modified Julian Date to the draft or not.

				-- Mike

-----Original Message-----
From: Carsten Bormann <[e-mail]> 
Sent: Wednesday, April 22, 2020 7:22 AM
To: Mike Jones <[e-mail]>
Cc: "Richter, Jörg" <[e-mail]>; [e-mail]; Anthony Nadalin <[e-mail]>
Subject: Re: [Cbor] CBOR tag for RFC 3339 full-date values

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