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

[Michael Richardson <[e-mail]>]

Mike Jones <Michael.Jones=[e-mail]> 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [