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: Thu, 14 Apr 2022 15:46:58 -0700 Organization: UCLA Computer Science Department Message-ID: <52fb10fb-892a-f273-3be8-28793f27e204__12401.4408489288$1649976497$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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36680"; 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 Fri Apr 15 00:48:13 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 1nf8G4-0009OF-Ks for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Apr 2022 00:48:12 +0200 Original-Received: from localhost ([::1]:49744 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nf8G3-0003Zj-8Q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Apr 2022 18:48:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nf8Fu-0003Vx-PF for bug-gnu-emacs@gnu.org; Thu, 14 Apr 2022 18:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35433) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nf8Fu-0006ys-GA for bug-gnu-emacs@gnu.org; Thu, 14 Apr 2022 18:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nf8Fu-0006Iv-D9 for bug-gnu-emacs@gnu.org; Thu, 14 Apr 2022 18:48: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: Thu, 14 Apr 2022 22:48: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.164997642824013 (code B ref 54764); Thu, 14 Apr 2022 22:48:02 +0000 Original-Received: (at 54764) by debbugs.gnu.org; 14 Apr 2022 22:47:08 +0000 Original-Received: from localhost ([127.0.0.1]:57563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nf8F2-0006FF-8S for submit@debbugs.gnu.org; Thu, 14 Apr 2022 18:47:08 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:46274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nf8F0-0006Ei-9R for 54764@debbugs.gnu.org; Thu, 14 Apr 2022 18:47:06 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 37CFE16007E; Thu, 14 Apr 2022 15:47:00 -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 LmDHBoLP6G3B; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 42E52160098; Thu, 14 Apr 2022 15:46:59 -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 pxkTnR3jT3eJ; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2041116007E; Thu, 14 Apr 2022 15:46:59 -0700 (PDT) Content-Language: en-US In-Reply-To: <4a23f3a4-fe8f-d396-49d8-10034803be63@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:229899 Archived-At: On 4/14/22 06:19, Max Nikulin wrote: > date-time +=20 > "America/Los_Angeles" input should not be reduced to timezone offset in= =20 > the output. It depends on the application. For some applications (e.g., generating=20 "Date:" lines in email), it is entirely correct to output a timestamp=20 like "14 Apr 2022 15:16:04 -0700", thus losing the fact that the=20 timestamp was generated with TZ=3D"America/Los_Angeles". > Zone internal object or identifier is important for calculation of othe= r date-time values based on the origin value. Again, that depends on the application. It's typically wrong to store an=20 old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because=20 there is no standard for what "Europe/Lisbon" means. If you update your=20 copy of TZDB, or interpret such a timestamp on another computer, that=20 can change the interpretation of such a timestamp. In this particular=20 case, a change in TZDB release 2021b altered the interpretation of this=20 old timestamp because we discovered that DST was observed in 1950 in=20 Portugal. If you want to keep the TZDB identifier for advice about how to=20 interpret dates relative to a timestamp, that's fine. But you should=20 keep the UT offset in addition to the TZDB identifier, if you want your=20 app to be fully accurate and useful. For example, you should store=20 "1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by=20 TZDB release 2021a, so that when you interpret the timestamp in release=20 2021b you'll have an idea of what you're dealing with. > I want hints like "in the case of ambiguity resolve to transition time = immediately before/immediately after transition" or "provide suitable tim= e prior to/after to transition". Although that might be nice it's not what mktime gives us, and I doubt=20 whether it's a good idea to try to implement it from scratch in Emacs. > I hope, they may work without explicitly providing time zone offset to = the input that anyway requires additional calculations.=20 It doesn't require additional calculations on the Emacs Lisp user's=20 part. All you need to do is save the UT offset, and use it later.=20 There's so little overhead to this that it's not worth worrying about. > =C2=B1n hours may mean =C2=B1n*3600 seconds or time with same minutes a= nd seconds=20 > values but hours value is changed by n even if a 30 min DST transition=20 > happens in between. Sorry, I don't understand what this sentence is intended to mean. > `parse-time-string' has another set of problems. Sure, but that was just an example. You can write your own date parser.=20 The point is that when you save a localtime timestamp, you should save=20 its UT offset too, in whatever notation is appropriate. > UTC offset is another feature and implementing the hints I have=20 > tried to describe may require implementing from scratch full stack of=20 > time handling functions. I doubt whether that's a good idea. I've written that sort of code, and=20 it's a lot more work than one might think and it's notoriously difficult=20 to do it correctly. You have better things to do. > So I still do not see any point in mandatory DST and ZONE fields in new= =20 > interface of `encode-time'. I think we're in agreement here. As I mentioned earlier, I plan to=20 modify Emacs encode-time so that you can pass it a 6-arg list as well as=20 an 9-arg list. Once this change is in, the DST and ZONE fields will not=20 be mandatory.