From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#72570: 31.0.50; Regression in date-to-time Date: Tue, 13 Aug 2024 14:15:57 +0300 Message-ID: <86ikw4hdw2.fsf@gnu.org> References: <86zfpige7k.fsf@gnu.org> <892ebc72-1020-471a-bdcd-8e8da10d61dd@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7349"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ulm@gentoo.org, 72570@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 13 13:16:57 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 1sdpWK-0001j0-U6 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Aug 2024 13:16:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sdpVv-000825-DP; Tue, 13 Aug 2024 07:16:31 -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 1sdpVt-00081k-Pk for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 07:16:30 -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 1sdpVt-00089T-HB for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 07:16:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=on7R1ewanoP0+F08Kmgnkbf6jdIyeDstAyQYvRWVM2c=; b=HE+rDv6NsIH1ui4wdRp7BJnTRkt85RhHT7vVIn/zhKyAd/e6hz8zeQky7PVOLv2l68Hcs1wFmVvKhB25p3Nwlz+OskP+HSy3aHiADXFSFZDeqt5TQdWjg9QJk/E8htFRjfjxoUJs0+848KRLusNHA8B26zCr8KWpBxW6ldfHQwFoe8P4YaKUTSXDzPafjY/KwGn/TUq2DbST9pmmhmKi/adWH/IsOQE0BPvesWKxvFvbDi2ILhOFWZ+zt2EaMOb04MZ14Y8yy4JYB5Zxap48wvusb4+hhUd0fpQeo9T8GDQki37GfntPea6U+GwVzxDY273H8fL0JLH34CHCzQ+zzQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sdpWQ-0003BW-Gn for bug-gnu-emacs@gnu.org; Tue, 13 Aug 2024 07:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Aug 2024 11:17:02 +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.172354781012209 (code B ref 72570); Tue, 13 Aug 2024 11:17:02 +0000 Original-Received: (at 72570) by debbugs.gnu.org; 13 Aug 2024 11:16:50 +0000 Original-Received: from localhost ([127.0.0.1]:44523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdpWD-0003Aq-Er for submit@debbugs.gnu.org; Tue, 13 Aug 2024 07:16:49 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdpW8-0003AJ-VE for 72570@debbugs.gnu.org; Tue, 13 Aug 2024 07:16:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sdpVS-00088N-6R; Tue, 13 Aug 2024 07:16:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=on7R1ewanoP0+F08Kmgnkbf6jdIyeDstAyQYvRWVM2c=; b=MyZi4t/s7arj 1n79M/N6HyfWnTXD+A27ypErNslNNFvQiC2/awmo7zyChH28D8iM+N2Lw2718YYYtsNWNzSMMNCCR 1crpK3dNAgtoYga8+CkkUMJuixHI1W8XoP9D7yTT41TR0uz/QGjmCIs0VQ+ZJ2HwQy1GhOyY0X/Np jVKKnH3loHCU15/GpTXX2/8ETGNwe7esYVh/QVKXJuPTz3i7qTjqCy94HwLCETdTeo4CaxHwQbkKd 6OOMkeHQjazzc6mzUgWWzUYWX9Dy+qqm0sq7MwnMmg2j/P6X7r8pzWHYaSCGSfmoyOtk9uzgokPv5 jg7hirOqh9cMyjWcc9+BMA==; In-Reply-To: <892ebc72-1020-471a-bdcd-8e8da10d61dd@cs.ucla.edu> (message from Paul Eggert on Mon, 12 Aug 2024 15:03:46 -0700) 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:290071 Archived-At: > Date: Mon, 12 Aug 2024 15:03:46 -0700 > Cc: 72570@debbugs.gnu.org > From: Paul Eggert > > On 2024-08-12 04:42, Eli Zaretskii wrote: > > Paul, any suggestions? And can we please document the missing > > time-zone assumptions? > > Not sure what documentation is missing, but I went through the doc for > parse-time-string and iso8601-parse and found some room for improvement > and so installed the attached. 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. At the very least we should say that without TZ information, these functions return nil as the time zone/UTC offset, and that the interpretation of that nil is up to the APIs that the program will call with these results. 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? > As for the original issue, I tend to agree with Ulrich that date-to-time > should default to local time. This would need changes to both > documentation and to code. Ulrich mentioned the following potential > issue with this idea: > > > The problem is that > > timezone-make-date-arpa-standard would need an explicit timezone as its > > second argument, which we don't know. > > The code could use timezone-time-zone-from-absolute to infer a timezone. > timezone-fix-time already does this sort of thing. Admittedly getting > the details right could be a bit tricky, and there is no perfect > solution in this area (certainly timezone-fix-time is flawed). It might > be good enough, though. The change which affected behavior that triggered this discussion was done because evidently timezone-time-zone-from-absolute was deemed to be too slow, and therefore the authors of the change wanted to avoid it. 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.