From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 AFQVD9Oxw2OQvwAAbAwnHQ (envelope-from ) for ; Sun, 15 Jan 2023 08:57:07 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id mDk+DtOxw2MDHQAAG6o9tA (envelope-from ) for ; Sun, 15 Jan 2023 08:57:07 +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 A715C23319 for ; Sun, 15 Jan 2023 08:57:06 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pGxsQ-0008I6-2L; Sun, 15 Jan 2023 02:56:26 -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 1pGxsO-0008Hy-PX for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 02:56:24 -0500 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pGxsM-0000aa-Jt for emacs-orgmode@gnu.org; Sun, 15 Jan 2023 02:56:24 -0500 Received: by mail-pf1-x436.google.com with SMTP id g205so1851307pfb.6 for ; Sat, 14 Jan 2023 23:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ahjn9fuT3yPhjP0g7dI2a47Fj4SBOTKYJL3eGL7ApKU=; b=AOVUrB0yTsugRnV/bxiuP2WT5gzhLXzQ2AK0m1Grr++iwPz0qvvRrOqABw5BEhUEdj LsgxjkEpG147YBdAcDX/Nj254Uz/uUoXsxsIfxqqlbV1jhbRLiyEn7edezyUB8O7G0E1 F1yk8OfQHoxdQhMZ9X5wHiee/aWTFLIdgYqzq5DGK5ZbFOqbJ/osu99moNpnc4ggTWNn pp2/On6uiiRK3eZHWrtuIxStwzGB5NZtXTBFybr07/QK2ds1/16EOGk3JYULwM8bT9rz K2tHE32nsYK+55mki+f47/ZxW/zW9EQuAvQhyzX4FLzS6cmD0B/ofMB4EkuqbnzoZOgz ZwZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:in-reply-to:date:subject:cc:to:from:user-agent :references:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ahjn9fuT3yPhjP0g7dI2a47Fj4SBOTKYJL3eGL7ApKU=; b=X3yAEGmEPgE2WMZp7AhHJL73MRxxoJvB9NxeLPWqXeZV7o6D8mzFOYLYmMWGRYJWVm w4nQprFWbOcqnLddzziLS0Mth7G7mQ3OML2uP5SN1kPNPRThVWavMtkps5JFc7LZx2nk hJ+La9h74etSooUFdkwhgWxpvTP4y5CF3bFPBMC4rnzEvKKVg2WcapZXwJZQRGx5UsIp 1sPV6MKvqlgYs37qxpx6dBZkGiqiF+9L3Lh4THfnva5BHy+b6ac8xa/DAYmvEWSAJj4k yv4eng++seB5LBQ71krNsKT4lPlKENI6H6cjSuKr6s+5/CK7fUsKvVhlwaVypCZRPHdS pzew== X-Gm-Message-State: AFqh2koAlsUEjGJJMy+zpz+8OtiYv1f3YLw3oU2l7RfJlt5vpmFwinVA w2wa+M/hqKXEPxD7YMnhdUqEA9LclqE= X-Google-Smtp-Source: AMrXdXt/x4WfOz83EGtAmxhHTDwb59/4q2wFeAwA4wIGdSkB4IGbSCQ5gdlOW7mGDBsdLmzdck7qmQ== X-Received: by 2002:aa7:8812:0:b0:582:c142:d4b8 with SMTP id c18-20020aa78812000000b00582c142d4b8mr44004860pfo.0.1673769380856; Sat, 14 Jan 2023 23:56:20 -0800 (PST) Received: from dingbat (220-235-140-148.dyn.iinet.net.au. [220.235.140.148]) by smtp.gmail.com with ESMTPSA id a20-20020aa795b4000000b00576145a9bd0sm5395401pfk.127.2023.01.14.23.56.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Jan 2023 23:56:20 -0800 (PST) Message-ID: <63c3b1a4.a70a0220.225b1.83fe@mx.google.com> X-Google-Original-Message-ID: --text follows this line-- References: <63c287ca.a70a0220.4bd14.873b@mx.google.com> <63c2b760.170a0220.56455.a114@mx.google.com> <63c31663.a70a0220.3ab1f.a9e2@mx.google.com> User-agent: mu4e 1.9.14; emacs 29.0.60 From: Tim Cross To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda Date: Sun, 15 Jan 2023 18:53:26 +1100 In-reply-to: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::436; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x436.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=1673769426; a=rsa-sha256; cv=none; b=SGUptaEBbQCCafwp2JP7qVM00INcgx/V0Xr7eGcGn0Mde/3Dy8xVa9n6jQctLT1bXN/+rT uZT9lDB9+mSMi741rsYv8UkS0mvOtpp7tk8GxqUAzTdcLsip6cofEgG//2BAKWxvkQJaas A36/XijOp5J+4uoh5SDjEgcJs59FIZNkz7mU/62H/9+P2ZmDL+8FRrh12VDGfbpNF21LZg k0pUucf2UnXAy45RxLEV8Ok7yV1SgJAdeTDHwCFJ4Sibc+eJunOllUuHiZfF8evRwgYzsO zsYCnU8Mdwh5YvXKrrBjoNRL35GVjiv3mLH+GT28wJFJnN07PUFAR4q+HL/39w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AOVUrB0y; 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=1673769426; 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=ahjn9fuT3yPhjP0g7dI2a47Fj4SBOTKYJL3eGL7ApKU=; b=eqbCtNI9P501IdsUlbCGLncY/U0hFB16LjYC+ofAdwYS8SofhxUh4ypTD2W5Qv6XS/21S/ kFjgrY7TcmQXydX3TzdCsAeMOoe/bteFOC6uw24kr8OBL4CLvyt8QU0+U9USDEpHl6MIQq 3RS9DGjmULCOUy4aqGX/Ze09pVDvqOG0+ryx1o1e5nJBysXueI2tzjyuw6lOA6X6I3RKv1 zo1gyN1bSZtYissQ4b5uyMOZ492xdpKXYH09h+73T4CD4ylHK7iKGiJObRbYbl+NllX59v Gnw975DBqLzXGUVQ1JT9KyCN+icl5ZNqcoFJM48U8SV6Q9kwVujV5R2LhPrYIg== X-Migadu-Spam-Score: -4.77 X-Spam-Score: -4.77 X-Migadu-Queue-Id: A715C23319 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AOVUrB0y; 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: dffY3O7rew1C Max Nikulin writes: > 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. WRT future timestamps, we would probably have to take the same approach as postgres i.e. the timezone rules in force at the time the timestamp is created are assumed to be 'forever'. While this is not true, it is really the only solution you can adopt and you just have ot accept that there is the chance that the rule will change in the future and the timestamp will then be incorrect.