From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Date: Sat, 16 Apr 2022 12:23:25 -0700 Organization: UCLA Computer Science Department Message-ID: <507cc0a2-d2d9-4283-7cc2-0da3c6510ac8__28113.7467174389$1650137057$gmane$org@cs.ucla.edu> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14249"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Cc: emacs-orgmode@gnu.org, 54764@debbugs.gnu.org To: Max Nikulin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 16 21:24:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nfo1k-0003YG-Ln for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Apr 2022 21:24:12 +0200 Original-Received: from localhost ([::1]:44848 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfo1j-0003zg-Kt for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Apr 2022 15:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38846) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfo1a-0003wj-PS for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2022 15:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40434) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nfo1a-0003pO-EL for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2022 15:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nfo1a-0004pp-9j for bug-gnu-emacs@gnu.org; Sat, 16 Apr 2022 15:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Apr 2022 19:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54764 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 54764-submit@debbugs.gnu.org id=B54764.165013701518548 (code B ref 54764); Sat, 16 Apr 2022 19:24:02 +0000 Original-Received: (at 54764) by debbugs.gnu.org; 16 Apr 2022 19:23:35 +0000 Original-Received: from localhost ([127.0.0.1]:34331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfo18-0004p6-W0 for submit@debbugs.gnu.org; Sat, 16 Apr 2022 15:23:35 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:33678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nfo17-0004ot-Ma for 54764@debbugs.gnu.org; Sat, 16 Apr 2022 15:23:34 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C36AE1600C5; Sat, 16 Apr 2022 12:23:27 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id sHkkt4dNuOmQ; Sat, 16 Apr 2022 12:23:26 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D409C1600E5; Sat, 16 Apr 2022 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JBQkvrZ6gdER; Sat, 16 Apr 2022 12:23:26 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 9794A1600C5; Sat, 16 Apr 2022 12:23:26 -0700 (PDT) Content-Language: en-US In-Reply-To: <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:230016 Archived-At: 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. > 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. 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. :-) > 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 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. > 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. 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.