From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 0NQbHMJzzWNuDAAAbAwnHQ (envelope-from ) for ; Sun, 22 Jan 2023 18:34:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id AFLxG8JzzWNLXAEAauVa8A (envelope-from ) for ; Sun, 22 Jan 2023 18:34:58 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DB22D3591A for ; Sun, 22 Jan 2023 18:34:57 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJeEX-0003Oj-Vw; Sun, 22 Jan 2023 12:34:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJeEU-0003OZ-Rd for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 12:34:18 -0500 Received: from alt-proxy28.mail.unifiedlayer.com ([74.220.216.123]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJeER-0003E0-TN for emacs-orgmode@gnu.org; Sun, 22 Jan 2023 12:34:18 -0500 Received: from cmgw14.mail.unifiedlayer.com (unknown [10.0.90.129]) by progateway1.mail.pro1.eigbox.com (Postfix) with ESMTP id 699FA100403FC for ; Sun, 22 Jan 2023 17:33:58 +0000 (UTC) Received: from box2035.bluehost.com ([74.220.219.237]) by cmsmtp with ESMTP id JeE9p0nT5iJ4bJeE9p4fPz; Sun, 22 Jan 2023 17:33:58 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=DfLSFthW c=1 sm=1 tr=0 ts=63cd7386 a=VozZY++RX3oc2UgfNhVfaA==:117 a=VozZY++RX3oc2UgfNhVfaA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=TP2bQshwf_QVURmJ:21 a=IkcTkHD0fZMA:10:nop_charset_1 a=MKtGQD3n3ToA:10:nop_fastflux_from_domain_1 a=1oJP67jkp3AA:10:nop_fastflux_mid_domain_1 a=RvmDmJFTN0MA:10:nop_rcvd_month_year a=DPR-AOO6AYYA:10:endurance_base64_authed_username_1 a=A2tt7buDTgEA:10:from_fastflux_domain1 a=pGLkceISAAAA:8 a=o9zw6IYYAAAA:8 a=11H84PglYk7I-IGoyQAA:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=-FEs8UIgK8oA:10:nop_fastflux_domain_1 a=EVVv6iHyYxc8UI9aA31H:22 a=BtxB1_lq3pBo68oZtZ_9:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tsdye.online; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:In-reply-to:Date:Subject:Cc:To:From:References:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rLqxCEQjJtCpzv5nDoEgpwcQXDwHDAX6m9tatmHbJJ0=; b=WOsSzfwiP0KlG0pyuL5QkQ7RwF TUyEbjPvBbBu4+uKxn/GranTJUvg/zbbPkeg66KW+UoM9eZnRPz8sqyYCvgRM4rnmo/FtTcmUB2Aa 7hcwNf9HX4xC7YOdvsY9AutvV7urQlwvoc7iUZ63zF+vZA/oJuVhegQD1U/2m6QZAf66D3AR2WTz2 FLJF1J5xL6XfkR7wiUWNuEdG/e2XT5xglftpEDaCMjty/4lqZsKaL+piGQEVrpyW+k55NFanmJxC+ CkzOgpsU4e9XLmzHjP3VZ+8UgxbUyujm+pZwtPIn2WPcM+9+ouiP6+M7QiX+Bw062I8cJg6kzpS2H Jt6ISgHw==; Received: from cpe-50-113-33-148.hawaii.res.rr.com ([50.113.33.148]:40040 helo=poto-foou.tsdye.online) by box2035.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pJeE9-003Grn-6d; Sun, 22 Jan 2023 10:33:57 -0700 References: <87r0vtiks0.fsf@localhost> <63c671c0.a70a0220.61aa5.56b8@mx.google.com> <87fsc88aq9.fsf@localhost> <63c7dd3d.170a0220.6b4d6.f84f@mx.google.com> <877cxk6oeu.fsf@localhost> <63c86454.170a0220.80970.652d@mx.google.com> <63c8f5a6.170a0220.ea8cf.7f96@mx.google.com> <63c9b654.170a0220.d82d2.4254@mx.google.com> <87lelxk87a.fsf@tsdye.online> <63ca5101.630a0220.b2298.3363@mx.google.com> <63cb2d0b.630a0220.f919a.6174@mx.google.com> <63cc5983.620a0220.a7d40.68f6@mx.google.com> <87r0vnhxj6.fsf@tsdye.online> User-agent: mu4e 1.6.10; emacs 27.1 From: "Thomas S. Dye" To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: UTC or not UTC for timestamps in the past ([FEATURE REQUEST] Timezone support in org-mode) Date: Sun, 22 Jan 2023 06:54:20 -1000 In-reply-to: Message-ID: <87ilgyiid8.fsf@tsdye.online> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box2035.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tsdye.online X-BWhitelist: no X-Source-IP: 50.113.33.148 X-Source-L: No X-Exim-ID: 1pJeE9-003Grn-6d X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-50-113-33-148.hawaii.res.rr.com (poto-foou.tsdye.online) [50.113.33.148]:40040 X-Source-Auth: tsd@tsdye.online X-Email-Count: 2 X-Source-Cap: dHNkeWVvbmw7dHNkeWVvbmw7Ym94MjAzNS5ibHVlaG9zdC5jb20= X-Local-Domain: yes Received-SPF: pass client-ip=74.220.216.123; envelope-from=tsd@tsdye.online; helo=alt-proxy28.mail.unifiedlayer.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1674408898; a=rsa-sha256; cv=none; b=asGAffeLeUeGoNBMyCjWU7UVjFygv5Moxd1fEQKntr2UoIDSJTZNH8n+Y+AEcRblR+4+vG EhG/NLm2VmmziKZu6aLfkND/L62aCoJDFJCyI/CrHpHwDjDvfczqsITpfFHdEPs020ND1F G6rJ8JzfgXd/0EZQbwtYi6PcK97YahLz/CEOp/QsKILTU1FYe+u6WBp/j7GZw/H7uP5Bat lHe4TFHWaZ0mNyD/jDWFIY3Gh5lDlYqD8a8oZ0OEroGH6nYWwVGh9WPgi6p21qmWht5dRV jpzSR6aCoB9UBfFUCnuaVP7uoEQ1CRSCcpR8A3PxmEk4N9bybR3RhA8eAfmI5g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=WOsSzfwi; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674408898; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=rLqxCEQjJtCpzv5nDoEgpwcQXDwHDAX6m9tatmHbJJ0=; b=ryWywF0MqOLIVP5MFkWokR7e2vDzOdaRWjUGlta2sbE6/Uha4tAeXYYVZRGFWmq8goO7Z/ YS+bVsl/QobUSAFOVrxmgvTBvoSeC9WxRRr3MlSn7HbB23XVDLXaQbRrVT3gMo22YozxY9 mcBLd13RPtzXkAcbTWl+07p+1Ap6hea+7h4A1H5OdGoMva5XzIwHFMQyVt7kFvtckkGQgD 8LebBl9YrA04KNdiUB/J7homvxQuqjg6MeCNfYi9o1JwuQVcThC2+yg0WePBf+95A3rO10 rRSVMZPZR5jXx8uwAp+G80W3YDqFLdwlIDRILSP2rxpssCDXhgHoBWKptL4WGg== X-Spam-Score: 1.61 X-Migadu-Queue-Id: DB22D3591A Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=WOsSzfwi; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: 1.61 X-TUID: D7DzZbqo/HIF Aloha Max, Max Nikulin writes: > Thomas, notice that I resumed a postponed earlier part of=20 > discussion related to > timestamps in the past. Offset from UTC is almost always well=20 > defined this case. > > My perception is that discussing timestamps in future, we came=20 > to agreement with > Tom that timestamps can be specified with timezone <2024-02-22 > 08:29@Australia/Sydney>, in UTC <2024-02-21 > 21:29@UTC>, or in local timezone <2024-02-22 08:29> > > Now I had a hope to convince at least some participants that=20 > explicit time > offset may be used interchangeably with UTC. It is applicable to=20 > timestamps in > the past and to future timestamps when the person who created=20 > appointment > respects remote participants, so decided to rule out DST and fix=20 > absolute time. Agreed, offset relative to UTC is absolute time. > > On 22/01/2023 13:17, Thomas S. Dye wrote: >> UTC is not a timezone.=C2=A0 It is absolute time. > > I do not see any point to consider UTC too special. > It is independent of the legislative tampering (DST, etc.) that=20 makes timezones difficult to work with. > Both timestamps [2023-01-21 Sat 21:29@UTC] and [2023-01-22 Sun=20 > 08:29@+1100] > specify absolute time. "+1100" means 11 hours, not particular=20 > location. Do you > have an example of a case where I am wrong? No, not if +1100 is relative to UTC. > I use the term "time zone" as a set of rules how to calculate=20 > offset at > particular time moment. UTC is a degenerate case of fixed zero=20 > offset.=20 > In this sense "+11:00" is not a timezone, it is time offset.=20 > Several time zones > (as set of rules) may have such offset at some specific time=20 > moments including > "Etc/GMT-11" that is a timezone. > This confuses me. Calculating offset relative to a timezone, such=20 as HST, refers to space/time and yields an event. Calculating=20 offset relative to UTC does not refer to space/time and yields=20 absolute time. IMO, using "time zone", which typically refers to=20 a region of space/time, to refer to a set of rules that might=20 yield absolute time invites the confusion Ramsey was hoping to=20 avoid. >>> A side note. In my opinion, *by default* timestamps should be=20 >>> created in >>> local >>> time with no offset or timezone. There are should be some=20 >>> preferences to >>> enable >>> absolute timestamps and a function to fix offsets or timezone=20 >>> identifiers for >>> existing timestamp when the user realizes that they become=20 >>> necessary (e.g. >>> before a trip). >> I don't think there should be a default. > > Unfortunately hard choice of default value or behavior is=20 > unavoidable during > development of software. Consider a user who just have installed=20 > Org. Till it is > explicitly configured, perhaps it is better to add e.g. clocking=20 > entries without > offset or timezone assuming local time. It should be possible to=20 > change it > later. > Is there some way for Org to identify when it is likely that user=20 has not specified time zone? If so, a query might be useful. >>> So I do not see any advantages of UTC in comparison to time=20 >>> offset specific >>> to >>> particular time zone, usually user's local one. My vote is=20 >>> [2023-01-22 Sun >>> 08:29@+1100] and not [2023-01-21 Sat 21:29@UTC] (of course,=20 >>> only in cases >>> when >>> identifiers like Australia/Sydney do not matter) with a=20 >>> configuration option >>> with timezone used fix offsets in stored timestamps. >> The disadvantage of time offset specific to a particular=20 >> timezone is=20 >> that the timezone offset wrt UTC can change arbitrarily. This=20 >> is a potential >> problem if the arbitrary change takes place between the=20 >> creation of the >> timestamp and the happening it identifies.=C2=A0 In contrast, UTC is=20 >> guaranteed not >> to change.=C2=A0 It is not a timezone, it is absolute time, a pure=20 >> continuum.=C2=A0 It >> is a requirement of occurrences. > > I consider the case when offset is already known because it is a=20 > time moment in > the past. Besides rare corner cases offset can be considered as=20 > a part of > authoritative data. Timestamps like [2023-01-22 Sun 08:29@+1100]=20 > can be > unambiguously mapped to UTC. > Yes, if +1100 is relative to UTC. If not, then it assumes a=20 timezone library that correctly includes the past time. >> I'm not sure offset is necessary for events, given that offset=20 >> can change >> arbitrarily.=C2=A0 WDYT?=C2=A0 It seems to me that once an event has bee= n=20 >> tied to a >> particular time in a particular time zone that Org's job is to=20 >> take into >> account changes to that timezone, such as DST and arbitrary=20 >> legislation.=C2=A0 >> These changes in the event's timezone need to be propagated=20 >> through the >> schedule for each user, so it is possible to synchronize local=20 >> timestamps >> around the globe. > > For timestamp in the past offsets simplifies calculation of=20 > duration. Offsets > may be used to fix absolute time before changing location when=20 > time zone was > omitted. Perhaps I will add more in another part of this thread. > > After all, for a person in Berlin [2023-01-22 Sun 08:29@+1100]=20 > may tell more > than [2023-01-22 Sun 08:29@Australia/Sydney]. I'm not sure to follow this. IIUC, the timestamp with offset=20 refers to absolute time, whereas the timestamp with the=20 Australia/Sydney timezone refers to a region of space/time whose=20 relation to absolute time is fixed for any moment, but potentially=20 variable over time. All the best, Tom --=20 Thomas S. Dye https://tsdye.online/tsdye