From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id MKewBKNuyWMRKAEAbAwnHQ (envelope-from ) for ; Thu, 19 Jan 2023 17:24:03 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id eHe2BKNuyWMfRAAA9RJhRA (envelope-from ) for ; Thu, 19 Jan 2023 17:24:03 +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 39A081D490 for ; Thu, 19 Jan 2023 17:24:02 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pIXgy-0001UY-VE; Thu, 19 Jan 2023 11:23:08 -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 1pIXgx-0001UE-2h for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 11:23:07 -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 1pIXgu-00045z-4X for emacs-orgmode@gnu.org; Thu, 19 Jan 2023 11:23:06 -0500 Received: from cmgw13.mail.unifiedlayer.com (unknown [10.0.90.128]) by progateway1.mail.pro1.eigbox.com (Postfix) with ESMTP id 6ACC61003FD92 for ; Thu, 19 Jan 2023 16:23:01 +0000 (UTC) Received: from box2035.bluehost.com ([74.220.219.237]) by cmsmtp with ESMTP id IXgqpLfk8NX2aIXgqp9IeF; Thu, 19 Jan 2023 16:23:01 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=NMAQR22g c=1 sm=1 tr=0 ts=63c96e65 a=VozZY++RX3oc2UgfNhVfaA==:117 a=VozZY++RX3oc2UgfNhVfaA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 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=nXA5WNwiAAAA:8 a=3GbmggnxAAAA:8 a=o9zw6IYYAAAA:8 a=RJB84H5GIURFOeOrQNQA:9 a=d_VElMKDodcA:10:uccc_2email_address a=-FEs8UIgK8oA:10:nop_fastflux_domain_1 a=fVewNKELSH4A:10:wikimedia_images_1 a=fGr-7aqQv4RST94IA8XU: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-Type:MIME-Version:Message-ID:In-reply-to :Date:Subject:Cc:To:From:References:Sender:Reply-To:Content-Transfer-Encoding :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=6lv7zkfGOtPQTUWOvFr8vVtCJOw2hho/wvruzbJRdlI=; b=TSxjCzMtuD5D8OspadCoOKklu6 ZHw9ZQ8NyHj3kgrAsOp4cfXHBI+T2zmIiD2apEBUvlLPoJjQ+RUruyWp047mtDvV6SAfJsLDwEZ0+ 6gCnYMr942NXBS5RIqdcua6jOZq+tICb2NcBloR56K9S704abNtQ98RA+Llbh35jSZKrEeEEb/+sS OWeeZSgwyleL3Z0WmaJBtCL4rPyQS5BAJje1m/eyYttMMubNGj9CrnfVh1mWR+UyA2/iXwPF9GKHT 4Q9PB7arYpkjGAGODi2z4t8Cu/CTU6B325k2V2oz+PfM8FAst81SbW0MbN6Zp8+6GFtB4bBcnf7IJ QXlZ+PoA==; Received: from cpe-50-113-33-148.hawaii.res.rr.com ([50.113.33.148]:35518 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 1pIXgp-002mzu-TL; Thu, 19 Jan 2023 09:23:00 -0700 References: <63c66048.630a0220.427bf.a5f6@mx.google.com> <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> <87wn5jf2to.fsf@tsdye.online> User-agent: mu4e 1.6.10; emacs 27.1 From: "Thomas S. Dye" To: Jean Louis Cc: "Thomas S. Dye" , Tim Cross , Ihor Radchenko , Daryl Manning , rjhorn@alum.mit.edu, emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Thu, 19 Jan 2023 05:55:34 -1000 In-reply-to: Message-ID: <87sfg6fq8u.fsf@tsdye.online> MIME-Version: 1.0 Content-Type: text/plain; format=flowed 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: 1pIXgp-002mzu-TL 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]:35518 X-Source-Auth: tsd@tsdye.online X-Email-Count: 6 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-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1674145442; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=6lv7zkfGOtPQTUWOvFr8vVtCJOw2hho/wvruzbJRdlI=; b=rsOGJjeImSa7QANc1Gj/2PszpnH5js4MIFlesTkHj8CJnyM/FwLs50C2JGG2njFBizxshe 19CRP7EER2JJD7fWwKOx4YfSDYyj0OZgw2Rn+GRlY3zx5sBZeNWAAkJDs1q1wusaWvLQvj +dH4Ed8v+6M3MvtGMOoog7CPMovk9xxyCk2Dd0vX0qiqjZ4jKlQj+aBfFM4XRdLgNCDcvZ WT5uYW72iA6RmBg367xBuHwWKbjqTGOVh+HZwfN9nMWGm/8bLEop5OZsnzCFOeVBFj+9xN gfuTVuNAasdkLZKpuKoOdijKAHdKF7Hwk16VW01khX5THD4Qa9h9Nu++GT/iKA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=TSxjCzMt; 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-Seal: i=1; s=key1; d=yhetil.org; t=1674145442; a=rsa-sha256; cv=none; b=qQDulgPVC2fj/8XTkgxerd1nWQzvYYYm3D1Dn+Tyy7PJ2uYs4OJ75IeVdlivm+3kYg/ukC C29Hn2GA2WguUaDdn7OaIJ6bNfAfe6hWfHvctd+cX8XWHGAUPkC5W3QMKp89YWXoOGZH0i Scei9BwEyLOhgQB32REIAgntaojq4Ss3QqpdkLIpfPbCDmnU797aNSi2hEaj4AD+iaEP8D Fbxv4ySJOd8/QLPXucM7omtx51xwYNFpwxLrF7AMipzCWkgc74mSyeWjALfE7KeTEL67We sC8oARfW9zQ7Qi/jBVXUrdF59WiUyO+CQ9DrzJUmjKQdsfGuD3ccUWg3bqit4Q== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: 1.07 X-Spam-Score: 1.07 X-Migadu-Queue-Id: 39A081D490 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tsdye.online header.s=default header.b=TSxjCzMt; 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-TUID: RLSNC79C3zdE Aloha Jean Louis, Jean Louis writes: > * Thomas S. Dye [2023-01-19 09:37]: >> Meetings are occurrences, which require absolute time, which >> has no >> timezones. Org should record occurrences with timestamps in >> UTC, >> possibly translating from the user's local time. > > User in Grece needs appointment at 9 o'clock, and writes it as: > <2023-01-20 Fri 09:00> He also has TIMEZONE (either system or > Org file > based) set to "EET". That way the time has been recorded in UTC > for > Org purposes, and UTC has been solved. For Greek user it is > completely > solved. Org calculates UTC based on configured time zone. But > when it > is 16:00 o'clock in Greece, it is 06:00 in Seattle. > > Online appointment is sent to user in Seattle, with the time > zone > PST. He receives the Org file from Greece, at 8:00 o'clock, > which has > settings inside TIMEZONE="EET". At first user thinks that > appointment > is in just 1 hour, because he can see "08:00", but Org > gracefully > notifies user that appointment is (probably) in a different time > zone, > and asks user if user would like to have it displayed in PST > time > zone. User answers with "Yes" and on his screen appears that > meeting > is actually at <2023-01-20 Fri 23:00>, he prepares himself for > longer > evening, and waits for his Greek partner on Jitsi Meet: > https://meet.jit.si/ to get online. > > It confirms your hypothesis, yes, all times are calculated as > UTC, but > all time stamps at export, sharing, or change of time zone, > shall be > displayable in understandable manner to human user. > Only occurrences require absolute time, UTC. Events do not. They follow the user's space/time. >> > Org in this state can't handle such things. >> >> Org can do the useful thing: translate the UTC timestamp into >> local time and >> report both UTC and local time. User will be able quickly to >> determine if >> local time is incorrect for some reason, such as DST or travel. > > Other way around, it has to translate time stamp into UTC time > in the first place. Yes, to store the time stamp, Org must take it from the event time of the user and translate it to UTC. When reporting an occurrence to the user, then Org must translate from UTC to the user's space/time. User might have a toggle, like pretty entities, that either shows UTC or translation to user's space/time. > Expecting that all user among so many various time zones write > their > time stamps in UTC is not reasonable. Org users are advanced, I > know, > but majority of note takers with other applications will not > even > think of different time zones, it is surprise they get when > dealing > internationally. People are not ready for calculating or even > viewing > their own time in UTC time zone, unless they are English or > Icelandic, > Portuguese, or Africans in parts of the West Africa. > Org should translate from the user's space/time to absolute time, UTC. The user has to tell Org what is the space/time relationship to absolute time. Org might use the timezone machinery to suggest a space/time relationship to absolute time, and it might warn the user when the user's suggested relationship differs from the value reported by the timezone machinery. >> Storing timestamps in UTC solves the interval problem Ihor >> raised. Intervals always make sense in absolute time. Moving >> them >> to event time leads to the insanity Ihor mentioned. > > The other way around. Assuming that time stamps are UTC raises > problems for all other people: > https://upload.wikimedia.org/wikipedia/commons/8/88/World_Time_Zones_Map.png > > Org now does not support time stamps, right? > > So people write timestamps in their own time zone! Is it right? IIUC, Org currently stores events, which are relative to the user's space/time. This works for events, but breaks for occurrences, which require absolute time, UTC. > > My time stamp here is <2023-01-19 Thu 17:12> now, what is yours? <2023-01-19 Thu 06:08> This is an event, specified relative to my space/time. > > Forcing users to write time stamps in UTC would cause havoc. Agreed, Org should help. > > Thus time stamps already have their time zones, it is just not > recorded in Org file. Events don't need a time zone, only occurrences need absolute time. > > Options can be created so that: > > - user always and automatically record time zone in Org file, > for > example from system time zone, so that when first time > property is > invoked that it stays there: > > #+TIMEZONE: EET > > Or like this > > * TODO Appointment on Jitsy Meet with Greek investor > DEADLINE: <2023-01-20 Fri 09:00> > :PROPERTIES: > :TIMEZONE: EET > :END: > > or inside of the time zone. > > When such heading is read in Seattle, Washington, Org will tell > to > user or ask to translate it to PST time. > > In such translations, EET time is first converted to UTC, for > reason > of using system libraries, and not complicating Org, and then > converted to PST time zone. The Org user in Seattle would either see UTC or toggle to see UTC translated to Seattle space/time, assuming user set space/time relationship to UTC correctly. If not, then Org should warn user that the specified relationship differs from the one suggested by the timezone machinery. hth, Tom -- Thomas S. Dye https://tsdye.online/tsdye