From nobody Tue Nov 1 06:32:16 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 A3D2BC14CF09; Tue, 1 Nov 2022 06:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no 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 loPt7Sict_RK; Tue, 1 Nov 2022 06:32:07 -0700 (PDT) Received: from smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E2BC14F74A; Tue, 1 Nov 2022 06:32:03 -0700 (PDT) Received: from client-0198.vpn.uni-bremen.de (client-0198.vpn.uni-bremen.de [134.102.107.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4N1rXd2QvxzDCbM; Tue, 1 Nov 2022 14:32:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Tue, 1 Nov 2022 14:32:00 +0100 Cc: Danny Mayer , "art@ietf.org" , "sedate@ietf.org" , "cbor@ietf.org" , "ntp@ietf.org" , "tictoc@ietf.org" X-Mao-Original-Outgoing-Id: 689002320.622666-e7808c846e13fb381899bb1cb94e5d3c Content-Transfer-Encoding: quoted-printable Message-Id: <98EC8A2B-B5F0-493C-9F39-701ACA7AE886@tzi.org> 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> To: Doug Arnold X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Sedate] [Cbor] [Ntp] [art] [TICTOC] 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: Tue, 01 Nov 2022 13:32:09 -0000 On 2022-11-01, at 14:06, Doug Arnold = wrote: >=20 > I agree with Danny. The proper way to handle time zones is at the = presentation layer of an application that displays local time for = humans. Machines should never use local time for any other purpose. This discussion is completely off-topic for the present thread. I mentioned that there are activities that go beyond this line of = reasoning (not invalidating it at all, just embracing a more complex = reality as well), which motivated me to mention the timezone-oriented = work done in SEDATE. If you don=E2=80=99t care about this, please just mute this topic (and = certainly please don=E2=80=99t reply to it). Gr=C3=BC=C3=9Fe, Carsten