Re: [Cbor] draft-ietf-cbor-date-tag-02

Yes we know who is doing the shepherd review.  She has started doing it I think. 

I agree that I don't want to deal with differences in calendars.  It might have been easier to go with the Jewish calendar but that would not be at all well known.  The conversions on dates should assume that the calendars are the same (and reasonable).

Jim

> -----Original Message-----
> From: Mike Jones <Michael.Jones@microsoft.com>
> Sent: Wednesday, July 8, 2020 10:26 AM
> To: Carsten Bormann <cabo@tzi.org>; Jim Schaad <ietf@augustcellars.com>
> Cc: draft-ietf-cbor-date-tag@ietf.org; cbor@ietf.org
> Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets
> 
> Thanks for your review, Jim, and for your stab at addressing it, Carsten.  I'll do
> some of this, but I don't think we should incorporate information about details
> vagaries of the Gregorian calendar over the centuries.  Such statements
> wouldn't be authoritative or actionable.  I'd rather reference another RFC as
> the authority on time processing than include details here, since time
> processing is out of scope.  I'm thinking that we should reference RFC 3339 as
> the authority on time processing.
> 
> BTW, have the chairs decided who the shepherd will be?  I'm wondering
> whether to wait to add this new text until the shepherd review also comes in.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Carsten Bormann <cabo@tzi.org>
> Sent: Tuesday, July 7, 2020 10:20 PM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: draft-ietf-cbor-date-tag@ietf.org; cbor@ietf.org
> Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets
> 
> 
> > On 2020-07-08, at 06:46, Jim Schaad <ietf@augustcellars.com> wrote:
> >
> > Mike,
> >
> > Based on the messages that I have seen, I would suggest the following
> actions:
> >
> > Create a new section dealing with the following:
> 
> Let me try...
> 
> > a) a definition of what calendar day means
> 
> A calendar day is a day on a (here: the Gregorian) calendar.
> The specific mapping of calendar days on civil time (here: UTC) is established
> by convention outside the scope of the date tags.
> 
> > b) a definition of a term other than Unix Epoch to be used as the basis.  This
> is a point in time rather than a calendar day so having this as the basis point
> seems to be generation frisson.  It would appear that it is better to use 1970-
> 01-01 as a POSIX calendar date epoch.
> 
> 1970-01-01 was chosen as the epoch for counting calendar days for the date
> tags because it is convenient on systems that have Posix date/time libraries
> available.
> 
> > c) Guidance on how to use two points in time to compute a calendar day
> count.
> 
> Well, that goes deep into date/time library APIs.
> But, usually, these APIs allow you to apply a timezone to a point in time and
> retrieve a calendar day and a time-of-day.
> By zeroing out the time-of-day, time deltas can be produced that, divided by
> 86400 and *rounded* to the nearest integer give you a calendar day count.
> 
> Watch out when using historical dates (the Gregorian calendar has a
> discontinuity in 1582, which was integrated into the civil calendars either
> immediately or later, say, 1752, 1753, … or 1923 if you are in Greece); make
> sure these are actually on the (proleptic) Gregorian calendar already.  Also,
> historically, the calendar date changed at sunrise, noon (astronomical
> day/Julian day number), or sunset on some calendars, and the year number on
> March 25th.  Again, not a problem as long as all dates are on the proleptic
> Gregorian calendar and your date/time libraries aren’t broken (which many
> are for historical dates).
> 
> > d) Information on why it is a bad idea or how to compare a calendar date and
> a point in time.
> 
> A calendar date is not anchored on a timescale, only adding timezone
> information does that.
> 
> > e) Guidance on how to compare two calendar dates (this should be easy).
> 
> If you have the day number (tag 100), that is easy.
> If you have the RFC 3339 full-date, go through a date/time library (using UTC as
> a time zone is the simplest approach).
> 
> Amazing.  I would not have thought that talking about calendar dates would
> evoke all this complexity...
> 
> Grüße, Carsten
> 
> >
> > Jim
> >
> >
> >
> >> -----Original Message-----
> >> From: CBOR <cbor-bounces@ietf.org> On Behalf Of Carsten Bormann
> >> Sent: Friday, July 3, 2020 5:11 AM
> >> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> >> Cc: draft-ietf-cbor-date-tag@ietf.org; Michael Richardson
> >> <mcr+ietf@sandelman.ca>; cbor@ietf.org
> >> Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time
> >> zone offsets
> >>
> >> On 2020-07-03, at 12:32, Juergen Schoenwaelder
> >> <j.schoenwaelder@jacobs- university.de> wrote:
> >>>
> >>> PS: There are even events where there is no natural time zone that can
> >>>   be associated with the event, like the first step on the moon.
> >>
> >> (For those who weren’t there when it happened:)
> >>
> >> Indeed, Monday, 1969-07-21T02:56:15Z.
> >>
> >> Most Americans will tell you Sunday 1969-07-20 for the first steps.   The
> exact
> >> time was actually specifically chosen to occur on prime time TV in
> >> the US (and then was slightly delayed, but managed to stay in
> >> window), which spans several time zones, which all have this on 1969-07-20.
> >>
> >> Yes, I agree we should have some text on this (not the moon landing,
> >> but the issues in converting between calendar dates and times
> >> anchored on time scales).
> >>
> >> 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