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 SHWNGStewWM7XAEAbAwnHQ (envelope-from ) for ; Fri, 13 Jan 2023 14:35:39 +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 CJ6BGStewWM3RQAA9RJhRA (envelope-from ) for ; Fri, 13 Jan 2023 14:35:39 +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 D2421279BE for ; Fri, 13 Jan 2023 14:35:38 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGKCm-0004DY-93; Fri, 13 Jan 2023 08:34:48 -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 1pGKCX-00049l-Vs for emacs-orgmode@gnu.org; Fri, 13 Jan 2023 08:34:35 -0500 Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGKCV-0003NX-R8 for emacs-orgmode@gnu.org; Fri, 13 Jan 2023 08:34:33 -0500 Received: by mail-pf1-x42c.google.com with SMTP id s3so13660614pfd.12 for ; Fri, 13 Jan 2023 05:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=Z6g1sIjZhSAtHPtbSKwSGNRgjwaEfas1LXOO8GQecfw=; b=Y4aIN56x43lk7o6yJpw9wEP7bKc2q4ueTznbcgh6zRkAuMIEVKri5+5al6YTc97Xoc 26CHxQn0H9jQWglPBUJRDqdkNaPMW/JU/e7CbuonLanhy6lBzmuW+nGcQF+vc76jWfI3 /mgpUU+ZYIxh8R3jqXv40S6+JHWkXWHXy4NDNVo+SPuGRpt4U4O9s6/rMuksL+GCaxJ2 p3vZ+F7+/e9WWBfxcLJLZ29rE8pTdW8MLJnucMRQ5L+lc7/NeBQ8XS/R8bQblC1P4yGg m5V/nV64KtpuvlB2ksyVNCPEBlquafZUlsSnmQZJ/dI+nLd+XPlbtq5h4UQfNBQ0J/N4 9NMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Z6g1sIjZhSAtHPtbSKwSGNRgjwaEfas1LXOO8GQecfw=; b=j/DgCcGgNdlxcIQ0Upxnc42UPdOzN7OhHq2nWIYfpLPl5VKYzBwVFVtu8VYiA1zDi6 pPzcStntahFZENYaTm+oSHCHCTW9aaEYXOo7JizE5ZaKZPUR3vyoEbE00D5y+gDpKUu3 1vJtZtdUkRmN4t3IwyCIcUk0s2o+AnuSItbekxhgjtty5vjbgOhrXOPSNP/avxNBqdGB Nppaw8E0kufprw4rWCpIKqSyTrAtUQ5YGoSioEEykpP09tM+nxujAZU0fE7OSTdxG9XZ sKdRnQTg7WtpUxWWuTL9EaqHV57sNeEU1HWpuzjOJhUUJlgjYJb0qIwEIIDuUIHa1dKz 709w== X-Gm-Message-State: AFqh2kp6xizWCMz078qUvB+gmU23YpIdSu167wqwqqG81YvTzPZZtfAt sQkSuKt6TGEOQI9Pvp76QXTAqerwMoQ= X-Google-Smtp-Source: AMrXdXvedQVrRWcZ+pBOfwihIu5I8L3rIRAI1qjDoyut6y3qXgvfNdjWJQx/FfkFjk9MwUOR4AkhfQ== X-Received: by 2002:a05:6a00:1308:b0:586:6e0d:2aca with SMTP id j8-20020a056a00130800b005866e0d2acamr26230935pfu.7.1673616868665; Fri, 13 Jan 2023 05:34:28 -0800 (PST) Received: from dingbat (ppp121-45-135-206.bri-pow-que-bras31.tpg.internode.on.net. [121.45.135.206]) by smtp.gmail.com with ESMTPSA id 128-20020a621586000000b00580ff8ff1c7sm14054632pfv.144.2023.01.13.05.34.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jan 2023 05:34:28 -0800 (PST) References: User-agent: mu4e 1.9.12; emacs 29.0.60 From: Tim Cross To: Daryl Manning Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Fri, 13 Jan 2023 23:51:54 +1100 In-reply-to: Message-ID: <86zgamtv6o.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42c; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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=1673616939; a=rsa-sha256; cv=none; b=BP6PRE84CRX2DfehHHbTrThl4EUr5sOktepSTsT40kp/zpLG/AQ+v0K3S5HR34S3og6/yh bcvuSadLgRvEKa1ehLbzUfmbh8PkX+v0hau2WzVo1M45PJD3GEalq097c35JHArvWn5woL LPamKL6fk0Tnnp94ynDuE6NtvmP1qiDiZenYpFCJmiX2vYC88cpZrHzZpkKLNoWbqTSqyF QXkA7VKJ0v35Fx/4yu2zIIBVxMitIZh/unZsR77SANBXNzfhMXLkgdzUyuilnStf10US2Y imBWxZFqn71t9H2fjRx3AblfLA8y1JFzjr7XC0edBqW7Od63uEAoHtdKX6PbKQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Y4aIN56x; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673616939; 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=Z6g1sIjZhSAtHPtbSKwSGNRgjwaEfas1LXOO8GQecfw=; b=UOLDCapTn8EDr7cltltPI/9SqPIqHVRBPpaWAMtWQBA7fkkcaa3VEJNxMswqShjo1wcK6a jI6QU8OFhHIOtm54hmsAAWPUFihn6Ej0E7WG7c4+UzFMEwJ8srxzxCfjYJDCSQAvJ00Tf5 1siEJnS2yTn6tsRzAutOsAKL3MBMRmnhfwzCA+1vzCTcJiUTxPSdQ8M2C8Fdu8q4YjJdEy wYYHJBEyQ3hxTRMjFWNsvot7fB9BhPehZuE8YwEH2irVALM0IdvpIl3SjFCzC+m2uesVa0 EjsfYjhBfqtx5DjaVt5pYCXhLuIi9ERRc7ubuDAzGsgSDN+DwgcdgzQb84JKtQ== X-Migadu-Spam-Score: -4.75 X-Spam-Score: -4.75 X-Migadu-Queue-Id: D2421279BE X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Y4aIN56x; 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"; dmarc=pass (policy=none) header.from=gmail.com X-TUID: JXp0omO/mZqN Daryl Manning writes: > Following on from thread at https://www.reddit.com/r/orgmode/comments/zrppqw/ > > [First off, I just wanted to say thank you to everyone that works on org-mode. It is a wonder.] > > While I realize a few kicks at this can may have been taken, I wanted to (re-)propose Timezone support in org-mode. The > world is much less local these days and we're all more remote and coordinating globally these days. > > *Background* > > 1. org-time-stamp-formats TZ currently only affects display and exports > 2. org-agenda itself is not TZ aware > 3. Several discussions on this have taken place over time > 4. Concerns raise included breaking backwards compatibility > > *Proposal* > > 1. org-mode sets an optional variable (org-timezone-aware t) which enables TZ > 2. org-agenda needs a way to determine which timezone it is in > 3. Once enabled, any timestamp not exhibiting a TZ in it is considered "local time" wherever that is (I do not think UTC > would work for this) > 4. org-agenda can calc local based on TZ differences > > I understand this is by no means trivial and quite gnarly with DST and such to figure out but I do believe libs exists to > deal with that heavy lifting. Currently, it does feel like a hole in org-mode as a 21st century organizer (disclaimer: > digital nomading so might feel it more keenly). Also, just interested in making org-mode a more awesome tool for > everybody. > > I'd love an understanding of the alluded to reservations raised in the reddit thread and in the mailing list threads > mentioned that the format change might break things (I was unsure if that was referring to say, how time ranges were > handled, or how say date ranges got dealt with (for example, say a flight from Singapore to Vancouver which takes off in > one time zone and lands in another - something that is often in my cal.). > I agree this would be a great feature to add. However, after having looked at it in some detail, I realise that not only is it not a trivial task, it is actually a very large and complex task and will require extensive work which will almost certainly result in breakage with regards to backwards compatibility. At the risk of over simplifying the matter, I would suggest the big challenge here is that there are two somewhat competing (and conflicting) use cases. On one hand, you want a high level abstraction which makes working with dates and times easy and clear. TO some extent, that is what we have now. On the other hand, we need something far more complex which is able to handle multiple time zones. This means being able to handle both base timezone offsets as well as offset adjustments for things like daylight savings time. There is a lot of hidden complexity here. You have to handle the fact that daylight saving chang-over dates/times are dynamic i.e. not necessarily the same every year. This adds the additional complexity of having to somehow track historical information regarding such changes, which isn't as readily accessible in a consistent manner on all platforms. Then there is the other 'messy' stuff. For example, when calculating time ranges and number of days, hours/ minutes between two dates you need to remember to add/remove the hour if the range crosses over a daylight savings period. Similarly you need to ensure you make the correct adjustment when changing timezones (consider emacs on a laptop for someone who travels a lot between different time zones). Not only do you need to take into account the different timezone offset, you also need to look at the date and then adjust according to the timezone offset for the current timezone at the time of the timestamp rather than just considering the current time offset. I expect what is needed is an 'internal' UTC based representation which is used for all calculations and an 'interface' layer, which converts the UTC representation into the local display representation for consumption by humans. The problem with this is that it is likely to break the core feature of org files i.e. that they are in plain text. I guess we could possibly do somehting clever with overlays such that UTC date/times are rendered/presented in local time format. However, we would then also require some type of interface for users to enter dates/times (to ensure they are converted to the correct UTC internal format). However, the real challenge here is that this is a very large piece of work and it needs someone who is prepared to take it on. I suspect until someone who needs to scratch this itch sufficiently comes along, this is a feature which will be unlikely to make it to the top of the todo list. There are simply far too many existing feature improvements and additions people will prefer to work on before taking on this one. Things are made more difficult because it isn't the sort of task which can be achieved with small increments over time. This is more likely to be something which needs to be developed in a feature branch, which once it reaches a sufficient level of completeness can be used and verified working for a wide variety of environments before then working out how to fold it back into the core system and handle whatever change management will be necessary.