From nobody Fri Nov 4 02:49:15 2022 Return-Path: X-Original-To: sedate@ietfa.amsl.com Delivered-To: sedate@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7457C152711; Fri, 4 Nov 2022 02:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qt.io Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZpcXlsT6Udl; Fri, 4 Nov 2022 02:49:10 -0700 (PDT) Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2119.outbound.protection.outlook.com [40.107.247.119]) (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 87C37C14CE25; Fri, 4 Nov 2022 02:49:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RBson64GJ0rSu6FUBeDIyq/vloAILQowyDaP31CnEQh2uAczuAMH0aauYKVU7C9d5odwj8aRFiVCyA5okZIKrjZvLcExih26EHyYpvcJlbImxLB55KtJroHZqAz1wMBrnhsjNddKlymmfs2r6MJGYkWgREQScYiXhF2FL+pRx4fCPTE2wCJKIoL4ujicoI7HvAKZTGMe8Z5s8BUEPGzmGGEI3Iax8JUpl8TMXzYZ5M7mBvM4ftA1A+17JUrxLemJ5MLAMoNeJR54xJYmr1Azji+kAivISwvQovr99ksPfbYRxuVXW7hl+DJiuAQP59UWzozzx03cEiXaujCnfC/X9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nrQHdSPGkGHmnHAxI52viP6koy+v/vCrkygsUiNAVYY=; b=Uw36hTgCHC1aZ2K06G9xFJI9swh0NEOqYo9ljW4JKjbRQTdk+KTYLMT0E68xP0xaiu5WObAeyscpbC+MFBz51GEmUHYXWGwf9Vg6PfguQnXAMkt/F0i8OBnD1BJsysOjWoSX6RL9aUtjqKhnRTCf//Lf8O3MmjloBN/GZfLtEwthpzhgfVmIldAdrSrEMBF6naV1MeE5p0locg+25LNLIVSg4TUvUjQWB2l63nsp+GIJZvBbT4EpuVJFunwqd0eemgTpadrzN/zAztRnyhYLQtaQNRLECz74Mi8y7Mj4OpdaFQwywA6AumNbY7c2LwJ7As/q7UAjE8XNv2ytgC8Iyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=qt.io; dmarc=pass action=none header.from=qt.io; dkim=pass header.d=qt.io; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qt.io; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nrQHdSPGkGHmnHAxI52viP6koy+v/vCrkygsUiNAVYY=; b=if2h+dES1/urBpDuT1fgY4KZMSplviejCJKq+MKoy1SOzKD53LURNROonlRKISrZvnTIcZKD03FOmUn1seYxDRlP7ICGZKI58z62O4pfRNUHWN7PEALkJGcOJyA2lFi588Ukr+VGD1bEaMPZ8OK7IJ4oTttoUPE2SL1owJ4xN/Q= Received: from DU0PR02MB8218.eurprd02.prod.outlook.com (2603:10a6:10:312::9) by AM0PR02MB5876.eurprd02.prod.outlook.com (2603:10a6:208:183::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.20; Fri, 4 Nov 2022 09:49:06 +0000 Received: from DU0PR02MB8218.eurprd02.prod.outlook.com ([fe80::590:e1f9:443f:3b5c]) by DU0PR02MB8218.eurprd02.prod.outlook.com ([fe80::590:e1f9:443f:3b5c%9]) with mapi id 15.20.5791.020; Fri, 4 Nov 2022 09:49:06 +0000 From: Edward Welbourne To: John C Klensin , Paul Kyzivat CC: "sedate@ietf.org" , "art@ietf.org" Thread-Topic: [Sedate] [art] [Ntp] [TICTOC] [Cbor] Two specifications on timestamps nearing WGLC Thread-Index: AQHY7/DTTfmmYkUaTk+1Z4isdo67Ja4uekj5 Date: Fri, 4 Nov 2022 09:49:06 +0000 Message-ID: References: <19C0959C-2DFF-4FA6-9691-792CD2AF5E09@tzi.org> <2620A4D0-F624-4E31-BDD1-860B40F7A31D@tzi.org> <193653.1665119732@dooku> <9621884E0BC501528B6BB591@PSB> <8ED6029F05884D21580EA2AF@PSB> <958a7cca-95df-6f81-54d3-d3dd6fd9b617@it.aoyama.ac.jp> <20FC2DF5DF55E51A8202D52D@PSB> <20221020180542798954.c6a9917e@comcast.net> <0661554d-ae98-79da-359e-248ab6cb9647@pdmconsulting.net> <45F13D65EA0B83A5F79A4B40@PSB> In-Reply-To: <45F13D65EA0B83A5F79A4B40@PSB> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=qt.io; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DU0PR02MB8218:EE_|AM0PR02MB5876:EE_ x-ms-office365-filtering-correlation-id: 9a70b081-751e-4e8d-e0a4-08dabe49d085 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H0cfCVZX5Tr8NqLCSdZwaBywrbkTGW5Bihar1Ecczjt38bAYrNhngN46QYedFMuzMNKoeh4lGnLORiozXl6Gvf6qh68kqNNfHxn1hIfnOWWv8azT2MGrqNY3EN7S5YOEKrQmBqI2ka5EcjS2VDJyUBrbIxzkmY2XV7RHKpQQuBuog4Qc5ndGLR1CXm0kvBKNwVfzKUJC035X27SLskjmEk8bH1lrHJzD65MaDBgKniApXRFvjCt/o2t1xf0rcKBqsDXpQ32UBdFvAr/NrbzGhJXT4VvOQwBfptGhQ5XM71b9NvkQpe7K6Ari2/kUcLsCVadbp7kRI8PML2fmshwMn6B4TtgRf8KTU/OLnb2SGdf0THMhlGamd7Fp+FnX2CFh4k8l2F6x+iLhitX25UECwgW7g34w+Yncazr82YYT/jhE7pXYOSag20RwW6O6dl4PXMIjXlNYYlILpHy7TAZ0LRgyFD+d9wtSAgcxIy8yZ/0ShMv58ZEVqOGlXm4X+QJBPoPz1tsY9BwHMoZXkp5gnKCeEKSQVChggKQcZ3CeP2S9DROpqOCl2n6NVRcR4njuXhvCu5IbJv0VMR2XGi5Fu7M8+lktktbU6xfsLlseNEZcIkaXVpR/m12LU9eh9kU+C5ocKquDjRoBRZxVOh3RgD135xWcGn9VzTRxW5ixYB1gBsEqJEpu7hlkRSh5kDXwx5qptQxXKAuHEla77BTMDueg41z7xQleMYV1KNCg7yrFH7fX72CZHzCk98QvZnAgAKSPSAAZw+PZlPHYMZMn6g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0PR02MB8218.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(346002)(366004)(39850400004)(396003)(136003)(376002)(451199015)(66946007)(55016003)(33656002)(76116006)(4326008)(8676002)(66446008)(66556008)(71200400001)(44832011)(110136005)(54906003)(38100700002)(52536014)(5660300002)(8936002)(316002)(122000001)(2906002)(64756008)(91956017)(7696005)(83380400001)(26005)(9686003)(186003)(66476007)(38070700005)(53546011)(6506007)(41300700001)(86362001)(478600001)(66899015); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?7mUzAUOJubI2pINTUFmdSteeOiy+K9NpkHIc8LxPNYim2yLtGye0c0M5bI?= =?iso-8859-1?Q?HUSdeMM0Hxr7FUlYch7z/yvbX969oKtZA71lVaPECYzPgAFR65dhxbSuW8?= =?iso-8859-1?Q?DYkJn8qzcxBAN0XRHkF7nc2JG7zAiIX+PPLM4UO9x6nrl7qPS8weqJI95o?= =?iso-8859-1?Q?VrasCK1oPbMVrU/tE9Z/mSfTcc9KtRID1dVjgYu2nSmOZZ9k5A2zAwo0ts?= =?iso-8859-1?Q?5xfgEfMGlv9x7BFONietREUbkrVyr3QlM9E+JapVztEWg3ENbO0FF6PQbH?= =?iso-8859-1?Q?mMco7jYjQHbh5tmXIUWWqqJ1hiIiZ/4XY8OZNohgzluwHabBFza5AS8F/E?= =?iso-8859-1?Q?1AyvXRQYY7pcHUv3hXWwbfMkTxcskJueDH521MAiYJgrte1d18yBuLeajq?= =?iso-8859-1?Q?4UJp5ZRE7tT/a0kIPiD2OeHEcx9lHhh17n5YNvmuF16cX0lehAeJaR/p8k?= =?iso-8859-1?Q?4jm6IEcoBOdBgKn7tnK7AHJGgNKsEcl0/mrQB/t0DraXPFkieWnjQ3fsil?= =?iso-8859-1?Q?uxu7TWgKFgcZeecr58YDg5ClH/D788bi5v4ufXjN8vHIB16J1w4bqktpqV?= =?iso-8859-1?Q?/5VntSq64U8dY2qCYmshUqXleHI6AEZT27qFYEhW8h1xATwMOguXbgYPrw?= =?iso-8859-1?Q?FvNJfev2hDLJZnu7gwTHpulic/KSD4R8b62fVMe4UAVjetXMGB6MMIcoiU?= =?iso-8859-1?Q?hod6pcyirl8FfHqzG6MtTo8rXNvrtC++BRDX/AYWHsTnJwnT+GhQmmHzeD?= =?iso-8859-1?Q?mI6HHBHbwriAyZ6oYQ541ggRmTS9LP99V6F7EhjAUCtQAnnkg1d1KcE/qX?= =?iso-8859-1?Q?pvFpphm0nmNS82y3eBQY2xMVzdWLvLQbuP/nJVY0+zYPV2bm+Q+ghFlgu6?= =?iso-8859-1?Q?cw+tWgdHHWOmCWt5pp0nn77eZ/VP0WxQYscE/WLCAwbh2nJrM3DmRFAp5k?= =?iso-8859-1?Q?FLSB8iwG0S2qr7E1LGpRfcbmSlUk57dcJ+bjEscGMAsYmgbJFl8Z2V2ua7?= =?iso-8859-1?Q?0sWZMTPCZu38PPlEgibDlPUlPEV6raNQG073On/qPvws1b1KIA2naod/L/?= =?iso-8859-1?Q?/ghynHr4doMIF/ZW6gRXMyCI4X7N6Iyr08oNHgvYvGD0K3orbuSRnYuKJG?= =?iso-8859-1?Q?tPVrFO1Q6ENE3u7aDp3Q+naWsJ9waTj0Mkz04b15pcElcmSgajXWzhKNJP?= =?iso-8859-1?Q?SYy0gAfveKImbrx5VRoeeFLU9lsHwsvb5FfN8KitT0H4XuoLkVqvycYG7W?= =?iso-8859-1?Q?E+/AGvRzcnIE/B7OvKBdvahG9jNkZ6vRFiULC3NVVt3iUd/AhscOfq7UYW?= =?iso-8859-1?Q?hfiB+0ell7w1xBvd5LoeMzMuJBJYgV5MhBhqvr8vGibjhqIy3ICfDSuFZ+?= =?iso-8859-1?Q?/gMj3hZWTzroF75jCu898NEanFwIw5r10pi66lW+g/YdOf1rsjLnszUxNU?= =?iso-8859-1?Q?7UuNdeuSV7ut6YoqjzVQy/1Uu2IuD5pJdqnuzk02jXG2AaGqd9en2IW5cO?= =?iso-8859-1?Q?XdwJ4GbUo4NWDwDhUTyU17kVRRC4xbJ557NMLPmeL3LgFaRLUsw5uLulak?= =?iso-8859-1?Q?O5pYH7xvdfEC6Wv3EKkvT3hgEuVBr/vBa3xMndDh7F0o5m7hcElSxZ4jT/?= =?iso-8859-1?Q?21fvibdpQQjxToIuLh8k9aF/+RKj/RWTH9?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qt.io X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DU0PR02MB8218.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a70b081-751e-4e8d-e0a4-08dabe49d085 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2022 09:49:06.6515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 20d0b167-794d-448a-9d01-aaeccc1124ac X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HfpbJjCP4CnFCS1HWu9V/bVLrWwZ/m3CqXN+FJSsKfYUUDQQ/cD8L+czJVI8/TLpiwSn1RtizucNivyljIBAyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR02MB5876 Archived-At: Subject: Re: [Sedate] [art] [Ntp] [TICTOC] [Cbor] Two specifications on timestamps nearing WGLC X-BeenThere: sedate@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Serialising Extended Data About Times and Events List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2022 09:49:14 -0000 =0A= On 11/1/22 9:33 AM, Edward Welbourne wrote:=0A= >>> [snip] So they have to store the event's timing relative to a=0A= >>> specified zone.=0A= =0A= John C Klensin (4 November 2022 02:57) replied:=0A= > Not enough, even before getting to Paul's corner cases. Suppose=0A= > it is not, summer in the location where the event will be=0A= > located and the only time zone information is an offset.=0A= [snip]=0A= > If all the information we have available is a time zone=0A= > expressed as a numeric offset, there is not enough information=0A= =0A= That's why I said to specify the zone, not its offset at some specific=0A= time. A zone (usually implicitly) contains information about how its=0A= offset varies with time. An offset is, indeed, insufficient. A zone=0A= is, aside from the cases Paul points out, enough.=0A= =0A= --On Tuesday, November 1, 2022 11:18 -0400 Paul Kyzivat wrote:=0A= >> Interesting corner case. But is solving it worth the hassle?=0A= =0A= Yes. When I'm organizing travel, it's mildly irritating that I can't=0A= set the start and end times of the flight in different zones (the way=0A= the airline tells me them), but I can cope with making the needed=0A= adjustment to one of them so they're expressed in relation to the same=0A= zone. I get the train time at the other end, on the other hand, from a=0A= rail information system that takes its zone for granted, and I'll be in=0A= that zone by the time I catch the train, so I record it in my calendar=0A= as being specified in that zone. The calendar duly shows it in the=0A= "block diagram" of the day converted to whatever zone I'm currently in,=0A= so that it's correctly positioned in relation to my flight, but when I=0A= look at the details of the train journey the calendar remembers that=0A= those are *specified* in the destination zone, not my current one.=0A= =0A= That's important because, aside from not wanting to do the zone=0A= conversion in my head for every step of the journey at the other end, it=0A= gives me reassurance later that I did in fact remember to use the right=0A= zone for that part of my planning; I'm not going to get a nasty shock on=0A= reaching the station, discovering that I've missed the train by an hour,=0A= or that I have an hour to wait. And my 'phone auto-switches zone for me=0A= when I switch it back out of airplane mode on landing.=0A= =0A= All of which is relevant even if the zone doesn't change its rules=0A= between planning and execution.=0A= =0A= >> If so then what about the situation where the politicians=0A= >> redefine how a particular area is divided up into time zones?=0A= >> For example, where it is decided to carve out a new set of=0A= >> time zone rules for a subregion of an existing time zone. Or=0A= >> if a city near a time zone boundary is moved into the=0A= >> neighboring time zone. What would be required for calendars to=0A= >> handle this?=0A= >>=0A= >> These are rare events, rarer than changing the rules for an=0A= >> existing time zone. But neither happens very often for any=0A= >> given place. Where do you draw the line and say "we'll let=0A= >> people deal with this manually".=0A= =0A= > Or, as an almost-different question, "where do you draw the line=0A= > and extend the syntax to allow a precise latitude and longitude=0A= > as well as a conventional time zone?". Presumably, that=0A= > information, or something else that identifies a locale=0A= > geographically rather than politically, would be needed for a=0A= > user (or a rather smart agent acting for a user) to make the=0A= > sorts of adjustments Paul describes above. And it is easy to=0A= > imagine a user agent/ presentation layer smart enough to accept=0A= > "10AM in Kingston, Jamaica on the fifth of July 2023" and=0A= > putting "2023-07-05 10:00 -0500 18=B000'N/76=B047'W" or equivalent=0A= > into a calendar database in some appropriate format.=0A= =0A= Ideally, in fact, the calendar would record "Kingston, Jamaica" instead=0A= of a latitude and longitude. There may be some cities which straddle a=0A= zone boundary, in which case it may be necessary to distinguish their=0A= West and East sides. That records something the user will understand=0A= when it's displayed to them and is what software has some chance of=0A= knowing about.=0A= =0A= Of course, usually time-zones are specified by a representative city;=0A= the time-zone database doesn't know about other cities, although=0A= potentially someone could compile a database of such to supplement what=0A= the TZDB knows. So Paul's corner-case remains a problem there -=0A= thankfully, it is significantly rarer than politicians changing the=0A= rules of the zone you're dealing with.=0A= =0A= Eddy.=0A=