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 gIYhN5Z6w2OO4gAAbAwnHQ (envelope-from ) for ; Sun, 15 Jan 2023 05:01:26 +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 gA3NNpZ6w2NuJAEAauVa8A (envelope-from ) for ; Sun, 15 Jan 2023 05:01:26 +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 8187846467 for ; Sun, 15 Jan 2023 05:01:25 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGuC1-0002Nx-CS; Sat, 14 Jan 2023 23:00:25 -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 1pGuBz-0002Nl-G6 for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 23:00:23 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pGuBx-0007jY-OQ for emacs-orgmode@gnu.org; Sat, 14 Jan 2023 23:00:23 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pGuBw-0000uf-9o for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 05:00:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 15 Jan 2023 11:00:12 +0700 Message-ID: References: <63c287ca.a70a0220.4bd14.873b@mx.google.com> <63c2b760.170a0220.56455.a114@mx.google.com> <63c31663.a70a0220.3ab1f.a9e2@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US In-Reply-To: <63c31663.a70a0220.3ab1f.a9e2@mx.google.com> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 26 X-Spam_score: 2.6 X-Spam_bar: ++ X-Spam_report: (2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673755285; a=rsa-sha256; cv=none; b=GHiuI1SodsLPpcki1J5rHHAh7Vi5nliIaKNT2BCVVKQ4KjJiaf7OmG2T2KDJ8n4PZMgB8p knAb6acITBXez00PvY78OtpCmG6zYkP3UUWD8UCz63Dwe7nSNtEn/vmmZ/VpajKltiUTmc EDOLCjWD31mYXEfDIifAlyE3JkDYdVk4ZJ9Cv4J26OdngPsGm9IgXsaI4qC4Is9rM9hNAM yBkl6zbAEUdYbGHJ/HSKJ7KNwGq9cR6gkENQHo+FAhB6Hw5qa2AkwNLQ6lFrojYmVQcB6z hsMt9UtFbs8o2lAYBcJRVrBP6v3KXqoOaw9nOJud76UCom37v3xUuzxDYitHZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673755285; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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; bh=/HHN5ot4Y/wfp6m+KVkSZSb26lqiMLhzweneEOZqMQg=; b=bBqVrTj6HhrqKa42rjuStn0IANB/tBAQz9rDlOuPgfEy/fukxB+gnDjCyudcIsauXBHbTu pz+LVtlTS1867fwQ+GZ8tD0JMuF9k2zpkrpIMcgN1TWmz98U9pyHJMnLX3krsPqRV0LsIH Fu6gZs5ypZR0B96kpl6+FDLsEDWcO5Wl05GdcS17l4fhFIuuSqTG1NM2Nj8LBdm00UuSxN hxrSS/aUa+J0U4AoaKbyH9f5cUMIcXF8MEBx+xbCNznySiisWhGCx3JBCWE7uU6pyVns5Z g1gWgNMWnW8YuS+OrZrZNTU1YUidVXUfjzDfPtW2uOYSemRSoNyREEp2Xk2EIQ== X-Migadu-Queue-Id: 8187846467 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) X-Migadu-Spam-Score: -1.32 X-Spam-Score: -1.32 X-TUID: AAbvbcdYWVYI On 15/01/2023 03:30, Tim Cross wrote: > The UTC time stays the same, but the > meeting time for me changes twice per year (moving forward/backward an > hour). Meeting time remains the same expressed as local time (15:00), but alternates between 04:00 and 05:00 UTC. So repeating schedule can not be stored as UTC, instead UTC timestamp should be calculated from local time for each date. (Even libc can do it while you work with single timezone.) It is OK to store in UTC already passed events, but local time still may be more compact and user friendly. Actually I am trying to draw attention to a more tricky case when timestamp stored as local time is even more important. Event time is bound to local time, and timezone database changed due to new rules for this time zone: the government decided to cancel or introduce DST transitions or to extend/shorten interval when daylight saving time is active. For a timezone without DST time offset may be changed as well. While timezone database is stable, you can calculate UTC timestamps for any moments expressed in local time. When new rules are published some future UTC timestamps become invalid. If you know local time, you may update UTC timestamps. If you store just UTC timestamp you have a trouble. Paul Eggert provided an example of updating time transition history, so what is authoritative: local time or UTC, applies to the past as well. However I do not agree with Paul completely. It is necessary to decide for each timestamp, what is the primary data, time offset (so timezone identifier should be updated) or local time (so time offset should be updated keeping timezone identifier). https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54764#30 Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list Thu, 14 Apr 2022 15:46:58 -0700 > Again, that depends on the application. It's typically wrong to store an > old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because > there is no standard for what "Europe/Lisbon" means. If you update your > copy of TZDB, or interpret such a timestamp on another computer, that > can change the interpretation of such a timestamp. In this particular > case, a change in TZDB release 2021b altered the interpretation of this > old timestamp because we discovered that DST was observed in 1950 in > Portugal. > > If you want to keep the TZDB identifier for advice about how to > interpret dates relative to a timestamp, that's fine. But you should > keep the UT offset in addition to the TZDB identifier, if you want your > app to be fully accurate and useful. For example, you should store > "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by > TZDB release 2021a, so that when you interpret the timestamp in release > 2021b you'll have an idea of what you're dealing with. So keeping redundant information may be crucial to get warnings that some timestamps need to be reviewed.