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

[Henk Birkholz <[e-mail]>]

Hi Jürgen,

comments in-line.

On 01.07.20 11:05, Juergen Schoenwaelder wrote:
> On Wed, Jul 01, 2020 at 10:18:29AM +0200, Carsten Bormann wrote:
>> Hi Juergen,
>>
>> thank you for that comment.
>>
>> There are two different concepts of “date", and I think the current draft needs to be more explicit that it is about one and not the other.
>>
>>> On 2020-07-01, at 09:21, Juergen Schoenwaelder <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> I just saw your CBOR date type and it seems it does not include a
>>> timezone offset. This means a date value does not represent a 24 hour
>>> time interval but something larger.
>>
>> Well, it represents the abstract date, as opposed to a time period starting at 00:00 on that date and ending at 24:00, both in some time zone (which in practice may be 23, 24, 24.00028, or 25 hours).
>>
>> Angela Merkel’s birthday was 1954-07-17.  You will find that on her passport.  The passport will be mute about the time zone in which she was born, as that is irrelevant to the identification principle.  (Other example: I was born at 00:05 UTC, but that doesn’t mean I have a different birthday in New York, where that specific instant would have been 20:05 the previous day, I think.)
> 
> I am not sure about Angela's passport but my passport in addition
> states where I was born (which implies a certain time zone). I do not
> know whether this example is useful or not, perhaps you just want to
> say that in some use cases the time zone does not matter and this is
> fine.

That is an excellent example. Personally, I think that a geo-location is 
a way more stable reference to a time zone at a given point in time than 
a time zone offset associated with that geo-location (as these change 
surprisingly often over time). Having said that, associating a calendar 
day with a time zone of course supports the association of calendar day 
with my local timescale. Please see below.

> 
> But on the other hand, two systems may tag an event with 1954-07-17
> but in UTC they would be not the same dates or two systems can tag an
> event with two different dates but they are actually the same date in
> UTC. In distributed systems operating across many timezones, simple
> comparisons of date values can be surprising.

"in UTC" is the association of a calendar day with a timescale. If you 
do that, time-zones become relevant. If I add a calendar event to my 
schedule, I want to associate it with a local timescale / TZ, otherwise 
I will probably miss the event. That is why calendar days are often 
bundled with a time zone in an event description. It supports the 
association with a given timescale.

>   
>>> XML schema's date type allows the
>>> optional inclusion of a timezone offset.
>>
>> Which is useful when you want to convert a date into that ~24-hour time period.
> 
> Or you want to compare dates, see above.
> 
>>> The date definition in
>>> draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) includes
>>> a mandatory timezone offset (since it was already mandatory for
>>> date-and-time). I do not know whether we should have a common approach
>>> for this.
>>
>> I think there is a use case for these periods (see also draft-bormann-cbor-time-tag for a little more about periods, even though we haven’t started to flesh out that part of the spec).  It is not the one addressed by these tags.
>>
>>> Note that your 'number of days since the epoch 1970-01-01 does not
>>> really say 1970-01-01T00:00:00 and also leaves it open whether this is
>>> calculated in UTC or not (on Unix-like systems, time is usually
>>> counted in UTC).
>>
>> It doesn’t have to, as it talks about the date, not the anchoring in a time scale of the start and end of the period covering that date in a specific time zone.
> 
>> Joerg’s original proposal has a separate tag for time zone, which (with the time zone data base and, depending on the time scale, information about leap seconds) may be used to do the conversion.  This is not included in the current draft, because the use case is for abstract dates, but it certainly will be addressed by some future tags.
>>
> 
> If the ambiguity caused by timezones is what this WG wants, fine. But
> then I think the WG should add a warning that naive comparisons of
> date values can be surprising.
> 
> Let me check POSIX.1 that is cited for the epoch. Section 4.16 says:
> 
>    If the year is >=1970 and the value is non-negative, the value is
>    related to a Coordinated Universal Time name according to the
>    C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and
>    tm_year are all integer types:
> 
>    tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
>      (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
>      ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
> 
> I read this as POSIX.1 says the calculation has to be done in UTC.
> 
> This means you can have date = 1970-01-02 with days since 1970-01-01 = 0, no?

All definitions in IEEE 1003.1 are about timescales and not calendar 
days (as indicated by the use of the UTC timescale).


Viele Grüße,

Henk

> 
> /js
>