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

Carsten Bormann <cabo@tzi.org> Fri, 03 July 2020 06:29 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE13A0D4F; Thu, 2 Jul 2020 23:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF4qyCCpaz5U; Thu, 2 Jul 2020 23:29:03 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4EC3A0D4E; Thu, 2 Jul 2020 23:29:03 -0700 (PDT)
Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49ylRK4hrKzyV2; Fri, 3 Jul 2020 08:29:01 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de>
Date: Fri, 03 Jul 2020 08:29:01 +0200
Cc: draft-ietf-cbor-date-tag@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 615450541.248722-0851f1cc7216e6ee0bde1b9c3a248705
Content-Transfer-Encoding: quoted-printable
Message-Id: <99A557CE-559D-409A-A3DC-5D20F2F55F5E@tzi.org>
References: <20200701072123.hnyhzemagtotnuyl@anna.jacobs.jacobs-university.de> <DD477DBD-3F3F-48FA-BADC-FF550CC3D4F7@tzi.org> <20200701090536.mqkfjebfzhz5phls@anna.jacobs.jacobs-university.de> <5244.1593618673@localhost> <04FEC6E5-F8E9-472D-A4D6-71C6C00D79E6@tzi.org> <20200703060820.ydmbdmp5fy2v6wgf@anna.jacobs.jacobs-university.de>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/K3BF5daOaG2ygttb3J0rtdNAlT0>
Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 06:29:06 -0000


> On 2020-07-03, at 08:08, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> On Wed, Jul 01, 2020 at 06:23:30PM +0200, Carsten Bormann wrote:
>> On 2020-07-01, at 17:51, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>> 
>>> The failure of the Nipponese to declare war on the USA on December 8, 1941
>>> (they date of the attack on Pearl Habou^Hr in Japan...) is perhaps a better
>>> example of failures to get the time zone right.
>> 
>> … and then there is V-E Day which is on 1945-05-08 everywhere except in some countries usually more or less loosely related to the Soviet Union, where it is on 1945-05-09 (even though the actual capitulation document was signed on 21:20 Central European Summer Time, which I think was 22:20 in Moscow which didn’t follow DST at the time…  
>> No time left to set up parades, so -05-09 it was :-).
>> 
>> I’m citing this as an example where a calendar date was chosen entirely by fiat, not based on the exact time of the actual event as adjusted for a specific place/time zone.  It does make sense to separate calendar dates from day-length periods anchored on a time scale, and this document is about representing calendar dates in CBOR.
>> 
> 
> You often associate an event with a date. If you ignore timezone, then
> 
> (1) two systems may associate the same event with different dates and

Yes, that was the point of my VE-day example.

> (2) comparisons of date values may lead to "wrong" results.
> 
> Since number of days since 1970-01-01 seems to be calculated in UTC
> (the document refers to the POSIX epoch which seems to be in UTC)

Yes, that is not entirely clean.  Since for many people (those west of the Atlantic) the Posix epoch falls on 1969-12-31; we need to be explicit that this is based on the calendar date of 1970-01-01.  (Using the Posix libraries still works out if you translate the calendar date into a Posix time based on UTC, *and* translate back based  on UTC as well.)  There may also be a need for a note that negative numbers are applied using the proleptic Gregorian calendar; Angela Merkel’s birthday is 100(-5844), and Charlemagne was crowned Roman Emperor on 100(-427334).

> (3) a 'date' value and a 'number of days since 1970-01-01' value can
>     be "inconsistent".

Not sure how that can be; a common Gregorian calendar seems to be in use.

> I think this deserves a clear warning. The -03 version has text in the
> security considerations section scoped to access control decisions but
> the fact that comparisons of date values and number of days since
> 1970-01-01 values may be surprising is not limited to access control,
> i.e., I prefer to see this explicitly discussed in section 2.1,
> perhaps including advice what should be done if proper comparison of
> date values is desirable.

I agree.

Grüße, Carsten