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 ms0.migadu.com with LMTPS id 2I9zFc4XW2KvcwEAgWs5BA (envelope-from ) for ; Sat, 16 Apr 2022 21:23:58 +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 0NIcDs4XW2LdfAAAG6o9tA (envelope-from ) for ; Sat, 16 Apr 2022 21:23:58 +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 A231A2F024 for ; Sat, 16 Apr 2022 21:23:57 +0200 (CEST) Received: from localhost ([::1]:43686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nfo1U-0003C5-Gw for larch@yhetil.org; Sat, 16 Apr 2022 15:23:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38782) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfo16-0003Bj-Hj for emacs-orgmode@gnu.org; Sat, 16 Apr 2022 15:23:32 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:36080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nfo14-0003mb-CY for emacs-orgmode@gnu.org; Sat, 16 Apr 2022 15:23:32 -0400 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) 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) 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 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) 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) Message-ID: <507cc0a2-d2d9-4283-7cc2-0da3c6510ac8@cs.ucla.edu> Date: Sat, 16 Apr 2022 12:23:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Max Nikulin 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> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones In-Reply-To: <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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=1650137038; 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; bh=sl40O6dVAjrEwLIvnLutEPoRKIzlKClcWx18TYPmubU=; b=dwBgJ7R0Wx25BeITd90lCAFjAvZCtqcd3aL1h/RTzv4ZNOZUMUGqiFKnT8ZOcwhXBBVCsg URDEmtKiKJVNbYlyHSB14sK8fEWUZdeu9COu/ctu/lB40kHRPalrZLQ2VTBrqboqpJSlBh uX7f4cVKkPrJvn7jNByvJVWmhqNYYW+bH7RzhURwAbqeutJJmaA20a/LZrx6PTD/XmgxKr UwyIYD0T1pzE9lfGgvidUMEaaOwdFI6R1mZQ11tM7vxRSXYlaz5saFW/nvwNOmhbwAWN9F QCMxtpSCrOqQaUKhhaMzVqqnUez5jV1/jLJHGjY3idk/Yqe+QAW5yeRfVek23A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1650137038; a=rsa-sha256; cv=none; b=AsTyUqchnpd+1BHV807CfNQWAszHFfL0/jhqKz6jzqOeDAvdPrf1AyjGRkJOBowttSMvhB H5wxcN49uDs32T1ERGEy7DKv1kzrFlmcrQJyutsvHQH9XiSPKylMPAEI/2pFhAYGDYAE4s YUcFda25tEpl6aD7gASL8gjrD48Ce+OH38TKA7mEHpN/Gqxoi9xz5SQPiHfFMRXWnubhRB ceSci0v5F3ojb1nu2bv6ub0w3r8ZXLO+df/vd4uRLkCX7URMucxp8SGV1tQTNESaXyq1mQ F4/poaoq3qvBDs4SSjSxG1NtqUFUDKMBiVTjKw19MOKH1m6OPA1wFwblJFjiKw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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: -2.64 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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: A231A2F024 X-Spam-Score: -2.64 X-Migadu-Scanner: scn0.migadu.com X-TUID: hCi/XkwRto7q 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.