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 WOKNHkibYWJ0DQAAbAwnHQ (envelope-from ) for ; Thu, 21 Apr 2022 19:58:32 +0200 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 8GOdHUibYWKEhQAAG6o9tA (envelope-from ) for ; Thu, 21 Apr 2022 19:58:32 +0200 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 1349EA838 for ; Thu, 21 Apr 2022 19:58:31 +0200 (CEST) Received: from localhost ([::1]:34020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhb4Y-00082A-Gy for larch@yhetil.org; Thu, 21 Apr 2022 13:58:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nha9O-0000vv-6m for emacs-orgmode@gnu.org; Thu, 21 Apr 2022 12:59:26 -0400 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]:42633) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nha9K-00068L-0J for emacs-orgmode@gnu.org; Thu, 21 Apr 2022 12:59:25 -0400 Received: by mail-lf1-x12b.google.com with SMTP id d6so9770368lfv.9 for ; Thu, 21 Apr 2022 09:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=/HayKXcLOGIi6s4mxS1cdrAhl83GPO/yxZlm4ATy0YU=; b=HMx1HhWIiQKyf0EIUhnm2nvKmyAKEYoXLGG+l7n9kY9zT9j4qKklIp7GB7Ru0woRb5 1SyxZb1EX6LzuqxmxdT3z5fi+2ay1/9VfTYgiHROxdyW0K31DSVpy9Scsmm7yitVUjbr GxX3THYJEfvd9X8Hq9/LIPqrc8Z01Zj565eur+zKuN97sJCtZNJ2ATI/ePwsiPFgkU13 /oKo1J0BpccZAHTfEIhKnO75cbvtC1uEajzWm2I2YYsCkmlZDRU6hDPF9oHaGqaGe3hw cxtKNqW7s1MG+OS76s+BirI9vBVZXLmat3gtLvY9vZ2hheUQhoyWQhWbTssqRRb3cRbv uzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=/HayKXcLOGIi6s4mxS1cdrAhl83GPO/yxZlm4ATy0YU=; b=RMpbImQDerBqvQOk1ok0sZoQla0nLr4KEIqQhDPlDd+y8bd06t3Bak3JHXhHVSdSiV WfNxqS5yITBWMeArs7HRmRlpk901HOqwA8GtITMrG/lzS036t/YAQJ0mMaNMRY6sCiW3 G27/S0K+OkNNVqTNQabMXUMFLo36/ClDDgzjzrHYLkE8TFbfdE8Um+qX7H7lVAnirtc6 +ouAlwhbgN972fnH7sDujbdRof+hYji4rjHzxwEKng0/Sxon/NrZYAYu4S1rLEm0SdIp lJT5bFTCUYUja1y1ad7d18J6DpydX08pChGFQiIasmbo/p4Jm6Yc4irA7s9vGL0/PIAz U+jQ== X-Gm-Message-State: AOAM531ezusOibYyF+Gsu4r/Roh8tDlXX+iWmqvbXeoXK9PIf4eorOZM iAbwPhc4Sll2GN2vwzWryX19Vlmkwco1pA== X-Google-Smtp-Source: ABdhPJxPZdfcRoi5IWYugBIge5VPlbtEwOgG0NGhqta0mFEzlX8E5zt0G2r8e9Fprz5Q3Vcp0Xvrxw== X-Received: by 2002:a19:ac4d:0:b0:46b:ae5b:83dd with SMTP id r13-20020a19ac4d000000b0046bae5b83ddmr254951lfc.557.1650560360038; Thu, 21 Apr 2022 09:59:20 -0700 (PDT) Received: from [192.168.0.101] (nat-0-0.nsk.sibset.net. [5.44.169.188]) by smtp.googlemail.com with ESMTPSA id d6-20020a056512320600b0047196449b7fsm1266532lfe.92.2022.04.21.09.59.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 09:59:19 -0700 (PDT) Message-ID: <93cb9b51-ce2f-1ec0-73af-a9e40d78fae7@gmail.com> Date: Thu, 21 Apr 2022 23:59:18 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Content-Language: en-US To: Paul Eggert References: <5ed963b2-3fa8-48d8-627e-bc0571d15b43@gmail.com> <149de00f-115b-5367-414f-c7700ef8966b@cs.ucla.edu> <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> <52fb10fb-892a-f273-3be8-28793f27e204@cs.ucla.edu> <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> <507cc0a2-d2d9-4283-7cc2-0da3c6510ac8@cs.ucla.edu> From: Max Nikulin In-Reply-To: <507cc0a2-d2d9-4283-7cc2-0da3c6510ac8@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=manikulin@gmail.com; helo=mail-lf1-x12b.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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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: , Cc: emacs-orgmode@gnu.org, 54764@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1650563912; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=/HayKXcLOGIi6s4mxS1cdrAhl83GPO/yxZlm4ATy0YU=; b=TprAkjI6XBHU+oH2pZQ8x9/CIj8BUbbBVg2n2MOPfQBJBwbYbyC4Auoxe7FchiJjqPIfXS uEaB1vaA0Mzw/5d8HcQbPlygqnJ0i1qkpPPKVK6xlwu8EaE+aEwow0vXdjfEd+B0mhG7jv dPIZbJ6DXEOLWQOJ6v6AdRumWTUfQ7chwGFM8dmCoxoEcm6hnMMX0nFtdApWj1LN8aFDyA JmKiCzLFuA48mcJBfkZKir1CHOdf2OjzSldjE/mbM6xNEPkcftFt+cYq7eTeUdXodVuBJP 52c30AOqbGXl7MHHEAA0G+ZlHT/TK68Cs5UF0+HjLRnKqFIuoLyLOftzqvPxDA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650563912; a=rsa-sha256; cv=none; b=ID/GlHcp85VXVoNyjSlK2Tj9u3AVmkBX68ybWpcfriDuzcFHLil/o2W4vJbUQcw1BNXsfp 7art4m1JmMi/GhuskeWDSCgU1Hh7C2b4g9S+fuNbkgK4ifhqWEHaV78jPkmVruplWPXh/M 3lY5XgkgBDwsFS6RRb6MIHtToonR5zKGc1VS2mkN34i7B+wIS++phiVUWNC+yaffJredhH WI4ueEXf3oDFng9vEqyfjpT+719gy/LyOtDX3qmqz8jstAbFSIHnBnS+6xp+RCorR8eQba I9IvTz6ncNrkWnR3kXBMmiDrHr4KpbmNZC9HH2d7CenrnnlCwzKZEhjt0yAqUw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=HMx1HhWI; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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" X-Migadu-Spam-Score: 6.17 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=HMx1HhWI; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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" X-Migadu-Queue-Id: 1349EA838 X-Spam-Score: 6.17 X-Migadu-Scanner: scn1.migadu.com X-TUID: I/fq/F7aNV6w On 17/04/2022 02:23, Paul Eggert wrote: > On 4/15/22 10:23, Max Nikulin wrote: > >> if you are storing future events bound to wall time then namely time >> zone identifier should have precedence. > > Although that would make sense for some applications it's not a good > idea in general. For example, if you're scheduling a Zoom meeting you > should save both, because other meeting participants may interpret > strings like "Pacific/Apia" differently. I would say that in such cases there is a primary time zone for such event and secondary time zones of other participants. Time transitions in the primary time zone (unless it is UTC that is the reference) affect participants from all other time zones. If some secondary time zone is changed then it affects only wall time in this particular time zone. So primary timezone and offsets in all time zones should be stored for user convenience and to figure out which notification should be sent after introducing new rules for some time zones. >> Just identifier may be ambiguous around DST transition. So timezone >> abbreviations are ambiguous per se but when identifiers are known they >> may be still necessary to resolve uncertainties for backward time >> shifts. At certain moment the Olson DB started to use "+04" >> abbreviations instead of letters for transitions unrelated to daylight >> saving time. > > Yes, timezone names like "Europe/Lisbon" are ambiguous during fallback > transitions, or if the meaning of "Europe/Lisbon" changes. This is why > one should also save UT offsets when generating localtime timestamps. Before/after time transition around the date may be more meaningful for people. Local tradition may use other reference than Greenwich. > Around five years ago I changed TZDB to numeric use time zone > abbreviations like "+04" instead of my inventions like "GET", because I > wanted TZDB to follow existing practice, not invent it. A nice side > effect is that numeric abbreviations are unambiguous. (Besides, even _I_ > couldn't remember what "GET" meant. :-) Numerical abbreviation broke parsers in stable linux distribution, e.g. a patch for Qt required in addition to tzdata update. I do not remember details, but removed old-style abbreviations caused some problems as well. I may be wrong concerning usage of such abbreviation in the postgres parser and earlier generated text timestamps. On the other hand an abbreviation for a timezone with evolved offset significantly contributes to uncertainties and does not help to resolve ambiguity around time shift. >> And WET/WEST gets another bit of info in addition to numerical offset. > > That info is meant only for users; I wouldn't rely on it for > calculations because those abbreviations are ambiguous. It could well > be, for example that the meaning of "PST" in the United States will > change in the near future. I agree that abbreviations are ambiguous when considered globally. When constrained to particular location (time zone) and moment of time, they may provide additional bit of information that is more convenient for users and enough to resolve ambiguity. It is not a general rule, sometimes uncertainty remains even when abbreviation is known. >> I do not remember if it is possible at all to obtain using libc the >> period of constant time offset, when time shift value is valid. >> Sometimes it is necessary to recalculate offset. > > Sorry, I don't understand this point. One can easily recalculate the UT > offset in Emacs Lisp by generating the desired timestamp and calling > decode-time on it. You surely are talking about something else, but I > don't know what it is. Let's assume Europe/Lisbon timezone. `decode-time' for today gives just +0100. It tells nothing if I need to process some thousands of timestamps for yesterday and past week. If some function returns "+0100 for given timestamp and the same offset is valid for Europe/Lisbon since Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 02:00:00 2022 WEST till Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 01:59:59 2022 WEST" then I can process whole bunch without any worry concerning non-existing or ambiguous time, extra or lost hour in time intervals. mktime should have all this information during intermediate calculations but it does not expose it to callers. Interface of mktime is suitable for conversion of isolated timestamps. For bunch of related data there is enough room for optimizing. >> You wrote that "2021-01-31 23:30:00 +0300" is parsed correctly. My >> opinion is that when time zone is known to be Africa/Juba (system-wide >> setting, environment variable, or an argument of the parsing function) >> then "2021-01-31 23:30:00 CAT" and "2021-01-31 23:30:00 EAT" should be >> parsed correctly (and localized date-time formats should be parsed as >> well). > > That's not possible in general, since the two abbreviations can be the > same. Traditionally in Australia, for example, "CST" meant both "Central > Standard Time" and "Central Summer Time", and there are probably still > apps that use the equivalent of TZ="CST-9:30CST,M10.1.0,M4.1.0/3" which > does precisely that. They should still have some way to disambiguate whether local time precedes transition or follows it in various schedules: night trains, buses, flights. However it might be just "*" and a footnote. > It's hardly ever a good idea to rely on time zone abbreviations as > they're too often ambiguous. It's much better to use UT offsets. When > generating a localtime timestamp, one should always output its UT offset > (in addition to any other advisory info you might want to output). And > if you do that, many of the abovementioned problems are easily solved. There is no general rule suitable for all cases. In some cases it is more convenient to store timestamps as seconds since epoch. However there are cases when it is fragile: dates without time (e.g. birth date in documents, not for astrology) or future events. Actually input data should be clearly marked to distinguish from guessed or derived values. If wall time is what exactly known then UTC offset is secondary data. When presented to users, UTC offset may sometimes add unnecessary noise with no real value. I do not dispute that UTC offset is important, I am just trying to say that sometimes it may be inconvenient in usage. To build agenda view aside from DST and over transitions and assuming no travel across time zones, all calculations may be performed without inspecting of UTC offset.