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#72570: 31.0.50; Regression in date-to-time Date: Tue, 13 Aug 2024 12:59:00 -0700 Organization: UCLA Computer Science Department Message-ID: <73e0c4d0-5eae-4b3d-9937-9aa9ac395ffa@cs.ucla.edu> References: <86zfpige7k.fsf@gnu.org> <892ebc72-1020-471a-bdcd-8e8da10d61dd@cs.ucla.edu> <86ikw4hdw2.fsf@gnu.org> 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="31435"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: ulm@gentoo.org, 72570@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 13 22:00:05 2024 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 1sdxga-00081S-A3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Aug 2024 22:00:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sdxg2-0004UT-GY; Tue, 13 Aug 2024 15:59:30 -0400 Original-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 1sdxg0-0004UJ-Jz for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 15:59:28 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sdxg0-0002rz-B3 for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 15:59:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=bUwerpxy3b2OVw/nGme9441XvuS/SzvkbzqsPhTHqec=; b=X3aqEo1XMsftbtY0TmqUh4HhM0ctWXVTnXW9godR7vQaFAUMZhr1eOSLMeg9xFqFCN5lwluZQFEFeTNh6YRSqCw4c/iJJxipt5tTwdaEvK+ArOuz67Ixwe9BmiKWpuh6tBwcITBLYZuOHoRRScKFtu6Wzj5VsqhLK8vIXqBOAtuAVkyx1742Hl/r5FTUAwsb93ycy4m6HWwRwJ0RHw8JnPDKugv92TvlJsPVnBT2srrhPMAFB8BqKqTZis+TyV622V2wIxkqaQ52/h6Vh+jf718PMaX0mXEkAkwU1dHYURu0VWgt70PKTGdX4yay8RgR6SJsYczHNFT7mKBF2L529Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sdxgY-0004i5-2i for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 16:00: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: Tue, 13 Aug 2024 20:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72570 X-GNU-PR-Package: emacs Original-Received: via spool by 72570-submit@debbugs.gnu.org id=B72570.172357918318043 (code B ref 72570); Tue, 13 Aug 2024 20:00:01 +0000 Original-Received: (at 72570) by debbugs.gnu.org; 13 Aug 2024 19:59:43 +0000 Original-Received: from localhost ([127.0.0.1]:45554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdxgE-0004gx-Hb for submit@debbugs.gnu.org; Tue, 13 Aug 2024 15:59:42 -0400 Original-Received: from mail.cs.ucla.edu ([131.179.128.66]:52854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdxgD-0004gX-2W for 72570@debbugs.gnu.org; Tue, 13 Aug 2024 15:59:41 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 3AF503C00FABA; Tue, 13 Aug 2024 12:59:01 -0700 (PDT) Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id ZhmVUZlVv32O; Tue, 13 Aug 2024 12:59:00 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D52F43C00D400; Tue, 13 Aug 2024 12:59:00 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu D52F43C00D400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1723579140; bh=bUwerpxy3b2OVw/nGme9441XvuS/SzvkbzqsPhTHqec=; h=Message-ID:Date:MIME-Version:To:From; b=UZ5e4IuDR8SAv5scDsIF0Zmc6ZvVN7yoAmHZas5GRTXpRD7JC8YH8xGWB7+lTBlv5 rCipkZ1ZYxpzmJ9Jx6sXdD8URZQZM5i09G6rYEybNuOdJLJUBiIpf0+lD0doiyxgby wmsutYgsjxzNMoRLHxlhtFMLhM/8DAeND7oAg0Z9axKtTBwef7/pkn6GGQ9oynS3Sn 9z5QNtGjj0T3S0fBr8HQgjQbmomVJuPfuLk3LiZG2kxZDKxqDNN2BhyEDM31uscoW2 xursUwuBnra4R9Fuklj8FNENBCBLahT1NguQC/QcEaXzoXFIPLHZEK4KA7zIQX4zd5 ijsT52PI8a1KA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id N28tYfG4zwO2; Tue, 13 Aug 2024 12:59:00 -0700 (PDT) Original-Received: from [192.168.254.12] (unknown [47.154.17.165]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 774653C00FABA; Tue, 13 Aug 2024 12:59:00 -0700 (PDT) Content-Language: en-US In-Reply-To: <86ikw4hdw2.fsf@gnu.org> 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:290089 Archived-At: On 2024-08-13 04:15, Eli Zaretskii wrote: > I'm okay with making the result of that change the de-facto > default, but then (a) we should document this change in NEWS including > the (trivial) way of getting back old behavior, and (b) make sure that > the new behavior happens even if the body of this condition-case in > date-to-time: > > (condition-case err > (let ((parsed (parse-time-string date))) > (when (decoded-time-year parsed) > (decoded-time-set-defaults parsed)) > (encode-time parsed)) > > does not signal an error. That all sounds good, and I suggested something similar to Ulrich in the email I sent a few minutes ago. > Thanks, but that doesn't document what I found missing: the > interpretation of the missing time-zone information. Maybe you > consider it unnecessary to mention these defaults in the doc strings > of parse-time-string and iso8601-parse, but it is something I kept > asking myself when I tried to understand what does date-to-time do > when called without time-zone argument. It's not parse-time-string's job to interpret missing time zone info, so I'm not sure what its doc string should say about this, other than "nil represents missing info" (something the doc already says). What the abovementioned date-to-time code says is "Parse DATE. If you find a year, use reasonable defaults for other components. Then try to encode the result. This attempt to encode will fail if the year is missing, because encode-time fails when crucial time components are unknown. This heuristic defaults to local time when the string lacks time zone information because encode-time treats a nil time zone as local time." Would it help to add a comment to that effect, to the date-to-time code? > At the very least we should > say that without TZ information, these functions return nil as the > time zone/UTC offset The doc already says that ... > and that the interpretation of that nil is up to > the APIs that the program will call with these results. ... and feel free to add words to that effect, if you think it's still needed given the above comments. This issue isn't just about time zones, though: it's about every component. For example, the interpretation of a nil year is up to the caller (as shown in the code you quoted). > Also, it > would be good to document what will these functions do when the TZ > information _is_ supplied: will they still just parse the string into > numbers, or will they convert the date/time to UTC? They don't convert. They just parse. Feel free to add more doc along those lines.