From nobody Mon Nov 7 03:23:55 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 CB3ECC1524CB; Mon, 7 Nov 2022 03:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.108 X-Spam-Level: X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, 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_BLOCKED=0.001, 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 fXugFS0HQuMP; Mon, 7 Nov 2022 03:23:47 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60120.outbound.protection.outlook.com [40.107.6.120]) (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 44837C1524DF; Mon, 7 Nov 2022 03:23:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bZ8lyq/COHNOq4RDdLquSXSCCrTReAzFoYHVEK90NDkgRgb8yH3N2Nq5sWcjI7QTIYJzOQfPpaPMsCDOAswJ1hAoRtEkxY0S4dCEQaxZXdHo5Ez1fgURSD5HRKLJYLBH3EHpb4R+HlZjk3RsbswEXl6VxulDhLMb8BO6lzZPBeBgAlrjUuTHlFt4i6BzxZsk3bXjmQDKUy8rnUlnhVMJBONoMUHqI86F8Wie28evHwkUyiZo+mEs+LnzbI/AYMdVdqXQZaZhrXDMYuLXcstzUw2CsLN/f26MQjPyA/IUfARov9p1sE57H0Ipp5A2+Ot7OrIUc1c96+jUuX1N0o69pg== 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=GKiHklRt1cugsOFZYygB6YQVbNc3Zyi2U3Knn/jEhnE=; b=erObXurQhV0t55iIcSUxhnfOpoB3Bh3eu5ht5w1JkzHb4+8Y2LF0eaqID2eMX4OTncwZlgDx6UZ1umgM2iM7pW/Zaq3wkkDgPwEIJIHDkMjq+JeCMcc2Ld26GxS+hGxbo23GF55AVMKbsA05jm0MCtemOioCOSOraYy3P6hhfQXdFHG6Xdtuu5sxy1hwliH+XRUzgs/KJkIk/lImFFIkULVchMGapbcikQSw0S0R6zOfLKD1Ago+yiz7yUj7opbzTJPub54TlQkr98hAn9MFI0Nu4Pico1abpr9j3Wo2layrJbXIawgMW7jPRABhQiIsAXF7Ti1aaxUaEsa1L4qo0Q== 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=GKiHklRt1cugsOFZYygB6YQVbNc3Zyi2U3Knn/jEhnE=; b=muSRcQwYCq/Gnr6pAnBg4KZ6u5JywrHLnepNvTW58MH0ar1ud+b5U/wCSqcHh8xKWR7ehA/rUbWZTUDM+gP2FV0gwlzfj5s6fuJQRyVQ4U0GLZKdJgOYdWkLJ054oGvQuZtUcF09vzQJ+Qs5XMx+DnhZO21UnGvfO3dZSn/WY80= Received: from DU0PR02MB8218.eurprd02.prod.outlook.com (2603:10a6:10:312::9) by AS2PR02MB8840.eurprd02.prod.outlook.com (2603:10a6:20b:554::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.20; Mon, 7 Nov 2022 11:23:43 +0000 Received: from DU0PR02MB8218.eurprd02.prod.outlook.com ([fe80::590:e1f9:443f:3b5c]) by DU0PR02MB8218.eurprd02.prod.outlook.com ([fe80::590:e1f9:443f:3b5c%8]) with mapi id 15.20.5791.026; Mon, 7 Nov 2022 11:23:43 +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+1Z4isdo67Ja4uekj5gABR4ICABHxMrQ== Date: Mon, 7 Nov 2022 11:23:43 +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> <86FE5A8D9225A9B1FA9A1391@PSB> In-Reply-To: <86FE5A8D9225A9B1FA9A1391@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_|AS2PR02MB8840:EE_ x-ms-office365-filtering-correlation-id: b4c6b2e0-9d36-4089-43f3-08dac0b2873d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jMrmjOIOM7+X53DsfvpzBnNtCYFPcCYFrquvs0e8zKxNxen6B0O1TReNGhH0BOusSG8a/sNB7nsk8LgIIK7Q4pqXMZMVY0DfmCWMH3nRFDpYXVB3iPdGN4iqsYtRTbEjcFqyvdI5mS0NybHOUsRDue6NxNFzwchNUM31PeNX+QWTV64FoteAJbG41iSHRe5fleoP5WHOKg0ybKIXSvk3mc5j/qcXxnFijq3fhS05N33HC18OcmtFHF46BsdAvH0styzbyKIZ7UP2uje+9tnwGVRSM3XgQg1lYHFF+G4KPEcH+J2ASN/y9zR3FaHmf9bcarVfhXB+stqkPuByCAaupoE0uBaBvRd3WUTsk25DOJ8JpXFzS3Vxn5ODDEg7jFs7mH7MQy4WlopIn8B1OQB0IkpoTEOII/4eJz16y7RvWUUqytM22Z4DRj+n2A/M8z4J3iB7JSR+pTVvwQgbxJ6aqeOJiOC+qBQy8sqTPclAO7J+yLHlFFO8EPMmLsFpUh2JwnX2thgV0J5KOfDAznWEOa/kpJBad5vrFOTRWruXE2ophyKxZ+YEs7nSeAxgXKj+ESRo5N/bOhW6XTq8L3h9ApuTEASJs4fMeXhDhms9i/Qh2PcgAK5a9eRZCyXoEPP5dWOmJB7wMBmxw8DRmhuKYyaqZBDnxZzLt+zNoszzwuXgTGnF16DA0RJtNr6kKxDz+XzNKb+8F3IZyVJ3pE+UBIi40bQTGUXDZnfDlENO0sZBwPBCfGLA4Xd50DFwqBP62rlrfVVQ4R62QurUKz/fXK+Nmuch+PpNyr0beZDE8lA= 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)(136003)(346002)(39850400004)(366004)(396003)(376002)(451199015)(186003)(38100700002)(26005)(9686003)(6506007)(53546011)(122000001)(7696005)(83380400001)(44832011)(2906002)(55016003)(316002)(110136005)(54906003)(478600001)(71200400001)(52536014)(966005)(5660300002)(41300700001)(8936002)(91956017)(76116006)(66446008)(66556008)(66476007)(66946007)(8676002)(64756008)(4326008)(66899015)(33656002)(38070700005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?R1IoCFlIy50j+4bUPQe1VVg+AUdniwXr8Ct1XFWrmVbVxyDl0+A1V57T6V?= =?iso-8859-1?Q?Tl9xpcPKQltlFQD5EySK0SvPxbjC+HhCpjQjBl+L9TH6X+4Kmc8pW+bWRc?= =?iso-8859-1?Q?ygmNjdno5P5akP0iGHpoOWM8CLK1gm8ePe5DBdCeJdoyCQQJlcC/p5fSDB?= =?iso-8859-1?Q?Hs4uEF1XGzOU5csBGFEJkSy0HHRIY9GQmcgSYrFuQr1KyvGl6E0LHoRc3n?= =?iso-8859-1?Q?FEhpK4F0NAuhH8UtZPaBY40b3/cxExSncy3DI/EtDbpY8JXUafK46anDfg?= =?iso-8859-1?Q?auofG/AIB15psQOsURrMS2kw2ocDLJqqDbQd8HRz3gCaphuJRDyjU3rUS0?= =?iso-8859-1?Q?9XHLdhRhbB02VTo32BG0h2t1Hd3jbCx3KGpcNBDq5zT30uQDHm9ZXErp3v?= =?iso-8859-1?Q?e43w/SBEr45Rc5GXAqhhFY5diu4ANqDP797cqxQ+aFNnpOipOBWgFyjTMZ?= =?iso-8859-1?Q?PUSwXhbngq6rlNeIWaTa57G0tOJEKV1w24dBBYU1MgbdQuVD9rfZJ1e/eP?= =?iso-8859-1?Q?IfO+WOHkOUazWMCswWHHPLmK84kIYyu7GPusiaxz+r0t8hb5StW3y6lXkZ?= =?iso-8859-1?Q?Nxj7BAfNm+upGsk98pBRkL3TlqPJkr2QBWbhE9JmlBdLj2psmSHVUq1D+4?= =?iso-8859-1?Q?+bBtR8ZQlz86WlxRWdbCRN9KStoDliu97KUNDh6B6f9F9vZ4sYhEUK2IdO?= =?iso-8859-1?Q?tMegrM9gX/k3LbY3Vi6mNTSZReu35OBh61nWg74/+C/HO7p91d+ru89vUo?= =?iso-8859-1?Q?zpsf2xRTFGVT2qlJWQV31wvlJy9A/fCT4ORNDDWbSSe1HJ/xIaRDCFiymi?= =?iso-8859-1?Q?86EL4U2lJMoLCWizV7hvTQj7o3eFRdeJ46rBmxrEAbuArU7NeRt6nj0h+4?= =?iso-8859-1?Q?rb4mqOCF9o4Wuxl9kltgbLUzGSgYi6PuAh57EYawdUhq1AOCzyH98Mje0+?= =?iso-8859-1?Q?P/X/0KGFd2b/JU75Si7Yt4knhiZzrFsie1QLbGXWTDKgfRHl9119/w7Ayo?= =?iso-8859-1?Q?ihSn/DKy8g4Iiut6vhyMEV+z2nj6zsnHqBNckNj6VzuIyYNShCNx+OY+yi?= =?iso-8859-1?Q?GMLry3qryBgi7+lWSyyN9sN2YwAaIzrOTcY7f0U0BeBFYABBFgbMZbkJvC?= =?iso-8859-1?Q?k9df1kJh+C3igMB2gO32UEjXiqjrSfFkWQ/aRsS4VqCClCGqy6zPeg54ql?= =?iso-8859-1?Q?blVL7yuyc9xMGjLg97yDe2m5zbIhBPgxpvzwSA5jpt+6TTj09nv1HIVCzO?= =?iso-8859-1?Q?VJ3nfEYS7rfERNMrkUTO8sBZRKRUT9UG1A8wMB6ECRmibxIhju4VbsNUZY?= =?iso-8859-1?Q?UfgqLM9qFlx/P082579733mAdeIP/3esx0qczTUGC2bQf+cszZbLqeEk0i?= =?iso-8859-1?Q?/6GRZodx9LKtJbeQItgtyR0KcFDQJUH6oRh+yoKIJpuBwc/Mp0kJBgoEA9?= =?iso-8859-1?Q?swC18meJfImxkwYNX6/rcCKwRskksha6IYSZOkb0589Gx5tnVYbROKAlEA?= =?iso-8859-1?Q?tgIW0MbM2Ncd/IoNyPi99sVzOEWtpVq8PMHL0u0Zy5FX9WffS4aVQwQ/za?= =?iso-8859-1?Q?mgzM3c2IcewM2ydihkh5jbh2sl0/vFo9vbELCU4MXmnC29HsuJybHPRd+F?= =?iso-8859-1?Q?zVyJDJ/na2jzWdUPr1hCLx8W3FQn1HmjOs?= 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: b4c6b2e0-9d36-4089-43f3-08dac0b2873d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2022 11:23:43.1684 (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: J0/vFBzHLSi6NxSnzNLFrZ9NmMb73L4cduzjVfH6gAX0bkYbpFX/MxnW78KVjss93hO0ktjiHNfTVGNpKmfseQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR02MB8840 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: Mon, 07 Nov 2022 11:23:54 -0000 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 it=0A= >>> is not, summer in the location where the event will be located and=0A= >>> the only time zone information is an offset.=0A= >> [snip]=0A= >>> If all the information we have available is a time zone expressed as=0A= >>> a numeric offset, there is not enough information=0A= =0A= On Friday, November 4, 2022 09:49 +0000 Edward Welbourne wrote:=0A= >> That's why I said to specify the zone, not its offset at some=0A= >> specific time. A zone (usually implicitly) contains information=0A= >> about how its offset varies with time. An offset is, indeed,=0A= >> insufficient. A zone is, aside from the cases Paul points out,=0A= >> enough.=0A= =0A= John C Klensin (4 November 2022 15:02) replied=0A= > Actually, well, almost. Going back to the example I gave, Jamaica is=0A= > often identified as "EST".=0A= =0A= Time-zone abbreviations do not (unambiguously) identify time-zones.=0A= They are subject to localization and, even in a single language, there=0A= are zones whose abbreviations coincide. As I said, you need to specify=0A= the zone; hinting at it - whether by an abbreviation or an offset -=0A= fails to *specify* it.=0A= =0A= The other problem with abbreviations is that the standard-time version=0A= of an abbreviation is commonly used also to denote the zone when=0A= understood regardless of time of year; so "Norway uses CET" implicitly=0A= says that it also uses CEST in summer (for now - I hear rumours of a=0A= plan to scrap DST in the EU, but see no action towards it).=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=0A= >> what 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= > I can't speak to "usually" because there have been assertions on the=0A= > SEDATE and other lists about, e.g., time zone offsets in fractions of=0A= > minutes,=0A= =0A= The Netherlands, until 1937, was the last to stop doing that. They had=0A= their own Royal Observatory, IIRC, which defined time just as Greenwich=0A= did; that put it 19 minutes 32.13 seconds ahead of GMT. On 1937-07-01=0A= they rounded that to 20 minutes; except that they were in summer time at=0A= the time, so that was 1h 20m for the rest of the summer.=0A= =0A= Zones in the TZDB include an "LMT" period (local (solar) mean time)=0A= before the relevant jurisdiction switched to using a common time zone.=0A= TZDB only gives these to the nearest second (and enough of them are=0A= given as round numbers of minutes that I suspect at least some are=0A= rounded to the nearest minute), probably because most of them weren't=0A= precisely defined.=0A= =0A= A second's difference in offset corresponds to 15 arc seconds of=0A= longitude change, which is a bit under half a kilometre at the equator=0A= and less - in proportion to cos(longitude) - away from it. So a typical=0A= city is wider than a second in its local solar mean time variation,=0A= making finer-than-second precision only meaningful where there was a=0A= specific location used to define it and an observatory located there to=0A= measure it to that precision.=0A= =0A= > I have seen representative city names used in the TZDB, calendaring=0A= > programs, and elsewhere, but, as you sort of point out, finding a=0A= > "representative city" given a city or village name can be a challenge.=0A= =0A= Indeed - but you can always ask the person you're booking a meeting with=0A= what city their 'phone uses to identify their present zone. As long as=0A= the zone doesn't shift its boundaries between then and the event, you=0A= should be fine.=0A= =0A= > As an example, take two fairly small communities, about a half-hour=0A= > drive apart, in Arizona called Tuba City and Gray Mountain. Both are=0A= > in MST during the winter months. Tuba City switches to daylight time;=0A= > Gray Mountain does not. For most people, especially those who have=0A= > never heard of either, figuring out a "representative city" is a=0A= > challenge. For Gray Mountain, it turns out to be Arizona/Phoenix,=0A= > almost 200 miles away, more or less to the south. For Tuba City, I=0A= > believe it is America/Denver, closer to 600 miles northeasterly.=0A= =0A= Fun ;^>=0A= Take a look at Indiana's zone history some time.=0A= https://github.com/eggert/tz/blob/main/northamerica#L858=0A= (through line 1098).=0A= =0A= > I think that puts us largely in agreement, but I think we are talking=0A= > about applications that the SEDATE specification is not adequate to=0A= > handle, at least without either latitude/longitude information or a=0A= > supplemental database that identifies all of the localities in the=0A= > world with their mappings to representative cities over time.=0A= =0A= hmmm ... probably better, for each city in the TZDB, to have some=0A= description of the boundary of the region it represents, in each of of a=0A= succession of time periods bounded by the changes. I guess a polygon=0A= expressed relative to OpenStreetMap's open-source data would make a good=0A= way to do that. Might need to be several polygons in some cases, or a=0A= polygon with a hole. But still more manageable than trying to list=0A= every place-name within such a polygon.=0A= =0A= Eddy.=0A=