Re: [Cbor] Proposal for Date, Time and Time Zones

Carsten Bormann <cabo@tzi.org> Thu, 14 February 2019 10:14 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 F0A5F131029 for <cbor@ietfa.amsl.com>; Thu, 14 Feb 2019 02:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 avWYLzGZcdME for <cbor@ietfa.amsl.com>; Thu, 14 Feb 2019 02:14:03 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E2C12870E for <cbor@ietf.org>; Thu, 14 Feb 2019 02:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x1EADsLN008372; Thu, 14 Feb 2019 11:13:59 +0100 (CET)
Received: from [134.102.116.214] (unknown [134.102.116.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 440XKt2rzFz1Br6; Thu, 14 Feb 2019 11:13:54 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <bd4d7f87e98b40d585eb7b4502d4b234@pdv-FS.de>
Date: Thu, 14 Feb 2019 11:13:52 +0100
Cc: "cbor@ietf.org" <cbor@ietf.org>
X-Mao-Original-Outgoing-Id: 571832029.799787-9a1553d05d81fd275f04885e53486576
Content-Transfer-Encoding: quoted-printable
Message-Id: <5105F5B3-258E-44B4-B756-2444BB336845@tzi.org>
References: <bd4d7f87e98b40d585eb7b4502d4b234@pdv-FS.de>
To: "\"Richter, Jörg\"" <Joerg.Richter@pdv-FS.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/zadzuxWUzmcVu29fkmGjugU8Z5o>
Subject: Re: [Cbor] Proposal for Date, Time and Time Zones
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: Thu, 14 Feb 2019 10:14:06 -0000

On Feb 14, 2019, at 09:31, Richter, Jörg <Joerg.Richter@pdv-FS.de> wrote:
> 
> Here is a proposal to assign tags to date, time of day and time zone designator:
> https://j-richter.github.io/CBOR/date.html

I think it is interesting to compare this approach with that of tag 1001.

Tag 1001 tries to combine necessary information (to identify a point in time) into a single data structure.

Your proposal differs in two ways:
(1) the date/time-of-day/timezone information is unbundled into separate tags.
(2) the relation to time zones is implicit (contextual).

Specifically:
— the “date” seems to stand for the entire 24-hour interval of the given day in some timezone taken from the context
— the “time” (really time of day) stands for any point in time that corresponds to that time of day (again in a time zone taken from the context)
— the “time zone” stands alone, i.e., is useful without such contextual information.

All of these would make good fields in a 1001-style map (which would provide the context), except that “date” really is an interval (which ) and “time” (time of day) really is a recurring event.

> For the tags I have chosen values between 24 and 255. For date and time I could imagine
> to use smaller tags, because the encoded payload is very short.
>  
> Do you have better suggestions for the tags?

I think the tags proposed are fine.  I’m interested in where the two different approaches would be used (and how to get the interval/periodic event function into tag 1001-1003).

Grüße, Carsten