From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 KAYFO+NQxWMANQEAbAwnHQ (envelope-from ) for ; Mon, 16 Jan 2023 14:28:04 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 8C34OeNQxWP3EAAAG6o9tA (envelope-from ) for ; Mon, 16 Jan 2023 14:28: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 A1D88F1D0 for ; Mon, 16 Jan 2023 14:28:03 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHPWO-0006VL-OK; Mon, 16 Jan 2023 08:27:33 -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 1pHPWJ-0006Ut-0m for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 08:27:27 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHPWE-00005V-Mn for emacs-orgmode@gnu.org; Mon, 16 Jan 2023 08:27:24 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D7328240187 for ; Mon, 16 Jan 2023 14:27:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1673875640; bh=pCHowgad5zQ4lQqlXKxzymPrKIhYNjCHJPsSpmb+S2c=; h=From:To:Cc:Subject:Date:From; b=EuQkI3rt1zBY3KBJk1GAJ69tHz49Dmu8dMCtuVF46OBNrn6QS1K8YDRrlLesjF0nK mCVGTCYWJAh70pivwVya9V9UdEaPG8WWjpeavv5Afna18HN4cJ/ZRgb7wpKrcpUgKp AxLYlA//KqXrTTidKXJiZ7HSopTwkpwlg2VyTv93EqEQBFJb9ZsT5Aps2Mo4vCXVkZ 3lg0xnaSp2lGVqkjbvsIZ6fzXc52OcjHMMNVvOlcQ8N7XzY6LlefUW12aOHJpDMA4z yHH30i8/xI2SD2Y3pV4v1mPOz1nmQcug8OEmjgn0tklBKQv96SDvHT9FpuuryLt/fq TCOF1OfMeknHA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NwXr62Dsmz9rxB; Mon, 16 Jan 2023 14:27:18 +0100 (CET) From: Ihor Radchenko To: Tim Cross Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda In-Reply-To: <63c46c0c.170a0220.bf97a.b73a@mx.google.com> References: <63c30f34.650a0220.498b8.4573@mx.google.com> <87ilh7evsn.fsf@localhost> <63c46c0c.170a0220.bf97a.b73a@mx.google.com> Date: Mon, 16 Jan 2023 13:27:49 +0000 Message-ID: <878ri2licq.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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, RCVD_IN_MSPIKE_H2=-0.001, 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=EuQkI3rt; 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=1673875683; a=rsa-sha256; cv=none; b=qTuuQ6BMapU23/1IK07Qyn0RoGKXhPysJQhnOMTD0MZPkleobD9mLafO3D72zyYRpPWtDU y6NLBitrfHF4HXaxLjx7GQ+pC69L1IHm37ikhIkGvzCBqLYjSu3Ra3ujtBCQRDXVGIjarZ 7WaQtwJ3DDDin2sg0UYUd/akPTdvzo+ovbu9nupA6FrE1o9JtbZ3St5oYCjTCxYwFw/NjF GfGboO/iVa3drB4XTJP3nwL/uBA3H7P/g6y+AIF3D6skdIIOFwxpU/pYSwVOZAru28GDjx LkUCd0NfpFpr1pr2NBG0nQdu7UaH161XJq3K3xF/JJRXz1OXYhyZ4w7eLJtn1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673875683; 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=Q6jtSrkGJhoeBbXXLWBNoZ6+Ppf8cs1TtyAXqX7vPe4=; b=mkxLCIf83NJMC7Y0HwB0tOlB41b28ydGxQGPPG/9eviaGifOkRi51yVMbR2wFz3AK/Yy02 8KdFDdYl5aE3DmlaTcq9wUBBfwEEiqKVd7Ak5oQahlH1sgNrPk/CV6/visL9RHB7mha6IO 20dQ5/Ajc8V2uzpkUHyCYbnVrZR9CqH5vXn+OS2WudNi+UZmedcMiminy1B7/sx11u7hAu 0WWCCs19Nr1rrdCMR9a1Zs0FuZInAjOIW+t9uMwlvZndwbEDC5mNsFBVt+e7C//HigiFIs qOK8ZVQ72DOCTrsbi2Yjl4rhPhp6cKFixR1+qRazpxcwNwTt16mDcofLia4Fnw== X-Migadu-Queue-Id: A1D88F1D0 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=EuQkI3rt; 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: -11.17 X-Spam-Score: -11.17 X-TUID: QEkWUQVUItbh Tim Cross writes: > If the timestamp only contains the abbreviated name e.g. AEST, then > there is no automatic way to disambiguate - best we could > do is issue a warning. The abbreviated TZ name, unlike the full TZ name, > is really just a shorthand for the time offset from UTC at a specific > point in time. The full TZ name on the other hand states not only the > UTC offset, but also the TZ rules (and with things like the IANA TZ > database, the specific TZ rules in place at the point in time that > timestamp represents). This is essentially Max's main point - if > timestamps for the future have the full TZ name, then we can manage > things like changes in TZ database rules which occur after creation of > the timestamp or adjusting timestamps (for scheduled tasks) based on > changes in location etc). This would not be possible with abbreviated TZ > or just UTC offsets. Sure. That's what I proposed by <2023-01-16 Mon 12:00@Australia/Melbourne> But we may as well allow UTC offsets there <2023-01-16 Mon 12:00+0200> whichever users prefer to use in their use case. Both the variants may be preferred depending on the purpose. The first is good when we need to conform to local time, including all the possible changes in TZ rules. The second is good when we, say, want to schedule something "102000 _actual_ hours from the beginning of the experiment; don't care about what government may decide about winter/summer time in future" > So I guess the timestamp format and the code which manages them will > need the ability to use the full TZ name and not just the abbreviated > form (and I guess an option to allow the user to select). In fact, we > probably need a way to select between abbreviated/full dynamically as > well as you might use the different TZ types as a way to flag which > timestamps you want to adjust due to TZ changes (either in TZ db or in > user location) and those you don't want changed. Sure. We should get it for free because both GMT+8 and Asia/Singapore are the valid TZ values. Both supported by Emacs' `encode-time'. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at