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

> 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