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: Mon, 12 Aug 2024 14:42:07 +0300 Message-ID: <86zfpige7k.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13591"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72570@debbugs.gnu.org To: Ulrich Mueller , Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 12 13:44:59 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 1sdTTt-0003MC-NC for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Aug 2024 13:44:57 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sdTTW-0005rZ-E7; Mon, 12 Aug 2024 07:44:34 -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 1sdTTT-0005qs-6n for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2024 07:44:31 -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 1sdTTS-00079Q-Bm for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2024 07:44:30 -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=6zjKj8sY9pnaVSBoR92COYAcq3MVjZo+NzEqLbt/s9Y=; b=lzeNKSXEaAsHL5vkBHuQISfz+F26ttfzf6sLSZYE2dTr5PIeT0DEv+xZUtUmGK7/Lb5zVMGzWiIcbC7NowWE84cNFzlTwuxJf8Gug/t755QpYzmv4IybGZMDL2A5BPK9aey+sxzoFXLR1+ywTjt7X8FeifWzTVx4tI6T1WbWsPuHaSB1lR+z2H9Gb3R9O52q5jipTw6R7NcNx3p7Nig+QfB9gQXhVXioz291dF3xAA+aC+5el6tEQmJKBVk2GChObylUyBvXGZ8rzsHPVdgqmZql/v6CYigjDdwvYZ1ylmruQ7HUELWTXYCVkqAsp8jWNb5mTaTikZmd0qcEVQKxfA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sdTTx-0001N8-Vh for bug-gnu-emacs@gnu.org; Mon, 12 Aug 2024 07:45: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: Mon, 12 Aug 2024 11:45: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.17234631015258 (code B ref 72570); Mon, 12 Aug 2024 11:45:01 +0000 Original-Received: (at 72570) by debbugs.gnu.org; 12 Aug 2024 11:45:01 +0000 Original-Received: from localhost ([127.0.0.1]:42540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdTTw-0001Mh-SO for submit@debbugs.gnu.org; Mon, 12 Aug 2024 07:45:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sdTTu-0001MM-3Y for 72570@debbugs.gnu.org; Mon, 12 Aug 2024 07:44:59 -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 1sdTRC-0006wd-0t; Mon, 12 Aug 2024 07:42:10 -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=6zjKj8sY9pnaVSBoR92COYAcq3MVjZo+NzEqLbt/s9Y=; b=fmJd338rI0Vi LZF9dGwklGgpQkgjMoHP3Tqt3fEpE1zaXF4o7n6+66fOMWWJ2Fkj9Cg0DYK7nfIVDYVdz9YLPHbdA UDCN6iL5VyGfdaxyBa11JgsIYKbPb7mMfvJiMIAmDPC2GHveJb/VyLntPZzSEpBIDIA2/+ku+7XtD boPFckI+64oIqArgmo8Ul/M83fxTGwdIOBja4zV1/WMna/qy+u1MvnMWXP7n7arrWw4Gm9k5ybx8x +9WK2l8p8zF+Dgo/5Dmdp+cQRMO1x+nQgK3kYZGv6Sm2IFcjWbfu7IKGrh5jWWg0ik8/HKkluNiN1 FA37OoXtDTozVNiUCtErDg==; In-Reply-To: (message from Ulrich Mueller on Sun, 11 Aug 2024 10:57:57 +0200) 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:290044 Archived-At: > From: Ulrich Mueller > Date: Sun, 11 Aug 2024 10:57:57 +0200 > > Function documentation of 'date-to-time' says: > "If DATE lacks timezone information, GMT is assumed." > > Also, the Lispref Manual: > "This function assumes Universal Time if STRING lacks explicit time zone > information, ..." > > (format-time-string > "%Y-%m-%d %H:%M:%S" (date-to-time "2024-01-01 00:00:00") t) > > returns "2023-12-31 23:00:00" as its result, while I would expect > "2024-01-01 00:00:00" with both conversions being in the same (UTC) > timezone. Apparently, date-to-time incorrectly uses the local timezone > (Europe/Berlin) instead of UTC. > > In Emacs 23.4 the function worked as expected. > > Git bisecting points to this commit: > > commit b069e5a697f37a06704136a8d5376b4d088658c8 (HEAD) > Author: Gnus developers > Date: Thu Sep 23 00:30:37 2010 +0000 > > Merge Changes made in Gnus trunk. > > [...] > time-date.el (date-to-time): Speed up date-to-time. > [...] That commit made this change in date-to-time: - (apply 'encode-time - (parse-time-string - ;; `parse-time-string' isn't sufficiently general or - ;; robust. It fails to grok some of the formats that - ;; timezone does (e.g. dodgy post-2000 stuff from some - ;; Elms) and either fails or returns bogus values. Lars - ;; reverted this change, but that loses non-trivially - ;; often for me. -- fx - (timezone-make-date-arpa-standard date))) - (error (error "Invalid date: %s" date)))) + (apply 'encode-time (parse-time-string date)) + (error (condition-case () + (apply 'encode-time + (parse-time-string + (timezone-make-date-arpa-standard date))) + (error (error "Invalid date: %s" date)))))) IOW, it applied parse-time-string to the argument DATE instead of first running it through timezone-make-date-arpa-standard. But that is not necessarily incorrect, because several time-conversion functions, including those involved in this issue, don't document their assumptions about time-zone when it is omitted. This includes parse-time-string and iso8601-parse. Since these functions don't document this aspect, and the code involved in the above snippet is quite convoluted, it is hard for me to decide which part of what function needs to be fixed. Paul, any suggestions? And can we please document the missing time-zone assumptions?