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

[Juergen Schoenwaelder <[e-mail]>]

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.

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>