Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets

From: Mike Jones <[email-masked]>
Date: Wed, 8 Jul 2020 17:26:03 +0000

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 <[email-masked]> 
Sent: Tuesday, July 7, 2020 10:20 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets

> On 2020-07-08, at 06:46, Jim Schaad <[email-masked]> 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 <[email-masked]> On Behalf Of Carsten Bormann
>> Sent: Friday, July 3, 2020 5:11 AM
>> To: Juergen Schoenwaelder <[email-masked]>
>> Cc: [email-masked]; Michael Richardson 
>> <[email-masked]>; [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2020 17:27:14 -0400

Mike Jones <Michael.Jones=[email-masked]> wrote:
    > 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 suggest you include text like:

   Note that since both tags are for dates without times, time zones and
   leap seconds are not applicable to these values.  These tags are both
   for representations of calendar dates.
+  These formats are capable of representing dates in the distant past as
+  well as in the future.  There have been a variety of calendars in use
+  prior to modern times, and this specification may not be suitable for uses
+  where human centric calendar concepts like the day of the week are important.

I suggest that you start:

   When
   using a calendar date for decision making, for example access
   control, it needs to be noted that since calendar dates do not
   represent a specific point in time, the results of the evaluation can
   differ depending upon where the decision is made.  For instance, a
   person may have reached their 21st birthday in Japan while
   simultaneously being a day short of their 21st birthday in Hawaii.

as a new paragraph.

* Would an RFC3339 example be worth while?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jim Schaad <[email-masked]>
Date: Wed, 8 Jul 2020 21:04:02 -0700

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

> From: Mike Jones <[email-masked]>
> Sent: Wednesday, July 8, 2020 10:26 AM
> To: Carsten Bormann <[email-masked]>; Jim Schaad <[email-masked]>
> 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
> 
> 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.
> 
> 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).
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Jul 2020 09:37:35 +0200

> On 2020-07-09, at 06:04, Jim Schaad <[email-masked]> wrote:
> 
> I agree that I don't want to deal with differences in calendars.  

Tag 100 is calendar agnostic, as long as the calendar has an equivalent to what is 1970-01-01 in the Gregorian calendar, and can count earth days back/forward from that.

Tag 1004 has the Gregorian calendar baked in, with leap years etc.  That also means that 1582-10-04 (100(-141428)) is immediately followed by 1582-10-15 (100(-141427)), and even more caution is needed before this date (proleptic Gregorian calendar).  But we don’t have to explain all that, just point out that there is some complexity with the proleptic Gregorian calendar.

Tag 100 dates inherit some of that complexity if combined with/converted to/from Gregorian dates, more so if the conversion actually is to/from a date-time anchored to a time zone (civil time).  That is also pretty much all we need to say about that.

> 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).

I’d go with the French revolutionary calendar — ten-day weeks (properly split into five workdays and five-day weekends, of course) would be so much more natural.  But I digress…

Grüße, Carsten