From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id oG9VBEZgxmNxDgEAbAwnHQ (envelope-from ) for ; Tue, 17 Jan 2023 09:45:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id YHljBEZgxmM0WQAA9RJhRA (envelope-from ) for ; Tue, 17 Jan 2023 09:45: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 C91CE966F for ; Tue, 17 Jan 2023 09:45:57 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHhaL-0001Xj-KU; Tue, 17 Jan 2023 03:44:49 -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 1pHhaJ-0001XT-SW for emacs-orgmode@gnu.org; Tue, 17 Jan 2023 03:44:47 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHhaH-0006uK-IH for emacs-orgmode@gnu.org; Tue, 17 Jan 2023 03:44:47 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 586002401BA for ; Tue, 17 Jan 2023 09:44:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1673945083; bh=J/qWHFr4MDFN99J4DVEohXtsP/AJfthBwWIrjYH/tNQ=; h=From:To:Cc:Subject:Date:From; b=qI+jr/EYpmjD76Nu2l1hwJdv0AK4WrO83ZG6gQ1wWUuXYU0nqcQBYYyqRKGM7r2Bj cfQZpg+ahcO22wHmrtue/KjsdYQ2VAlQSuelpkvgy+W5MDbM8I27RyOW407AWcRmpS TNVRtYKq528nl74G7WkQvNHBkWpRpfTa8sgi5NFSOzKocTfulVhDq7DDcl68NyR4wt I387p8stXZepfubH5ZoW7ZRpWWqVDC2vNK2Gi52a7Uq/uFrSFuT2kg0Qk5KRySBcEa 1nZ9yNc1PSQk3khIjuIVP4njdEQvXaZR0vFIcK4HI34zqqFC10+z/Bv7PAYVU+31QM NQfnnZfulQxmg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Nx2WY6zhPz6tmH; Tue, 17 Jan 2023 09:44:41 +0100 (CET) From: Ihor Radchenko To: Robert Horn Cc: rjhorn@alum.mit.edu, Daryl Manning , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda In-Reply-To: References: <86zgamtv6o.fsf@gmail.com> <87tu0t1i0c.fsf@localhost> <63c2aa9e.170a0220.3bb49.9ef4@mx.google.com> <87pmbhz1x6.fsf@localhost> <87wn5mlo7f.fsf@localhost> <87pmbelnd0.fsf@localhost> <87fscajo2q.fsf@localhost> <87cz7ejmgu.fsf@localhost> Date: Tue, 17 Jan 2023 08:45:12 +0000 Message-ID: <874jspk0rr.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, 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-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="qI+jr/EY"; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673945157; a=rsa-sha256; cv=none; b=pG3VEaZuNDJ393G6fmZJcsYNKofn0X70ivRB9xeIZao8K9/Tunh4zPAh9DVJUPM45GcSLh nYR7TZl3w/k5AymntU0QvczA2zFgb0D7IxMTFVrPrueOw0PMieBqBvAuw10j4ASLzDTsW1 A7x5oQFnGFH3luyrkkfp+hQKGKyjqvytMk8ejnVRd5WKaA+9l2D/Mu3TlHdn8YmzoWDgJK pyoDRdEqLDd42kXcwUZT3KXg+erq9x9qJ1xVqd2OuWLhVq9wcGrIQGNEH9pXo4tpfWaf1M SUCbTuj98swImc+4KY9kpFlOmsj9CnIehpn2bogeNxTto+s/nNCdLJ+cbqCidw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673945157; 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=vs/D+CcfRP+we3dMT23XaSH4fOBbptqOMRSs9TlDYGE=; b=LZOvbkZ4lREiQX4i7jPKgRdOxc7dEf9QB8nMw4QiYiWfixm8IzKwE/qLMN6BCPJwk+/USn bMYXhD6bmKqzPOMaeD+tyiNkjl8dgy/SxhMSjrT3V51sEuIjf0abWDNy+zdS17rW2KFALE pefGBZIgIJkGeihRXiVb68KfiU+Js9v1wxal03Xo2970WiwFqwOYRiSgkWw/YqbmBmZ9Bg LbhDyysGJmf/JIYVEno3fKU8ibhn/Md6ajlqkp2cA3taj5oufjoHicrdMZKZSVm9ka1LsU cXlSHBAfUqCzVKoWU9PoUvNlU4X8vH6pd4ZFhWcLbRvBYIHXZp+kyuFHCW18ZQ== X-Migadu-Queue-Id: C91CE966F X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="qI+jr/EY"; 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=posteo.net X-Migadu-Spam-Score: -10.88 X-Spam-Score: -10.88 X-TUID: V13tBmawkSgu Robert Horn writes: >> Not really. Countries may change DST at any moment in future. Or decide >> to switch calendars (consider countries near the day transition line). >> >> And "past local time, according to the DST rules in effect at the time" >> is also an option that might be useful in certain scenarios. >> > The issue is clarity of the expected rules for the format. If I > schedule a meeting for 10:05 DST, but the rules change so that it is not > DST at that location at that time in the future, what is the expected > interpretation? It could be: Let me clarify. I do not think that we need to offer selecting DST/no DST in the timestamp. Instead, we offer something like <2028-12-11 18:00@Europe/Berlin>, specifying local time, including possible DST transitions or any other political decisions the country might make regarding the local time rules. Or, if the preference is specifying time in such a way that it is unaffected by the local time rules (for example, "+10000 hours from now, no matter what the DST/no DST or whatever rules will happen in the middle"), one can use explicit UTC offsets like <2028-12-11 18:00@UTC+02> Can you think of any situations when these two variants are not sufficient? AFAIU, they should cover your example just fine. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at