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

[Carsten Bormann <[e-mail]>]

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

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

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

Grüße, Carsten