GNU logs - #52209, boring messages


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 30 Nov 2021 21:49:02 +0000
Resent-Message-ID: <handler.52209.B.163830888831073 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 52209 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.163830888831073
          (code B ref -1); Tue, 30 Nov 2021 21:49:02 +0000
Received: (at submit) by debbugs.gnu.org; 30 Nov 2021 21:48:08 +0000
Received: from localhost ([127.0.0.1]:42725 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1msAyt-000857-HY
	for submit <at> debbugs.gnu.org; Tue, 30 Nov 2021 16:48:08 -0500
Received: from lists.gnu.org ([209.51.188.17]:58794)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1msAAI-0006h8-In
 for submit <at> debbugs.gnu.org; Tue, 30 Nov 2021 15:55:50 -0500
Received: from eggs.gnu.org ([209.51.188.92]:37666)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <rogers-emacs@HIDDEN>)
 id 1msAAI-0004zo-BM
 for bug-gnu-emacs@HIDDEN; Tue, 30 Nov 2021 15:55:50 -0500
Received: from li126-47.members.linode.com ([69.164.211.47]:38800
 helo=rgrjr.com) by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <rogers-emacs@HIDDEN>) id 1msAAF-0000Uu-JD
 for bug-gnu-emacs@HIDDEN; Tue, 30 Nov 2021 15:55:49 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 833871D6BB2
 for <bug-gnu-emacs@HIDDEN>; Tue, 30 Nov 2021 20:55:59 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 504B85FE4A; 
 Tue, 30 Nov 2021 15:55:45 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="rN9WCOecwd"
Content-Transfer-Encoding: 7bit
Message-ID: <24998.36813.449798.684270@HIDDEN>
Date: Tue, 30 Nov 2021 15:55:41 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
X-Mailer: VM 7.19 under Emacs 28.0.60
Received-SPF: none client-ip=69.164.211.47;
 envelope-from=rogers-emacs@HIDDEN; helo=rgrjr.com
X-Spam_score_int: -14
X-Spam_score: -1.5
X-Spam_bar: -
X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398,
 SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -2.3 (--)
X-Mailman-Approved-At: Tue, 30 Nov 2021 16:48:06 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)


--rN9WCOecwd
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   In the emacs-28 branch at 0dd3883def:

   Imagine my surprise when evaluating

	(days-between "2021-10-22" "2020-09-29")

returned zero.  The root cause is that passing any date string without a
time to date-to-time produces the same return value:

	(date-to-time "2021-10-22") => (14445 17280)
	(date-to-time "2020-09-29") => (14445 17280)

But:

	(date-to-time "2020-09-29 23:15") => (24435 63540)

There are really two bugs here (or maybe three, depending on how you
look at it):

   1.  If parsing throws an error that is not an overflow, it passes the
date through timezone-make-date-arpa-standard to try to fix some cases
that parse-time-string can't handle.  But the condition-case is also
wrapped around the encode-time call, which gets a wrong-type-argument
error when it sees nil time values for HH:MM, so the fallback gets used
for something other than a parsing error.

   2.  When timezone-make-date-arpa-standard gets something it can't
handle, it "canonicalizes" the value to "31 Dec 1999 19:00:00 -0500",
which is the source of the constant result.  That may be worth another
bug report, but I'm not sure of its charter; maybe that's correct
behavior in context.

   The attached patch adds decoded-time-set-defaults, moves that and the
encode-time call outside the condition-case, and disables the fallback
to timezone-make-date-arpa-standard if the date appears not to have a
time value.  And I can now tell you there are 388 days between
2020-09-29 and 2021-10-22.

					-- Bob Rogers
					   http://www.rgrjr.com/


--rN9WCOecwd
Content-Type: text/x-patch
Content-Description: 
Content-Disposition: inline;
	filename="rgr-date-to-time-fix.patch"
Content-Transfer-Encoding: 7bit

diff --git a/lisp/calendar/time-date.el b/lisp/calendar/time-date.el
index 155c34927f..6407138953 100644
--- a/lisp/calendar/time-date.el
+++ b/lisp/calendar/time-date.el
@@ -153,19 +153,25 @@ date-to-time
   "Parse a string DATE that represents a date-time and return a time value.
 DATE should be in one of the forms recognized by `parse-time-string'.
 If DATE lacks timezone information, GMT is assumed."
-  (condition-case err
-      (encode-time (parse-time-string date))
-    (error
-     (let ((overflow-error '(error "Specified time is not representable")))
-       (if (equal err overflow-error)
-	   (signal (car err) (cdr err))
-	 (condition-case err
-	     (encode-time (parse-time-string
-			   (timezone-make-date-arpa-standard date)))
-	   (error
-	    (if (equal err overflow-error)
-		(signal (car err) (cdr err))
-	      (error "Invalid date: %s" date)))))))))
+  ;; Pass the result of parsing through decoded-time-set-defaults
+  ;; because encode-time signals if HH:MM:SS are not filled in.
+  (encode-time
+    (decoded-time-set-defaults
+      (condition-case err
+          (parse-time-string date)
+        (error
+         (let ((overflow-error '(error "Specified time is not representable")))
+           (if (or (equal err overflow-error)
+                   ;; timezone-make-date-arpa-standard misbehaves if
+                   ;; not given at least HH:MM as part of the date.
+                   (not (string-match ":" date)))
+               (signal (car err) (cdr err))
+             (condition-case err
+                 (parse-time-string (timezone-make-date-arpa-standard date))
+               (error
+                (if (equal err overflow-error)
+                    (signal (car err) (cdr err))
+                  (error "Invalid date: %s" date)))))))))))
 
 ;;;###autoload
 (defalias 'time-to-seconds 'float-time)

--rN9WCOecwd--




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Bob Rogers <rogers-emacs@HIDDEN>
Subject: bug#52209: Acknowledgement (28.0.60; [PATCH] date-to-time fails
 on pure dates)
Message-ID: <handler.52209.B.163830888831073.ack <at> debbugs.gnu.org>
References: <24998.36813.449798.684270@HIDDEN>
X-Gnu-PR-Message: ack 52209
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 52209 <at> debbugs.gnu.org
Date: Tue, 30 Nov 2021 21:49:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 52209 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
52209: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D52209
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 01 Dec 2021 04:18:01 +0000
Resent-Message-ID: <handler.52209.B52209.163833226221377 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.163833226221377
          (code B ref 52209); Wed, 01 Dec 2021 04:18:01 +0000
Received: (at 52209) by debbugs.gnu.org; 1 Dec 2021 04:17:42 +0000
Received: from localhost ([127.0.0.1]:42941 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1msH3u-0005YZ-1J
	for submit <at> debbugs.gnu.org; Tue, 30 Nov 2021 23:17:42 -0500
Received: from quimby.gnus.org ([95.216.78.240]:48726)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1msH3t-0005Ub-3u
 for 52209 <at> debbugs.gnu.org; Tue, 30 Nov 2021 23:17:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=KJMTxdGMrCwMb+UjlM2vvv50wb3Mbf70i/anPrd07ms=; b=q2Foim9xKHphDiCR4kkvXgszjQ
 8wbpySuP5L9QV67w1ye42WlpXc6mdMvbH/KZofpOOng8ETVShDflIk8rbvRVdkXqv5jc+wzBa7k4G
 aowRK3P5fivtXpWcVzI2FLTL6ZJCTmzyvUZJYjZrSo+jMYPZ404w6erEhnPkJ1Z9QHaM=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1msH3k-000436-CQ; Wed, 01 Dec 2021 05:17:34 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <24998.36813.449798.684270@HIDDEN>
X-Now-Playing: Streifenjunko's _Like Driving_: "Like Driving"
Date: Wed, 01 Dec 2021 05:17:30 +0100
In-Reply-To: <24998.36813.449798.684270@HIDDEN> (Bob Rogers's message
 of "Tue, 30 Nov 2021 15:55:41 -0500")
Message-ID: <87fsrdarhh.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Bob Rogers <rogers-emacs@HIDDEN> writes: > In the
 emacs-28 branch at 0dd3883def: > > Imagine my surprise when evaluating >
 > (days-between "2021-10-22" "2020-09-29") > > returned zero. Thanks, applied
 to Emacs 29. 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

>    In the emacs-28 branch at 0dd3883def:
>
>    Imagine my surprise when evaluating
>
> 	(days-between "2021-10-22" "2020-09-29")
>
> returned zero.

Thanks, applied to Emacs 29.

(These functions were never really intended to support parsing dates
like that -- only strict RFC822 date strings were originally supported,
but it's become more DWIM as time has passed.  Especially since it
wasn't explicitly stated anywhere that time-date.el was an RFC822
library.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message received at control <at> debbugs.gnu.org:


Received: (at control) by debbugs.gnu.org; 1 Dec 2021 04:17:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 30 23:17:48 2021
Received: from localhost ([127.0.0.1]:42944 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1msH40-0005cm-8x
	for submit <at> debbugs.gnu.org; Tue, 30 Nov 2021 23:17:48 -0500
Received: from quimby.gnus.org ([95.216.78.240]:48740)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1msH3z-0005Yg-DD
 for control <at> debbugs.gnu.org; Tue, 30 Nov 2021 23:17:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=JI1mleIxWA49ts2C3pmleGP0GV8UsLAT+GIchMbEQ68=; b=fjAy/oqLsBbV+SBO7dieeituEE
 Dz1TWSdGlGLvf0HtBwZuqoiafElF9/VOwKv5eZmLbwJFRURjYDMBvocWp4iGi+/kd5M1XsGTf/iNc
 6WI2YNArEdCfSMITs8nZXeC30d88lvgA9Q0UvJRuMsC+ahajWMSDrAUDLToUHPbMRtmQ=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1msH3r-00043E-Gu
 for control <at> debbugs.gnu.org; Wed, 01 Dec 2021 05:17:41 +0100
Date: Wed, 01 Dec 2021 05:17:39 +0100
Message-Id: <87ee6xarh8.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: control message for bug #52209
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  close 52209 29.1 quit 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

close 52209 29.1
quit





Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
In-Reply-To: <24998.36813.449798.684270@HIDDEN>
Resent-From: Katsumi Yamaoka <yamaoka@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Dec 2021 05:20:02 +0000
Resent-Message-ID: <handler.52209.B52209.163850878431168 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Bob Rogers <rogers-emacs@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.163850878431168
          (code B ref 52209); Fri, 03 Dec 2021 05:20:02 +0000
Received: (at 52209) by debbugs.gnu.org; 3 Dec 2021 05:19:44 +0000
Received: from localhost ([127.0.0.1]:49877 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mt0z2-00086e-0b
	for submit <at> debbugs.gnu.org; Fri, 03 Dec 2021 00:19:44 -0500
Received: from donkey.elm.relay.mailchannels.net ([23.83.212.49]:50549)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yamaoka@HIDDEN>) id 1mt0yz-00086V-Qm
 for 52209 <at> debbugs.gnu.org; Fri, 03 Dec 2021 00:19:42 -0500
X-Sender-Id: tih5qno0ow|x-authuser|yamaoka@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
 by relay.mailchannels.net (Postfix) with ESMTP id 89DB2321788;
 Fri,  3 Dec 2021 05:19:40 +0000 (UTC)
Received: from cloud1.hostforweb.net (unknown [127.0.0.6])
 (Authenticated sender: tih5qno0ow)
 by relay.mailchannels.net (Postfix) with ESMTPA id 7479B320A4F;
 Fri,  3 Dec 2021 05:19:39 +0000 (UTC)
X-Sender-Id: tih5qno0ow|x-authuser|yamaoka@HIDDEN
Received: from cloud1.hostforweb.net (cloud1.hostforweb.net [154.16.119.57])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384)
 by 100.116.149.8 (trex/6.4.3); Fri, 03 Dec 2021 05:19:40 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: tih5qno0ow|x-authuser|yamaoka@HIDDEN
X-MailChannels-Auth-Id: tih5qno0ow
X-Drop-Army: 22508d92554a8510_1638508780177_2097285272
X-MC-Loop-Signature: 1638508780177:4116085761
X-MC-Ingress-Time: 1638508780176
Received: from 157-205-200-190.cns.tayoreru.com ([157.205.200.190]:57978
 helo=localhost) by cloud1.hostforweb.net with esmtpsa (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)
 (envelope-from <yamaoka@HIDDEN>)
 id 1mt0yy-00FAw9-9F; Fri, 03 Dec 2021 00:19:38 -0500
Date: Fri, 03 Dec 2021 14:19:33 +0900
Message-ID: <b4my252feoq.fsf@HIDDEN>
From: Katsumi Yamaoka <yamaoka@HIDDEN>
References: <24998.36813.449798.684270@HIDDEN>
 <87fsrdarhh.fsf@HIDDEN>
Organization: Emacsen advocacy group
X-Face: #kKnN,xUnmKia.'[pp`;
 Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk
 B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu; B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw=
 L&i*6&(
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-cygwin)
Cancel-Lock: sha1:rRD2R0pta+k+FKJo/7325GDJBW8=
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-AuthUser: yamaoka@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=

On Wed, 01 Dec 2021 05:17:30 +0100, Lars Ingebrigtsen wrote:
> Bob Rogers <rogers-emacs@HIDDEN> writes:
>>    In the emacs-28 branch at 0dd3883def:
>>    Imagine my surprise when evaluating
>> 	(days-between "2021-10-22" "2020-09-29")
>> returned zero.

> Thanks, applied to Emacs 29.

This change caused another regression.  Please try:

(current-time-string (date-to-time "Fri, 03-Dec-2021 04:59:52 GMT"))

The function needs to test if `parse-time-string' returns a valid
data as the old version did it with the help of `encode-time'.
A patch is below (where why I do `(setq time ...)' is to silence
the byte compiler).

Thanks.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline

--- time-date.el~	2021-12-01 22:24:35.006052000 +0000
+++ time-date.el	2021-12-03 05:13:22.832443900 +0000
@@ -158,7 +158,10 @@
   (encode-time
     (decoded-time-set-defaults
       (condition-case err
-          (parse-time-string date)
+          (let ((time (parse-time-string date)))
+            (prog1 time
+              ;; Cause an error if data `parse-time-string' returns is invalid.
+              (setq time (encode-time time))))
         (error
          (let ((overflow-error '(error "Specified time is not representable")))
            (if (or (equal err overflow-error)

--=-=-=--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Dec 2021 16:30:02 +0000
Resent-Message-ID: <handler.52209.B52209.163854896016987 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Katsumi Yamaoka <yamaoka@HIDDEN>
Cc: Bob Rogers <rogers-emacs@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.163854896016987
          (code B ref 52209); Fri, 03 Dec 2021 16:30:02 +0000
Received: (at 52209) by debbugs.gnu.org; 3 Dec 2021 16:29:20 +0000
Received: from localhost ([127.0.0.1]:52099 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mtBR2-0004Pv-7M
	for submit <at> debbugs.gnu.org; Fri, 03 Dec 2021 11:29:20 -0500
Received: from quimby.gnus.org ([95.216.78.240]:54142)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1mtBQx-0004Pb-1Y
 for 52209 <at> debbugs.gnu.org; Fri, 03 Dec 2021 11:29:18 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=MIo9Fai/QUDVnnieCnUu1ZU2dLY+N9lXlC6BfpTrhDM=; b=c/g7eu81r+EMGC+TljT6vDfl2k
 kbbcmgVHKnodA7+AXlavYdJg6FCCyQmw95dZm9DSkubpd04Ruj/d2+YAqgv9HGxFVBol8z/2bN7k+
 oKjmUfECkZDS/qQsxml51lSRK5rVjUgWd2EtEvQZe4u0IiMU7I89UL99fPEKn6xwa96g=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1mtBQm-0004Ut-Ou; Fri, 03 Dec 2021 17:29:07 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <24998.36813.449798.684270@HIDDEN>
 <87fsrdarhh.fsf@HIDDEN> <b4my252feoq.fsf@HIDDEN>
X-Now-Playing: Joni Mitchell's _Clouds_: "Chelsea Morning"
Date: Fri, 03 Dec 2021 17:29:04 +0100
In-Reply-To: <b4my252feoq.fsf@HIDDEN> (Katsumi Yamaoka's message of "Fri, 03
 Dec 2021 14:19:33 +0900")
Message-ID: <87czmdwt2n.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Katsumi Yamaoka <yamaoka@HIDDEN> writes: > The function
 needs
 to test if `parse-time-string' returns a valid > data as the old version
 did it with the help of `encode-time'. > A patch is below (where why I do
 `(setq time ...)' is to silence [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Katsumi Yamaoka <yamaoka@HIDDEN> writes:

> The function needs to test if `parse-time-string' returns a valid
> data as the old version did it with the help of `encode-time'.
> A patch is below (where why I do `(setq time ...)' is to silence
> the byte compiler).

Thanks; applied to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Michael Heerdegen <michael_heerdegen@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 Dec 2021 18:39:01 +0000
Resent-Message-ID: <handler.52209.B52209.163855670831433 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Katsumi Yamaoka <yamaoka@HIDDEN>
Cc: Bob Rogers <rogers-emacs@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.163855670831433
          (code B ref 52209); Fri, 03 Dec 2021 18:39:01 +0000
Received: (at 52209) by debbugs.gnu.org; 3 Dec 2021 18:38:28 +0000
Received: from localhost ([127.0.0.1]:52216 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mtDS0-0008Au-FY
	for submit <at> debbugs.gnu.org; Fri, 03 Dec 2021 13:38:28 -0500
Received: from mout.web.de ([212.227.15.3]:33179)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <michael_heerdegen@HIDDEN>) id 1mtDRx-0008Ai-QX
 for 52209 <at> debbugs.gnu.org; Fri, 03 Dec 2021 13:38:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de;
 s=dbaedf251592; t=1638556698;
 bh=pS5YSFHND0EPQ4iOYGJcJ//c56dm3stlczlXcLFuKwc=;
 h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To;
 b=rz59+UV0H63ZhfG6doHq85zvqjTYoUjpU44Wr6zhjdvKD87W93A8btJGdOYidbJ5m
 61tyMKlVnXPVLyLCDviATcSZKHhsVt+auFD1XC0bDtA+Ueiwy53fDAFYVKJGocSLYZ
 OkxlEaRVzqBgY/pICkBAe0myTppnBtb6BmwP5t50=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from drachen.dragon ([92.208.225.87]) by smtp.web.de (mrweb005
 [213.165.67.108]) with ESMTPSA (Nemesis) id 1My6pf-1mejh83MuF-00zLxz; Fri, 03
 Dec 2021 19:38:17 +0100
From: Michael Heerdegen <michael_heerdegen@HIDDEN>
References: <24998.36813.449798.684270@HIDDEN>
 <87fsrdarhh.fsf@HIDDEN> <b4my252feoq.fsf@HIDDEN>
Date: Fri, 03 Dec 2021 19:38:16 +0100
In-Reply-To: <b4my252feoq.fsf@HIDDEN> (Katsumi Yamaoka's message of "Fri, 03
 Dec 2021 14:19:33 +0900")
Message-ID: <871r2to7on.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:5aQP2Yjvi5KKzLQ7ZZc9Z5wEU4FvWX0Sc74Ex/jCkU2cP4qOYD8
 2VcuPuIJxIuYAHC2hMgHzPcPz7pS5JASdvJha2llYL/Dw8h8S/xY2MnWx66+f2ViKRu9e2O
 z6qtCD30wLPByIUdQ9O5SdSqNld0o16QtkvfwxYaqqXG8iXAB/4lZjav9wLjxu7Hu36/M8i
 zr/tL6APj8W231S/Rk4Eg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:/+sRmbAQmdg=:URe99ZVp69dTrGG+RNs2be
 kysJ/bSCLjFNHWg6V3lPYlIUnhrcpHD8o9xtrTtC0p5R2r20M9Q7YjkP9aoeRtI1vSAC0l7fJ
 d9XChahb+ZBhDIVgYkadEvaNShvtmqjoF5128/Wx2Gd0sTR+Mq/kaINmGQX9k+AlOfBOtW7m8
 TyIuMFEYGdu337l3Y/I4Pjqq8w9W+lmmPBoN1I0I7QGMSlL/pB+b72VoWhCAmz5OSvMJOtqz8
 DB1eU+ZWSY0Kc8FVXK02/njzNrP4akYTDKk+faaiNH/AyrNabRT9bNFJ+i7Z7YxnK3KNnIZwp
 mA1wrtXIJicaE6D/tedotcD1OgKUen9Xp6oqqqs+A8Hr63wWvbaU6rlu2vgwR04eKrnY4Hl8P
 Q+ho0iHLCguKZlaiko+0C/ZTVQ5OP+2+ZSBToWE9K0y+sBb7fBjPmCsMyMG0FelQFoh2SF/GV
 BjURPqLcIgfqhTXYkfkeGiFDpvLhMj03crwP+kpz16dCu3pZ0TjnBH2OfDa5tdusG6yhyO0Yz
 uI9E6skWmkYz6RaAyCEv/qJgggBc7ox8626daQmLdc+PyR5Zk57m7piRvCz1T9r89PRjvlL1N
 YVBE9iz0XCsRcYYjiBAcSGMKMptbDsohJ9D1kLsrYsl6VR7Zt69dUe7kgNn1aaM07Iv033PEt
 i8TUkQ944NA81ZgDHRy8MdRBJspQ8skAgtVOYHGXhVx/6tpJW+i0hLZX7XWu5AHqawhqf7GIZ
 w3nsLP5ElNLee7f8sk48nKZx28nsmVpyvyTYhNCHjQd+WHf3I52hrJdpkk5bHhym+S6TTw2c1
 bA+L8ktBkoK7QNptIi1OHLeZ9dsaUCVnqDhcn8MQFDTxFZCPlBPJzSSQ7ZAvJPrXXcxY7E017
 +w5VbeUEVB696Cmrmbi9fVZrBIKZOlhIsxcCPXiLfvIOTOg1fJOCGsMivil+TqwEpVDMZFSeS
 hUjOLhIxrl9RGW4ss1KMaNxwWBenLI3J7E7RPv9bAQg1KzzAbWS9KmeTijuxyqRyw8NETRN/+
 WTBFWFmGPp7EBP7s/phdSfa2klGBmhBi5Tov9ZhjFb1EzsONqorwexBP2TY+9tqfkGwmYcehp
 wLDLVW4uS/8R0s=
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Katsumi Yamaoka <yamaoka@HIDDEN> writes:

> A patch is below (where why I do `(setq time ...)' is to silence
> the byte compiler).

AFAIU: `ignore' is the solution we choose most of the time for such
cases, it makes a bit clearer what happens.

Michael.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
References: <24998.36813.449798.684270@HIDDEN>
In-Reply-To: <24998.36813.449798.684270@HIDDEN>
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 04 Dec 2021 18:59:01 +0000
Resent-Message-ID: <handler.52209.B52209.16386443307937 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Bob Rogers <rogers-emacs@HIDDEN>, Katsumi Yamaoka <yamaoka@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16386443307937
          (code B ref 52209); Sat, 04 Dec 2021 18:59:01 +0000
Received: (at 52209) by debbugs.gnu.org; 4 Dec 2021 18:58:50 +0000
Received: from localhost ([127.0.0.1]:54936 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mtaFF-00023x-U3
	for submit <at> debbugs.gnu.org; Sat, 04 Dec 2021 13:58:50 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:45360)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1mtaFC-00023h-H9
 for 52209 <at> debbugs.gnu.org; Sat, 04 Dec 2021 13:58:48 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 05B55160108;
 Sat,  4 Dec 2021 10:58:40 -0800 (PST)
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 CD_X5_gmvA21; Sat,  4 Dec 2021 10:58:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 92651160107;
 Sat,  4 Dec 2021 10:58:38 -0800 (PST)
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 0IPXiTrn6wRH; Sat,  4 Dec 2021 10:58:38 -0800 (PST)
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 5C0E6160106;
 Sat,  4 Dec 2021 10:58:38 -0800 (PST)
Content-Type: multipart/mixed; boundary="------------EKJu01G3R0StBJ9IYEUQj3R5"
Message-ID: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
Date: Sat, 4 Dec 2021 10:58:37 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Content-Language: en-US
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
X-Spam-Score: -1.1 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

This is a multi-part message in MIME format.
--------------EKJu01G3R0StBJ9IYEUQj3R5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Unfortunately the latest change to time-date.el reintroduced Bug#52209. 
I installed the attached patch to fix this, and to add some test cases 
mentioned in this bug report to help prevent the problem recurring. 
Also, this patch documents the new feature, and avoids 
overenthusiastically guessing the year to be 1970 when the date string 
lacks a year.

> (These functions were never really intended to support parsing dates
> like that -- only strict RFC822 date strings were originally supported,
> but it's become more DWIM as time has passed.

Yes, date-to-time has definitely ... evolved.

My understanding is that date-to-time's RFC822 parsing is present only 
for backward compatibility, and that we shouldn't attempt to enhance it 
(here, the enhancement would be pointless as the RFC822 parsing fills in 
the blanks anyway). So the patch I just installed adds the new feature 
only for the normal path taken, when not doing the RFC822 hack.


PS. Internet RFC 822 has been obsolete since 2001, and the Emacs code 
should be talking about RFC 5322 everywhere except when Emacs is 
explicitly supporting the obsolete standard instead of the current 
standard. And we should rename functions like rfc822-goto-eoh to 
rfc-email-goto-eoh, to help avoid confusion or further function 
renaming. But I digress....
--------------EKJu01G3R0StBJ9IYEUQj3R5
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-Fix-date-to-time-2021-12-04.patch"
Content-Disposition: attachment;
 filename="0001-Fix-date-to-time-2021-12-04.patch"
Content-Transfer-Encoding: base64

RnJvbSBjYjBmNGYwMGIzMjhhNTYxZTQ5NTM4YmJmMGY5MDA1MGVhYzFiYTIwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1
PgpEYXRlOiBTYXQsIDQgRGVjIDIwMjEgMTA6MzM6MzIgLTA4MDAKU3ViamVjdDogW1BBVENI
XSBGaXggKGRhdGUtdG8tdGltZSAiMjAyMS0xMi0wNCIpCgpUaGlzIHNob3VsZCBjb21wbGV0
ZSB0aGUgZml4IGZvciBCdWcjNTIyMDkuCiogbGlzcC9jYWxlbmRhci90aW1lLWRhdGUuZWwg
KGRhdGUtdG8tdGltZSk6IEFwcGx5CmRlY29kZWQtdGltZS1zZXQtZGVmYXVsdHMgb25seSB0
byB0aGUgb3V0cHV0IG9mIChwYXJzZS10aW1lLXN0cmluZwpkYXRlKSwgYW5kIG9ubHkgd2hl
biB0aGUgb3V0cHV0IGhhcyBhIHllYXIgKHRvIGF2b2lkIGNvbmZ1c2lvbgp3aGVuIGRhdGVz
IGxhY2sgeWVhcnMpLiAgVGhlcmUgaXMgbm8gcG9pbnQgYXBwbHlpbmcgaXQgYWZ0ZXIKdGlt
ZXpvbmUtbWFrZS1kYXRlLWFycGEtc3RhbmRhcmQgc2luY2UgdGhlIGxhdHRlciBmaWxscyBp
biBhbGwgdGhlCmJsYW5rcy4gIEFuZCB0aGUgZm9ybWVyIGNvZGUgbWlzdGFrZW5seSBjYWxs
ZWQgZW5jb2RlLXRpbWUgb24gYW4KYWxyZWFkeS1lbmNvZGVkIHRpbWUuICBUaGlzIGdvZXMg
YmFjayB0byB0aGUgY29kZSBhIGNvdXBsZSBvZiBkYXlzCmFnbywgZXhjZXB0IHdpdGggY2hh
bmdlZCBiZWhhdmlvciAodG8gZml4IEJ1ZyM1MjIwOSkgb25seSB3aGVuCnRpbWV6b25lLW1h
a2UtZGF0ZS1hcnBhLXN0YW5kYXJkIGlzIG5vdCBjYWxsZWQuCiogdGVzdC9saXNwL2NhbGVu
ZGFyL3RpbWUtZGF0ZS10ZXN0cy5lbCAodGVzdC1kYXRlLXRvLXRpbWUpCih0ZXN0LWRheXMt
YmV0d2Vlbik6IE5ldyB0ZXN0cy4KLS0tCiBkb2MvbGlzcHJlZi9vcy50ZXhpICAgICAgICAg
ICAgICAgICAgIHwgIDMgKystCiBldGMvTkVXUyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgIDQgKysrCiBsaXNwL2NhbGVuZGFyL3RpbWUtZGF0ZS5lbCAgICAgICAgICAgIHwg
MzggKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tCiB0ZXN0L2xpc3AvY2FsZW5kYXIvdGlt
ZS1kYXRlLXRlc3RzLmVsIHwgIDcgKysrKysKIDQgZmlsZXMgY2hhbmdlZCwgMjkgaW5zZXJ0
aW9ucygrKSwgMjMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZG9jL2xpc3ByZWYvb3Mu
dGV4aSBiL2RvYy9saXNwcmVmL29zLnRleGkKaW5kZXggZTQyMDY0NGNkOC4uYjRlZmM0NGIw
MyAxMDA2NDQKLS0tIGEvZG9jL2xpc3ByZWYvb3MudGV4aQorKysgYi9kb2MvbGlzcHJlZi9v
cy50ZXhpCkBAIC0xNzI0LDcgKzE3MjQsOCBAQCBUaW1lIFBhcnNpbmcKIGNvcnJlc3BvbmRp
bmcgTGlzcCB0aW1lc3RhbXAuICBUaGUgYXJndW1lbnQgQHZhcntzdHJpbmd9IHNob3VsZCBy
ZXByZXNlbnQKIGEgZGF0ZS10aW1lLCBhbmQgc2hvdWxkIGJlIGluIG9uZSBvZiB0aGUgZm9y
bXMgcmVjb2duaXplZCBieQogQGNvZGV7cGFyc2UtdGltZS1zdHJpbmd9IChzZWUgYmVsb3cp
LiAgVGhpcyBmdW5jdGlvbiBhc3N1bWVzIFVuaXZlcnNhbAotVGltZSBpZiBAdmFye3N0cmlu
Z30gbGFja3MgZXhwbGljaXQgdGltZSB6b25lIGluZm9ybWF0aW9uLgorVGltZSBpZiBAdmFy
e3N0cmluZ30gbGFja3MgZXhwbGljaXQgdGltZSB6b25lIGluZm9ybWF0aW9uLAorYW5kIGFz
c3VtZXMgZWFybGllc3QgdmFsdWVzIGlmIEB2YXJ7c3RyaW5nfSBsYWNrcyBtb250aCwgZGF5
LCBvciB0aW1lLgogVGhlIG9wZXJhdGluZyBzeXN0ZW0gbGltaXRzIHRoZSByYW5nZSBvZiB0
aW1lIGFuZCB6b25lIHZhbHVlcy4KIEBlbmQgZGVmdW4KIApkaWZmIC0tZ2l0IGEvZXRjL05F
V1MgYi9ldGMvTkVXUwppbmRleCBhYzE3ODdkN2Y4Li4yYjRlYWFmOGExIDEwMDY0NAotLS0g
YS9ldGMvTkVXUworKysgYi9ldGMvTkVXUwpAQCAtMTA4NCw2ICsxMDg0LDEwIEBAIGNvb2tp
ZXMgc2V0IGJ5IHdlYiBwYWdlcyBvbiBkaXNrLgogKiogTmV3IHZhcmlhYmxlICdoZWxwLWJ1
ZmZlci11bmRlci1wcmVwYXJhdGlvbicuCiBUaGlzIHZhcmlhYmxlIGlzIGJvdW5kIHRvIHQg
ZHVyaW5nIHRoZSBwcmVwYXJhdGlvbiBvZiBhICIqSGVscCoiIGJ1ZmZlci4KIAorKysrCisq
KiAnZGF0ZS10by10aW1lJyBub3cgYXNzdW1lcyBlYXJsaWVzdCB2YWx1ZXMgaWYgaXRzIGFy
Z3VtZW50IGxhY2tzCittb250aCwgZGF5LCBvciB0aW1lLiAgRm9yIGV4YW1wbGUsIChkYXRl
LXRvLXRpbWUgIjIwMjEtMTItMDQiKSBub3cKK2Fzc3VtZXMgYSB0aW1lIG9mIDAwOjAwIGlu
c3RlYWQgb2Ygc2lnbmFsaW5nIGFuIGVycm9yLgogDAogKiBDaGFuZ2VzIGluIEVtYWNzIDI5
LjEgb24gTm9uLUZyZWUgT3BlcmF0aW5nIFN5c3RlbXMKIApkaWZmIC0tZ2l0IGEvbGlzcC9j
YWxlbmRhci90aW1lLWRhdGUuZWwgYi9saXNwL2NhbGVuZGFyL3RpbWUtZGF0ZS5lbAppbmRl
eCA4YTZlZTBmMjcwLi4zN2ExNmQzYjk4IDEwMDY0NAotLS0gYS9saXNwL2NhbGVuZGFyL3Rp
bWUtZGF0ZS5lbAorKysgYi9saXNwL2NhbGVuZGFyL3RpbWUtZGF0ZS5lbApAQCAtMTUzLDI4
ICsxNTMsMjIgQEAgZGF0ZS10by10aW1lCiAgICJQYXJzZSBhIHN0cmluZyBEQVRFIHRoYXQg
cmVwcmVzZW50cyBhIGRhdGUtdGltZSBhbmQgcmV0dXJuIGEgdGltZSB2YWx1ZS4KIERBVEUg
c2hvdWxkIGJlIGluIG9uZSBvZiB0aGUgZm9ybXMgcmVjb2duaXplZCBieSBgcGFyc2UtdGlt
ZS1zdHJpbmcnLgogSWYgREFURSBsYWNrcyB0aW1lem9uZSBpbmZvcm1hdGlvbiwgR01UIGlz
IGFzc3VtZWQuIgotICA7OyBQYXNzIHRoZSByZXN1bHQgb2YgcGFyc2luZyB0aHJvdWdoIGRl
Y29kZWQtdGltZS1zZXQtZGVmYXVsdHMKLSAgOzsgYmVjYXVzZSBlbmNvZGUtdGltZSBzaWdu
YWxzIGlmIEhIOk1NOlNTIGFyZSBub3QgZmlsbGVkIGluLgotICAoZW5jb2RlLXRpbWUKLSAg
ICAoZGVjb2RlZC10aW1lLXNldC1kZWZhdWx0cwotICAgICAgKGNvbmRpdGlvbi1jYXNlIGVy
cgotICAgICAgICAgIChsZXQgKCh0aW1lIChwYXJzZS10aW1lLXN0cmluZyBkYXRlKSkpCi0g
ICAgICAgICAgICAocHJvZzEgdGltZQotICAgICAgICAgICAgICA7OyBDYXVzZSBhbiBlcnJv
ciBpZiBkYXRhIGBwYXJzZS10aW1lLXN0cmluZycgcmV0dXJucyBpcyBpbnZhbGlkLgotICAg
ICAgICAgICAgICAoc2V0cSB0aW1lIChlbmNvZGUtdGltZSB0aW1lKSkpKQotICAgICAgICAo
ZXJyb3IKLSAgICAgICAgIChsZXQgKChvdmVyZmxvdy1lcnJvciAnKGVycm9yICJTcGVjaWZp
ZWQgdGltZSBpcyBub3QgcmVwcmVzZW50YWJsZSIpKSkKLSAgICAgICAgICAgKGlmIChvciAo
ZXF1YWwgZXJyIG92ZXJmbG93LWVycm9yKQotICAgICAgICAgICAgICAgICAgIDs7IHRpbWV6
b25lLW1ha2UtZGF0ZS1hcnBhLXN0YW5kYXJkIG1pc2JlaGF2ZXMgaWYKLSAgICAgICAgICAg
ICAgICAgICA7OyBub3QgZ2l2ZW4gYXQgbGVhc3QgSEg6TU0gYXMgcGFydCBvZiB0aGUgZGF0
ZS4KLSAgICAgICAgICAgICAgICAgICAobm90IChzdHJpbmctbWF0Y2ggIjoiIGRhdGUpKSkK
LSAgICAgICAgICAgICAgIChzaWduYWwgKGNhciBlcnIpIChjZHIgZXJyKSkKLSAgICAgICAg
ICAgICAoY29uZGl0aW9uLWNhc2UgZXJyCi0gICAgICAgICAgICAgICAgIChwYXJzZS10aW1l
LXN0cmluZyAodGltZXpvbmUtbWFrZS1kYXRlLWFycGEtc3RhbmRhcmQgZGF0ZSkpCi0gICAg
ICAgICAgICAgICAoZXJyb3IKLSAgICAgICAgICAgICAgICAoaWYgKGVxdWFsIGVyciBvdmVy
Zmxvdy1lcnJvcikKLSAgICAgICAgICAgICAgICAgICAgKHNpZ25hbCAoY2FyIGVycikgKGNk
ciBlcnIpKQotICAgICAgICAgICAgICAgICAgKGVycm9yICJJbnZhbGlkIGRhdGU6ICVzIiBk
YXRlKSkpKSkpKSkpKSkKKyAgKGNvbmRpdGlvbi1jYXNlIGVycgorICAgICAgKGxldCAoKHBh
cnNlZCAocGFyc2UtdGltZS1zdHJpbmcgZGF0ZSkpKQorCSh3aGVuIChkZWNvZGVkLXRpbWUt
eWVhciBwYXJzZWQpCisJICAoZGVjb2RlZC10aW1lLXNldC1kZWZhdWx0cyBwYXJzZWQpKQor
CShlbmNvZGUtdGltZSBwYXJzZWQpKQorICAgIChlcnJvcgorICAgICAobGV0ICgob3ZlcmZs
b3ctZXJyb3IgJyhlcnJvciAiU3BlY2lmaWVkIHRpbWUgaXMgbm90IHJlcHJlc2VudGFibGUi
KSkpCisgICAgICAgKGlmIChlcXVhbCBlcnIgb3ZlcmZsb3ctZXJyb3IpCisJICAgKHNpZ25h
bCAoY2FyIGVycikgKGNkciBlcnIpKQorCSAoY29uZGl0aW9uLWNhc2UgZXJyCisJICAgICAo
ZW5jb2RlLXRpbWUgKHBhcnNlLXRpbWUtc3RyaW5nCisJCQkgICAodGltZXpvbmUtbWFrZS1k
YXRlLWFycGEtc3RhbmRhcmQgZGF0ZSkpKQorCSAgIChlcnJvcgorCSAgICAoaWYgKGVxdWFs
IGVyciBvdmVyZmxvdy1lcnJvcikKKwkJKHNpZ25hbCAoY2FyIGVycikgKGNkciBlcnIpKQor
CSAgICAgIChlcnJvciAiSW52YWxpZCBkYXRlOiAlcyIgZGF0ZSkpKSkpKSkpKQogCiA7Ozsj
IyNhdXRvbG9hZAogKGRlZmFsaWFzICd0aW1lLXRvLXNlY29uZHMgJ2Zsb2F0LXRpbWUpCmRp
ZmYgLS1naXQgYS90ZXN0L2xpc3AvY2FsZW5kYXIvdGltZS1kYXRlLXRlc3RzLmVsIGIvdGVz
dC9saXNwL2NhbGVuZGFyL3RpbWUtZGF0ZS10ZXN0cy5lbAppbmRleCA0NTY4OTQ3YzBiLi5k
NTI2OTgwNGFkIDEwMDY0NAotLS0gYS90ZXN0L2xpc3AvY2FsZW5kYXIvdGltZS1kYXRlLXRl
c3RzLmVsCisrKyBiL3Rlc3QvbGlzcC9jYWxlbmRhci90aW1lLWRhdGUtdGVzdHMuZWwKQEAg
LTQxLDYgKzQxLDEzIEBAIHRlc3Qtb2Jzb2xldGUtZW5jb2RlLXRpbWUtdmFsdWUKICAgICAg
ICAgICAgICAgICAgICAoZW5jb2RlLXRpbWUtdmFsdWUgMSAyIDMgNCAzKSkKICAgICAgICAg
ICAgICAgICAgJygxIDIgMyA0KSkpKQogCisoZXJ0LWRlZnRlc3QgdGVzdC1kYXRlLXRvLXRp
bWUgKCkKKyAgKHNob3VsZCAoZXF1YWwgKGZvcm1hdC10aW1lLXN0cmluZyAiJUYgJVQiIChk
YXRlLXRvLXRpbWUgIjIwMjEtMTItMDQiKSkKKyAgICAgICAgICAgICAgICAgIjIwMjEtMTIt
MDQgMDA6MDA6MDAiKSkpCisKKyhlcnQtZGVmdGVzdCB0ZXN0LWRheXMtYmV0d2VlbiAoKQor
ICAoc2hvdWxkIChlcXVhbCAoZGF5cy1iZXR3ZWVuICIyMDIxLTEwLTIyIiAiMjAyMC0wOS0y
OSIpIDM4OCkpKQorCiAoZXJ0LWRlZnRlc3QgdGVzdC1sZWFwLXllYXIgKCkKICAgKHNob3Vs
ZC1ub3QgKGRhdGUtbGVhcC15ZWFyLXAgMTk5OSkpCiAgIChzaG91bGQtbm90IChkYXRlLWxl
YXAteWVhci1wIDE5MDApKQotLSAKMi4zMi4wCgo=
--------------EKJu01G3R0StBJ9IYEUQj3R5--





Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 19 Dec 2021 21:12:02 +0000
Resent-Message-ID: <handler.52209.B52209.163994829226545 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Paul Eggert <eggert@HIDDEN>,    Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Katsumi Yamaoka <yamaoka@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.163994829226545
          (code B ref 52209); Sun, 19 Dec 2021 21:12:02 +0000
Received: (at 52209) by debbugs.gnu.org; 19 Dec 2021 21:11:32 +0000
Received: from localhost ([127.0.0.1]:48345 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mz3St-0006u4-TL
	for submit <at> debbugs.gnu.org; Sun, 19 Dec 2021 16:11:32 -0500
Received: from rgrjr.com ([69.164.211.47]:36288)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1mz3Ss-0006tx-Fn
 for 52209 <at> debbugs.gnu.org; Sun, 19 Dec 2021 16:11:31 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 2C2B11D6BB2;
 Sun, 19 Dec 2021 21:11:43 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id AA9A25FE79; 
 Sun, 19 Dec 2021 16:11:29 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="JRqshbaEP8"
Content-Transfer-Encoding: 7bit
Message-ID: <25023.40959.627321.685762@HIDDEN>
Date: Sun, 19 Dec 2021 16:11:27 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)


--JRqshbaEP8
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   From: Paul Eggert <eggert@HIDDEN>
   Date: Sat, 4 Dec 2021 10:58:37 -0800

   Unfortunately the latest change to time-date.el reintroduced
   Bug#52209.  I installed the attached patch to fix this . . .

I'm sure none of you will be surprised to learn that parse-time-string
still doesn't recognize single-digit months or days, with the same
fallback-to-the-epoch behavior that threw me for a loop originally.

    (format-time-string "%F %T %z" (date-to-time "2022-1-12"))
	=> "1999-12-31 19:00:00 -0500"

And adding a time makes it work again because it seems that
timezone-make-date-arpa-standard does accept single-digit months and
days.  Go figure.

   The attached patch extends parse-time-string by using regexps instead
of string manipulation of fixed-width fields.  This could possibly break
interface compatibility, especially if you expect anyone to customize
parse-time-rules.  So I will not be surprised if you decline to adopt
it.

   > (These functions were never really intended to support parsing dates
   > like that -- only strict RFC822 date strings were originally supported,
   > but it's become more DWIM as time has passed.

   Yes, date-to-time has definitely ... evolved.

   My understanding is that date-to-time's RFC822 parsing is present
   only for backward compatibility, and that we shouldn't attempt to
   enhance it (here, the enhancement would be pointless as the RFC822
   parsing fills in the blanks anyway). So the patch I just installed
   adds the new feature only for the normal path taken, when not doing
   the RFC822 hack.

   PS. Internet RFC 822 has been obsolete since 2001, and the Emacs code
   should be talking about RFC 5322 everywhere except when Emacs is
   explicitly supporting the obsolete standard instead of the current
   standard. And we should rename functions like rfc822-goto-eoh to
   rfc-email-goto-eoh, to help avoid confusion or further function
   renaming. But I digress....

Since Emacs time functions have evolved well beyond email, I would argue
that even "rfc-email-" is too specific a prefix for them.  So if this
patch is not suitable, maybe it's (cough, cough) time for a new time and
date parsing API that supports a broader range of human-generated dates
and times, with better error handling and I18N support.  WDYT?

					-- Bob Rogers
					   http://www.rgrjr.com/


--JRqshbaEP8
Content-Type: text/x-patch
Content-Description: 
Content-Disposition: inline;
	filename="rgr-extend-parse-time.patch"
Content-Transfer-Encoding: 7bit

diff --git a/lisp/calendar/parse-time.el b/lisp/calendar/parse-time.el
index 5a3d2706af..4812dcbd1b 100644
--- a/lisp/calendar/parse-time.el
+++ b/lisp/calendar/parse-time.el
@@ -102,45 +102,25 @@ parse-time-rules
     ((3) (1 31))
     ((4) parse-time-months)
     ((5) (100))
-    ((2 1 0)
-     ,(lambda () (and (stringp parse-time-elt)
-                      (= (length parse-time-elt) 8)
-                      (= (aref parse-time-elt 2) ?:)
-                      (= (aref parse-time-elt 5) ?:)))
-     [0 2] [3 5] [6 8])
     ((8 7) parse-time-zoneinfo
      ,(lambda () (car parse-time-val))
      ,(lambda () (cadr parse-time-val)))
     ((8)
+     "^[-+][0-9][0-9][0-9][0-9]$"
      ,(lambda ()
-        (and (stringp parse-time-elt)
-             (= 5 (length parse-time-elt))
-             (or (= (aref parse-time-elt 0) ?+)
-                 (= (aref parse-time-elt 0) ?-))))
-     ,(lambda () (* 60 (+ (cl-parse-integer parse-time-elt :start 3 :end 5)
-                          (* 60 (cl-parse-integer parse-time-elt :start 1 :end 3)))
-                    (if (= (aref parse-time-elt 0) ?-) -1 1))))
+        (* 60
+           (+ (cl-parse-integer parse-time-elt :start 3 :end 5)
+              (* 60 (cl-parse-integer parse-time-elt :start 1 :end 3)))
+           (if (= (aref parse-time-elt 0) ?-) -1 1))))
     ((5 4 3)
-     ,(lambda () (and (stringp parse-time-elt)
-                      (= (length parse-time-elt) 10)
-                      (= (aref parse-time-elt 4) ?-)
-                      (= (aref parse-time-elt 7) ?-)))
-     [0 4] [5 7] [8 10])
-    ((2 1 0)
-     ,(lambda () (and (stringp parse-time-elt)
-                      (= (length parse-time-elt) 5)
-                      (= (aref parse-time-elt 2) ?:)))
-     [0 2] [3 5] ,(lambda () 0))
+     "^\\([0-9][0-9][0-9][0-9]\\)-\\([0-9][0-9]?\\)-\\([0-9][0-9]?\\)$"
+     1 2 3)
     ((2 1 0)
-     ,(lambda () (and (stringp parse-time-elt)
-                      (= (length parse-time-elt) 4)
-                      (= (aref parse-time-elt 1) ?:)))
-     [0 1] [2 4] ,(lambda () 0))
+     "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\)$"
+     1 2 ,(lambda () 0))
     ((2 1 0)
-     ,(lambda () (and (stringp parse-time-elt)
-                      (= (length parse-time-elt) 7)
-                      (= (aref parse-time-elt 1) ?:)))
-     [0 1] [2 4] [5 7])
+     "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\):\\([0-9][0-9]\\)$"
+     1 2 3)
     ((5) (50 110) ,(lambda () (+ 1900 parse-time-elt)))
     ((5) (0 49) ,(lambda () (+ 2000 parse-time-elt))))
   "(slots predicate extractor...)")
@@ -173,7 +153,11 @@ parse-time-string
 		    (parse-time-val))
 	       (when (and (not (nth (car slots) time)) ;not already set
 			  (setq parse-time-val
-				(cond ((and (consp predicate)
+				(cond ((stringp predicate)
+                                        (and (stringp parse-time-elt)
+                                             (string-match predicate
+                                                           parse-time-elt)))
+                                      ((and (consp predicate)
 					    (not (functionp predicate)))
 				       (and (numberp parse-time-elt)
 					    (<= (car predicate) parse-time-elt)
@@ -188,15 +172,15 @@ parse-time-string
 		 (setq exit t)
 		 (while slots
 		   (let ((new-val (if rule
-				      (let ((this (pop rule)))
-					(if (vectorp this)
-					    (cl-parse-integer
-					     parse-time-elt
-					     :start (aref this 0)
-					     :end (aref this 1))
-					  (funcall this)))
+				      (let* ((this (pop rule)))
+                                        (if (integerp this)
+                                            (cl-parse-integer
+                                              (match-string this parse-time-elt))
+                                          (funcall this)))
 				    parse-time-val)))
-		     (setf (nth (pop slots) time) new-val))))))))
+                     (setf (nth (pop slots) time) new-val))))))
+           (unless exit
+             (message "unrecognized token '%s'" parse-time-elt))))
        time))))
 
 (defun parse-iso8601-time-string (date-string)
diff --git a/test/lisp/calendar/parse-time-tests.el b/test/lisp/calendar/parse-time-tests.el
index b706b73570..63b696db1d 100644
--- a/test/lisp/calendar/parse-time-tests.el
+++ b/test/lisp/calendar/parse-time-tests.el
@@ -45,6 +45,36 @@ parse-time-tests
                  '(42 35 19 22 2 2016 1 nil -28800)))
   (should (equal (parse-time-string "Friday, 21 Sep 2018 13:47:58 PDT")
                  '(58 47 13 21 9 2018 5 t -25200)))
+  (should (equal (parse-time-string "Friday, 21 Sep 2018 13:47:58")
+                 '(58 47 13 21 9 2018 5 -1 nil)))
+  (should (equal (parse-time-string "Friday, 21 Sep 2018")
+                 '(nil nil nil 21 9 2018 5 -1 nil)))
+  ;; Date can be numeric if separated by hyphens.
+  (should (equal (parse-time-string "Friday, 2018-09-21")
+                 '(nil nil nil 21 9 2018 5 -1 nil)))
+  ;; Day of week is optional
+  (should (equal (parse-time-string "2018-09-21")
+                 '(nil nil nil 21 9 2018 nil -1 nil)))
+  ;; The order of date, time, etc., does not matter.
+  (should (equal (parse-time-string "13:47:58, +0100, 2018-09-21, Friday")
+                 '(58 47 13 21 9 2018 5 -1 3600)))
+  ;; Month, day, or both, can be a single digit.
+  (should (equal (parse-time-string "Friday, 2018-9-08")
+                 '(nil nil nil 8 9 2018 5 -1 nil)))
+  (should (equal (parse-time-string "Friday, 2018-09-8")
+                 '(nil nil nil 8 9 2018 5 -1 nil)))
+  (should (equal (parse-time-string "Friday, 2018-9-8")
+                 '(nil nil nil 8 9 2018 5 -1 nil)))
+  ;; Time by itself is recognized as such.
+  (should (equal (parse-time-string "03:47:58")
+                 '(58 47 3 nil nil nil nil -1 nil)))
+  ;; A leading zero for hours is optional.
+  (should (equal (parse-time-string "3:47:58")
+                 '(58 47 3 nil nil nil nil -1 nil)))
+  ;; Missing seconds are assumed to be zero.
+  (should (equal (parse-time-string "3:47")
+                 '(0 47 3 nil nil nil nil -1 nil)))
+
   (should (equal (format-time-string
 		  "%Y-%m-%d %H:%M:%S"
 		  (parse-iso8601-time-string "1998-09-12T12:21:54-0200") t)

--JRqshbaEP8--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 20 Dec 2021 15:58:02 +0000
Resent-Message-ID: <handler.52209.B52209.164001586116565 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Katsumi Yamaoka <yamaoka@HIDDEN>, Paul Eggert <eggert@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164001586116565
          (code B ref 52209); Mon, 20 Dec 2021 15:58:02 +0000
Received: (at 52209) by debbugs.gnu.org; 20 Dec 2021 15:57:41 +0000
Received: from localhost ([127.0.0.1]:51192 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mzL2i-0004J7-O1
	for submit <at> debbugs.gnu.org; Mon, 20 Dec 2021 10:57:40 -0500
Received: from rgrjr.com ([69.164.211.47]:36416)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1mzL2f-0004Ip-17
 for 52209 <at> debbugs.gnu.org; Mon, 20 Dec 2021 10:57:39 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id A59831D6BB2;
 Mon, 20 Dec 2021 15:57:48 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 595845FE4D; 
 Mon, 20 Dec 2021 10:57:35 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25024.42989.718735.680188@HIDDEN>
Date: Mon, 20 Dec 2021 10:57:33 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <875yrjpp03.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Mon, 20 Dec 2021 11:08:44 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > Since Emacs time functions have evolved well beyond email, I would argue
   > that even "rfc-email-" is too specific a prefix for them.  So if this
   > patch is not suitable, maybe it's (cough, cough) time for a new time and
   > date parsing API that supports a broader range of human-generated dates
   > and times, with better error handling and I18N support.  WDYT?

   Yes, I think we should stop futzing around with `parse-time-string' and
   instead create a new well-defined library with a signature like:

   (parse-time "2020-01-15T16:12:21-08:00" 'iso-8601)
   (parse-time "1/4-2" 'us-date)
   (parse-time "Wed, 15 Jan 2020 16:12:21 -0800" 'rfc822)

   etc.  (And yes, I know the latter is a superseded standard, but it's
   the one people know.)

I can see that it's a good idea to have an explicit hint that the date
is in rfc822 format since a two-digit year (which parse-time-string
still supports) might otherwise be misinterpreted as something else.
And perhaps two-digit years this far into the century should otherwise
be disallowed.

   Otherwise, I think the other date formats would be pretty easy to
recognize, with the exception of month-day order in numeric dates, which
ought to be possible to disambiguate via locale.  (Though I admit I have
no experience with locale programming.)

   On the other hand, I can imagine the caller might want to insist that
the passed string must be in a certain format and force an error if
parse-time finds otherwise.

   One question:  Did you have in mind that parse-time should have the
same return value as parse-time-string, in order to feed into the other
Emacs time functions?

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 20 Dec 2021 16:35:01 +0000
Resent-Message-ID: <handler.52209.B52209.164001807420702 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Katsumi Yamaoka <yamaoka@HIDDEN>, Paul Eggert <eggert@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164001807420702
          (code B ref 52209); Mon, 20 Dec 2021 16:35:01 +0000
Received: (at 52209) by debbugs.gnu.org; 20 Dec 2021 16:34:34 +0000
Received: from localhost ([127.0.0.1]:51239 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mzLcQ-0005Nq-Da
	for submit <at> debbugs.gnu.org; Mon, 20 Dec 2021 11:34:34 -0500
Received: from rgrjr.com ([69.164.211.47]:36432)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1mzLcN-0005Nh-An
 for 52209 <at> debbugs.gnu.org; Mon, 20 Dec 2021 11:34:33 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 594BB1D6BB2;
 Mon, 20 Dec 2021 16:34:42 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 011CB5FE4D; 
 Mon, 20 Dec 2021 11:34:29 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25024.45204.996103.451554@HIDDEN>
Date: Mon, 20 Dec 2021 11:34:28 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <25024.42989.718735.680188@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Bob Rogers <rogers-emacs@HIDDEN>
   Date: Mon, 20 Dec 2021 10:57:33 -0500

   . . . Otherwise, I think the other date formats would be pretty easy
   to recognize, with the exception of month-day order in numeric dates,
   which ought to be possible to disambiguate via locale.  (Though I
   admit I have no experience with locale programming.)

Never mind; through further reading I have realized that the current
locale has no necessary bearing on the locale of the date.  So I'm not
sure what's needed here.

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 21 Dec 2021 04:09:01 +0000
Resent-Message-ID: <handler.52209.B52209.16400597171719 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: Katsumi Yamaoka <yamaoka@HIDDEN>, Paul Eggert <eggert@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16400597171719
          (code B ref 52209); Tue, 21 Dec 2021 04:09:01 +0000
Received: (at 52209) by debbugs.gnu.org; 21 Dec 2021 04:08:37 +0000
Received: from localhost ([127.0.0.1]:51973 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mzWS4-0000Rf-Nw
	for submit <at> debbugs.gnu.org; Mon, 20 Dec 2021 23:08:36 -0500
Received: from quimby.gnus.org ([95.216.78.240]:60072)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1mzWS3-0000RQ-83
 for 52209 <at> debbugs.gnu.org; Mon, 20 Dec 2021 23:08:35 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Resent-Message-ID:Resent-Date:Resent-From:
 Resent-To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Sender:Resent-Cc:List-Id:List-Help:
 List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+ApLqOa6F7oGNtiWsl3IBAJzZAvRZPR7ilebpMjYeQw=; b=rK8uXkRb/ztWUpr8UOD3cE6hTY
 za8eErH2aHeG6PAS3BZndRhvayFdshhRWsjWUxgilk23Qy9gQZKGXuBVO9PIU2ZA5GBSVJwR0c/rN
 /eYVRO8uGxvL0b2UQMYDgwORMp/gg2OTLbM+Ie+n6Qrn5FPvQTRv0UagKiE80DcgVrOo=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1mzWRv-0002n8-1Z
 for 52209 <at> debbugs.gnu.org; Tue, 21 Dec 2021 05:08:29 +0100
Resent-X-Now-Playing: Heidi Berry's _Love_: "Gloria"
Resent-To: 52209 <at> debbugs.gnu.org
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Resent-Date: Tue, 21 Dec 2021 05:08:26 +0100
Resent-Message-ID: <87v8zilhvp.fsf@HIDDEN>
X-From-Line: nobody Mon Dec 20 11:08:48 2021
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAACVBMVEWOoVlMZDn///9k
 6/PIAAAAAWJLR0QCZgt8ZAAAAAd0SU1FB+UMFAkxCrmP2HsAAAFESURBVCjPRVFBDuQwCDNSuKdS
 +A+RmjuR4P9fWdMd7ebSOAZsXIBnYMx4+yaJwFCYF1xLHJgVFkBV34HFqvhAQJdpg5KA8N1gBLvu
 hChbiE7VADzZTxJKPpsi5lTJU2BJ1fW20c+ZJBKmG/1uFbRDvUFRspcjEl7q99btVpSr63cl6DW0
 fiBi/gf3vp/L5iGie44pY9LBddHRJw73L31YMrjsYAZ7TpGXlYKzG4BgDepsVfEnpy+cDorlPInn
 S7LjqPjikr+aDHH/qrT4fhw/N9zH//UUZt7AuxSHJcnUOhjoFrIJPQd4juEpH0+q49HLELGYVFXr
 VI6VztC6hy0fEebajE2qs06Qiz1ZVLj0PXzFsqAx/tNB49PcMKzLqMjkocYPg5DqZV6UTs4+QiOL
 FsM5zSlEvz73sAeRjEq5txqTnbA/cGxYvOKgEBwAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMTIt
 MjBUMDk6NDk6MTArMDA6MDDZqP18AAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTEyLTIwVDA5OjQ5
 OjEwKzAwOjAwqPVFwAAAAABJRU5ErkJggg==
X-Now-Playing: Forest's _Strange Folk_: "Fading Light"
Date: Mon, 20 Dec 2021 11:08:44 +0100
In-Reply-To: <25023.40959.627321.685762@HIDDEN> (Bob Rogers's message
 of "Sun, 19 Dec 2021 16:11:27 -0500")
Message-ID: <875yrjpp03.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Lines: 21
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Bob Rogers <rogers-emacs@HIDDEN> writes: > Since
 Emacs time functions have evolved well beyond email, I would argue > that
 even "rfc-email-" is too specific a prefix for them. So if this > patch is
 not suitable, maybe it's (cough, cough) tim [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> Since Emacs time functions have evolved well beyond email, I would argue
> that even "rfc-email-" is too specific a prefix for them.  So if this
> patch is not suitable, maybe it's (cough, cough) time for a new time and
> date parsing API that supports a broader range of human-generated dates
> and times, with better error handling and I18N support.  WDYT?

Yes, I think we should stop futzing around with `parse-time-string' and
instead create a new well-defined library with a signature like:

(parse-time "2020-01-15T16:12:21-08:00" 'iso-8601)
(parse-time "1/4-2" 'us-date)
(parse-time "Wed, 15 Jan 2020 16:12:21 -0800" 'rfc822)

etc.  (And yes, I know the latter is a superseded standard, but it's the
one people know.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 21 Dec 2021 11:02:02 +0000
Resent-Message-ID: <handler.52209.B52209.16400844829494 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: Katsumi Yamaoka <yamaoka@HIDDEN>, Paul Eggert <eggert@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16400844829494
          (code B ref 52209); Tue, 21 Dec 2021 11:02:02 +0000
Received: (at 52209) by debbugs.gnu.org; 21 Dec 2021 11:01:22 +0000
Received: from localhost ([127.0.0.1]:52513 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mzctW-0002Sl-AA
	for submit <at> debbugs.gnu.org; Tue, 21 Dec 2021 06:01:22 -0500
Received: from quimby.gnus.org ([95.216.78.240]:36446)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1mzctU-0002Lv-AR
 for 52209 <at> debbugs.gnu.org; Tue, 21 Dec 2021 06:01:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=tQBBr6Uiku8kvsaRpZpEEJYwhQypOVKlXkws7T/Ntao=; b=shsFMh5TnudAJgcHePnFpJisHw
 rNu+85cO8KztIIkNDVcG+PPUs5GDuIg48M1Jds95eDwD+64lyLlOyWnSJzcWHaYFOkgk6ovaAPWnv
 8L/iIxbtZNSTiWLuOZqiMlumGQbssW1g8gLEuxPkNkU6u1jy1EzUP5m27iSs9B/aZGis=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1mzctH-0005Z1-UX; Tue, 21 Dec 2021 12:01:10 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEVPcZAhOVFtjauf
 t87X5fD///9yaa3UAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UMFQoqG8Dz6i8AAAGdSURBVDjLbZTR
 ecMgDIQFzgDQdAAsMkCKPEFg/5l6EmDjflVeYn6fhA5hokAz4hrkAjHzPwDBFj79Bb4D7iCcqYjz
 DbipCCxlAZTcTMUiWBbZbcFLAdGtQiFSygSbSOp7UoVFB1mUkAfIKwj6r/RcE7iRyYD1IUfTJ2eC
 1uoK6gDfDYFdWg0vcoKjdSKC9ZQ72CM9bV2fDHAvssf0aidRb3024L5KO6OatwB4KW35Ao0SCIqA
 JDluAD8Dmu0GnDrad8mtvacKtd0EVbCr5wkyqo7XPgEeLKD4Ad7xedXAaRQaVfcVwBBJaERFP/Fx
 ATX3DR87OG5AqibUVGHpIwabEgXVPVYQsbHSAb1uwKaaFSR/AzoRrGdSU2BeAC6C70V0CLalRj9e
 gI8e+6ijF8d7PZF6dPCYfZDaZeMEb9ZUwWcZQHzMa4N9RhXkxZIT2JitfRDPqdZLcqyKeUFKstG3
 UzbFlDCjqSlHH56HRuciTDl1DzMPED1fYH4BAEyPe1/EvEqG8Oxo44woJSuA8X4Ad6rHJ8fSJXJx
 fHIS/wI1yLQaHchSrwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0xMi0yMVQxMDo0MjoyNyswMDow
 MN6SRekAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMTItMjFUMTA6NDI6MjcrMDA6MDCvz/1VAAAA
 AElFTkSuQmCC
X-Now-Playing: Laurie Freelove's _Songs From The Nineline_: "The Moon In Our
 Hearts"
Date: Tue, 21 Dec 2021 12:01:07 +0100
In-Reply-To: <25024.42989.718735.680188@HIDDEN> (Bob Rogers's message
 of "Mon, 20 Dec 2021 10:57:33 -0500")
Message-ID: <871r26i5n0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Bob Rogers <rogers-emacs@HIDDEN> writes: > On the
 other hand, I can imagine the caller might want to insist that > the passed
 string must be in a certain format and force an error if > parse-time finds
 otherwise. 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

>    On the other hand, I can imagine the caller might want to insist that
> the passed string must be in a certain format and force an error if
> parse-time finds otherwise.

Yup.  That's one good reason to not have a time parsing function guess
at formats, because the input data will be different.

In my previous job, we had a library to parse date/time strings, and I
think we were up to about 80 distinct formats to handle the different
data feeds we were getting.  For instance, "01 02 03" may be three
different dates depending on where you get the date from.

>    One question:  Did you have in mind that parse-time should have the
> same return value as parse-time-string, in order to feed into the other
> Emacs time functions?

Yes, I think so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 23 Dec 2021 19:49:01 +0000
Resent-Message-ID: <handler.52209.B52209.164028889118833 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164028889118833
          (code B ref 52209); Thu, 23 Dec 2021 19:49:01 +0000
Received: (at 52209) by debbugs.gnu.org; 23 Dec 2021 19:48:11 +0000
Received: from localhost ([127.0.0.1]:35020 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n0U4Q-0004tg-1t
	for submit <at> debbugs.gnu.org; Thu, 23 Dec 2021 14:48:11 -0500
Received: from rgrjr.com ([69.164.211.47]:37790)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n0U4N-0004tX-BR
 for 52209 <at> debbugs.gnu.org; Thu, 23 Dec 2021 14:48:08 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id C8A251D6BB2;
 Thu, 23 Dec 2021 19:48:19 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id BC3CD5FEB0; 
 Thu, 23 Dec 2021 14:48:06 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="gKQbAfc6jm"
Content-Transfer-Encoding: 7bit
Message-ID: <25028.53876.304365.706795@HIDDEN>
Date: Thu, 23 Dec 2021 14:48:04 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <871r26i5n0.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)


--gKQbAfc6jm
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Tue, 21 Dec 2021 12:01:07 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   >    On the other hand, I can imagine the caller might want to insist
   > that the passed string must be in a certain format and force an
   > error if parse-time finds otherwise.

   Yup.  That's one good reason to not have a time parsing function guess
   at formats, because the input data will be different.

OK, I have proceeded along those lines; WIP attached for feedback.  I
changed the name to "parse-date" to avoid confusion; I was otherwise
stuck when trying to come up with a sensible name for the test file,
since parse-time-tests.el was already taken (though I suppose I could
have added to the existing file).  The docstring of parse-date describes
the expected functionality as far as I've planned, with comments in
square brackets to note what's missing.

   In my previous job, we had a library to parse date/time strings, and I
   think we were up to about 80 distinct formats to handle the different
   data feeds we were getting.  For instance, "01 02 03" may be three
   different dates depending on where you get the date from.

Which (additional) formats would you like?  I'm assuming we need iso8601
and rfc822 for compatibility (in which case rfc2822 will be easy to
provide in addition), and us-date and euro-date to disambiguate the
month/day order.  Would the third format correspond to ISO 2001-01-03?
Do we want to support that?

   And come to think of it, I've been using DD-Mon-YY for my own
purposes for so long that I'm not even certain whether Americans use
MM-DD-YY or it's the other way around . . .

					-- Bob


--gKQbAfc6jm
Content-Type: text/x-patch
Content-Description: 
Content-Disposition: inline;
	filename="rgr-parse-date-211223.patch"
Content-Transfer-Encoding: 7bit

diff --git a/lisp/calendar/parse-date.el b/lisp/calendar/parse-date.el
new file mode 100644
index 0000000000..c4b756cf2e
--- /dev/null
+++ b/lisp/calendar/parse-date.el
@@ -0,0 +1,281 @@
+;;; parse-date.el --- parsing time/date strings -*- lexical-binding: t -*-
+
+;; Copyright (C) 2021 Free Software Foundation, Inc.
+
+;; Author: Bob Rogers <rogers@HIDDEN>
+;; Keywords: util
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; 'parse-date' parses a time and/or date in a string and returns a
+;; list of values, just like `decode-time', where unspecified elements
+;; in the string are returned as nil (except unspecified DST is
+;; returned as -1).  `encode-time' may be applied on these values to
+;; obtain an internal time value.  If left to its own devices, it
+;; accepts a wide variety of formats, but can be told to insist on a
+;; particular date/time format.
+
+;; Historically, `parse-time-string' was used for this purpose, but it
+;; was focused on email date formats, and gradually but imperfectly
+;; extended to handle other formats.  'parse-date' is compatible in
+;; that it parses the same input formats and uses the same return
+;; value format, but is stricter in that it signals an error for
+;; tokens that `parse-time-string' would simply ignore.
+
+;;; TODO:
+;;
+;; * Define and signal a date-error for parsing issues.
+;;
+;; * Implement rfc2822 and rfc822 independently of parse-time-string.
+;;
+;; * Add a euro-date format for DD/MM/YYYY ?
+;;
+
+;;; Code:
+
+(require 'cl-lib)
+(require 'iso8601)
+(require 'parse-time)
+
+(defun parse-date-guess-format (time-string)
+  (cond ((string-match "[0-9]T[0-9]" time-string) 'iso8601)
+        (t nil)))
+
+(defun parse-date-ignore-char? (char)
+  (or (eq char ?\ ) (eq char ?,) (eq char ?,)))
+
+(defun parse-date-tokenize-string (string)
+  "Turn STRING into tokens, separated only by whitespace and commas.
+Multiple commas are ignored.  Pure digit sequences are turned
+into integers."
+  (let ((index 0)
+	(end (length string))
+        (char nil)
+	(list ()))
+    ;; Skip leading ignored characters.
+    (while (and (< index end)
+                (setq char (aref string index))
+                (parse-date-ignore-char? char))
+      (cl-incf index))
+    (while (< index end)
+      (let ((start index)
+            (all-digits (<= ?0 char ?9)))
+        ;; char is valid; look for more valid characters.
+        (while (and (< (cl-incf index) end)
+                    (setq char (aref string index))
+                    (not (parse-date-ignore-char? char)))
+          (unless (<= ?0 char ?9)
+	    (setq all-digits nil)))
+        (when (<= index end)
+	  (push (if all-digits
+                    (cl-parse-integer string :start start :end index)
+		  (substring string start index))
+		list)
+          ;; Skip ignored characters.
+          (while (and (< (cl-incf index) end)
+                      (setq char (aref string index))
+                      (parse-date-ignore-char? char))
+            ())
+          ;; Next token.
+          )))
+    (nreverse list)))
+
+(defconst parse-date-slot-names
+  '(second minute hour day month year weekday dst zone)
+  "Names of return value slots, for better error messages
+See the decoded-time defstruct.")
+
+(defconst parse-date-slot-ranges
+  '((0 59) (0 59) (0 23) (1 31) (1 12) (1 9999))
+  "Numeric slot ranges, for bounds checking.")
+
+(defun parse-date-default (time-string two-digit-year?)
+  ;; Do the standard parsing thing.  This is mostly free form, in that
+  ;; tokens may appear in any order, but we expect to introduce some
+  ;; state dependence.
+  (let ((tokens (parse-date-tokenize-string (downcase time-string)))
+        (time (list nil nil nil nil nil nil nil -1 nil)))
+    (cl-flet ((set-matched-slot (slot index token)
+                ;; Assign a slot value from match data if index is
+                ;; non-nil, else from token, signalling an error if
+                ;; it's already been assigned or is out of range.
+                (let ((value (if index
+                                 (cl-parse-integer (match-string index token))
+                               token))
+                      (range (nth slot parse-date-slot-ranges)))
+                  (unless (equal (nth slot time)
+                                 (if (= slot 7) -1 nil))
+                    (error "Duplicate %s slot value '%s'"
+                           (nth slot parse-date-slot-names) token))
+                  (when (and range
+                             (not (<= (car range) value (cadr range))))
+                    (error "Value %s is out of range for %s"
+                           token (nth slot parse-date-slot-names)))
+                  (setf (nth slot time) value))))
+      (while tokens
+        (let ((token (pop tokens))
+              (match nil))
+          (cond ((numberp token)
+                  ;; A bare number could be a month, day, or year.
+                  ;; The order of these tests matters greatly.
+                  (cond ((>= token 1000)
+                          (set-matched-slot 5 nil token))
+                        ((and (<= 1 token 31)
+                              (not (nth 3 time)))
+                          ;; Assume days come before months or years.
+                          (set-matched-slot 3 nil token))
+                        ((and (<= 1 token 12)
+                              (not (nth 4 time)))
+                          ;; Assume days come before years.
+                          (set-matched-slot 4 nil token))
+                        ((or (nth 5 time)
+                             (not two-digit-year?)
+                             (> token 100))
+                          (error "Unrecognized numeric value %s" token))
+                        ;; It's a two-digit year.
+                        ((>= token 50)
+                          ;; second half of the 20th century.
+                          (set-matched-slot 5 nil (+ 1900 token)))
+                        (t
+                          ;; first half of the 21st century.
+                          (set-matched-slot 5 nil (+ 2000 token)))))
+                ((setq match (assoc token parse-time-weekdays))
+                  (set-matched-slot 6 nil (cdr match)))
+                ((setq match (assoc token parse-time-months))
+                  (set-matched-slot 4 nil (cdr match)))
+                ((setq match (assoc token parse-time-zoneinfo))
+                  (set-matched-slot 8 nil (cadr match))
+                  (set-matched-slot 7 nil (caddr match)))
+                ((string-match "^[-+][0-9][0-9][0-9][0-9]$" token)
+                  ;; Numeric time zone.
+                  (set-matched-slot
+                    8 nil
+                    (* 60
+                       (+ (cl-parse-integer token :start 3 :end 5)
+                          (* 60 (cl-parse-integer token :start 1 :end 3)))
+                       (if (= (aref token 0) ?-) -1 1))))
+                ((string-match
+                  "^\\([0-9][0-9][0-9][0-9]\\)[-/]\\([0-9][0-9]?\\)[-/]\\([0-9][0-9]?\\)$"
+                  token)
+                  ;; ISO-8601-style date (YYYY-MM-DD).
+                  (set-matched-slot 5 1 token)
+                  (set-matched-slot 4 2 token)
+                  (set-matched-slot 3 3 token))
+                ((string-match
+                  "^\\([0-9][0-9]?\\)[-/]\\([0-9][0-9]?\\)[-/]\\([0-9][0-9][0-9][0-9]\\)$"
+                  token)
+                  ;; US date (MM-DD-YYYY), but we insist on four
+                  ;; digits for the year.
+                  (set-matched-slot 4 1 token)
+                  (set-matched-slot 3 2 token)
+                  (set-matched-slot 5 3 token))
+                ((string-match
+                  "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\):\\([0-9][0-9]\\)$"
+                  token)
+                  (set-matched-slot 2 1 token)
+                  (set-matched-slot 1 2 token)
+                  (set-matched-slot 0 3 token))
+                ((string-match "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\)$" token)
+                  ;; Time without seconds.
+                  (set-matched-slot 2 1 token)
+                  (set-matched-slot 1 2 token)
+                  (set-matched-slot 0 nil 0))
+                ((member token '("am" "pm"))
+                  (unless (nth 2 time)
+                    (error "'AM'/'PM' specified before or without time"))
+                  (unless (<= (nth 2 time) 12)
+                    (error "'AM'/'PM' specified for time already past noon"))
+                  (when (equal token "pm")
+                    (cl-incf (nth 2 time) 12)))
+                (t
+                  (error "Unrecognized time token '%s'" token))))))
+    time))
+
+;;;###autoload
+(defun parse-date (time-string &optional format)
+  "Parse TIME-STRING according to FORMAT, returning a list.
+The FORMAT value is a symbol that may be one of the following:
+
+   iso8601 => parse the string according to the ISO-8601
+standard.  See `parse-iso8601-time-string'.
+
+   iso-8601 => synonym for iso8601.
+
+   rfc822 => parse an RFC822 (old email) date, which allows
+two-digit years and internal '()' comments.  In dates of the form
+'11 Jan 12', the 11 is assumed to be the day, and the 12 is
+assumed to mean 2012.  [not fully implemented.]
+
+   rfc2822 => parse an RFC2822 (new email) date, which allows
+only four-digit years.  [not implemented.]
+
+   us-date => parse a US-style date, of the form MM/DD/YYYY, but
+allowing two-digit years.  In dates of the form '01/11/12', the 1
+is the month, 11 is the day, and the 12 is assumed to mean 2012.
+[not fully implemented.]
+
+   nil => attempt to guess the format, falling back on us-date
+with two-digit years disallowed.
+
+The default is nil, and anything else is assumed to be us-date
+with two-digit years disallowed.
+
+   * For all formats except iso8601, parsing is case-insensitive.
+
+   * Commas and whitespace are ignored.
+
+   * In date specifications, either '/' or '-' may be used to
+separate components, but all three components must be given.
+
+   * A date that starts with four digits is YYYY-MM-DD, ISO-8601
+style, but a date that ends with four digits is MM-DD-YYYY [at
+least in us-date format].
+
+   * Two digit years, when allowed, are in the 1900's when
+between 50 and 99 and in the 2000's when between 0 and 49.
+
+Errors are signalled when time values are duplicated,
+unrecognized, or out of range.  No consistency checks between
+fields are done.  For instance, the weekday is not checked to see
+that it corresponds to the date, and parse-date complains about
+the 32nd of March (or any other month) but blithely accepts the
+29th of February in non-leap years -- or the 31st of February in
+any year.
+
+The result is a list of (SEC MIN HOUR DAY MON YEAR DOW DST TZ),
+which can be accessed as a decoded-time defstruct (q.v.),
+e.g. `decoded-time-year' to extract the year, and turned into an
+Emacs timestamp by `encode-time'.  The values returned are
+identical to those of `decode-time', but any unknown values other
+than DST are returned as nil, and an unknown DST value is
+returned as -1."
+  (cl-case (or format (parse-date-guess-format time-string))
+    ((iso8601 iso-8601)
+      (parse-iso8601-time-string time-string))
+    ((rfc822 rfc2822)
+      ;; [Placeholder; we eventually want something more strict.  --
+      ;; rgr, 20-Dec-21.]
+      (parse-time-string time-string))
+    (us-date
+      (parse-date-default time-string t))
+    (t
+      (parse-date-default time-string nil))))
+
+(provide 'parse-date)
+
+;;; parse-date.el ends here
diff --git a/test/lisp/calendar/parse-date-tests.el b/test/lisp/calendar/parse-date-tests.el
new file mode 100644
index 0000000000..682365e674
--- /dev/null
+++ b/test/lisp/calendar/parse-date-tests.el
@@ -0,0 +1,164 @@
+;;; parse-date-tests.el --- Test suite for parse-date.el  -*- lexical-binding:t -*-
+
+;; Copyright (C) 2016-2021 Free Software Foundation, Inc.
+
+;; Author: Lars Ingebrigtsen <larsi@HIDDEN>
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;;; Code:
+
+(require 'ert)
+(require 'parse-date)
+
+(ert-deftest parse-date-tests ()
+  "Test basic parse-date functionality."
+
+  ;; Test tokenization.
+  (should (equal (parse-date-tokenize-string " ") '()))
+  (should (equal (parse-date-tokenize-string " a b") '("a" "b")))
+  (should (equal (parse-date-tokenize-string "a bbc dde") '("a" "bbc" "dde")))
+  (should (equal (parse-date-tokenize-string " , a 27 b,, c 14:32 ")
+                 '("a" 27 "b" "c" "14:32")))
+
+  ;; Start with some RFC822 dates.
+  (dolist (format '(nil rfc822))
+    (should (equal (parse-date "Mon, 22 Feb 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "22 Feb 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 nil -1 3600)))
+    (should (equal (parse-date "22 Feb 2016 +0100" format)
+                   '(nil nil nil 22 2 2016 nil -1 3600)))
+    (should (equal (parse-date "Mon, 22 February 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "Mon, 22 feb 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "Monday, 22 february 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "Monday, 22 february 2016 19:35:42 PST" format)
+                   '(42 35 19 22 2 2016 1 nil -28800)))
+    (should (equal (parse-date "Friday, 21 Sep 2018 13:47:58 PDT" format)
+                   '(58 47 13 21 9 2018 5 t -25200)))
+    (should (equal (parse-date "Friday, 21 Sep 2018 13:47:58" format)
+                   '(58 47 13 21 9 2018 5 -1 nil)))
+    (should (equal (parse-date "Friday, 21 Sep 2018" format)
+                   '(nil nil nil 21 9 2018 5 -1 nil))))
+  ;; These are not allowed by the default format.
+  (should (equal (parse-date "22 Feb 16 19:35:42 +0100" 'rfc822)
+                 '(42 35 19 22 2 2016 nil -1 3600)))
+  (should (equal (parse-date "22 Feb 96 19:35:42 +0100" 'rfc822)
+                 '(42 35 19 22 2 1996 nil -1 3600)))
+
+  ;; Test the default format with both hyphens and slashes in dates.
+  (dolist (case '(;; Month can be numeric if date uses hyphens/slashes.
+                  ("Friday, 2018-09-21" (nil nil nil 21 9 2018 5 -1 nil))
+                  ;; Year can come last if four digits.
+                  ("Friday, 9-21-2018" (nil nil nil 21 9 2018 5 -1 nil))
+                  ;; Day of week is optional
+                  ("2018-09-21" (nil nil nil 21 9 2018 nil -1 nil))
+                  ;; The order of date, time, etc., does not matter.
+                  ("13:47:58, +0100, 2018-09-21, Friday"
+                   (58 47 13 21 9 2018 5 -1 3600))
+                  ;; Month, day, or both, can be a single digit.
+                  ("Friday, 2018-9-08" (nil nil nil 8 9 2018 5 -1 nil))
+                  ("Friday, 2018-09-8" (nil nil nil 8 9 2018 5 -1 nil))
+                  ("Friday, 2018-9-8" (nil nil nil 8 9 2018 5 -1 nil))))
+    (let ((string (car case))
+          (expected (cadr case)))
+      ;; Test with hyphens.
+      (should (equal (parse-date string) expected))
+      (while (string-match "-" string)
+        (setq string (replace-match "/" t t string)))
+      ;; Test with slashes.
+      (should (equal (parse-date string) expected))))
+
+  ;; Time by itself is recognized as such.
+  (should (equal (parse-date "03:47:58")
+                 '(58 47 3 nil nil nil nil -1 nil)))
+  ;; A leading zero for hours is optional.
+  (should (equal (parse-date "3:47:58")
+                 '(58 47 3 nil nil nil nil -1 nil)))
+  ;; Missing seconds are assumed to be zero.
+  (should (equal (parse-date "3:47")
+                 '(0 47 3 nil nil nil nil -1 nil)))
+  ;; AM/PM are understood (in any case combination).
+  (dolist (am '(am AM Am))
+    (should (equal (parse-date (format "3:47 %s" am))
+                   '(0 47 3 nil nil nil nil -1 nil))))
+  (dolist (pm '(pm PM Pm))
+    (should (equal (parse-date (format "3:47 %s" pm))
+                   '(0 47 15 nil nil nil nil -1 nil))))
+
+  ;; Ensure some cases fail.
+  (should-error (parse-date "22 Feb 196" 'us-date))	;; bad year
+  (should-error (parse-date "22 Feb 16 19:35:42"))	;; two-digit year
+  (should-error (parse-date "22 Feb 96 19:35:42"))	;; two-digit year
+  (should-error (parse-date "2 Feb 2021 1996"))	;; duplicate year
+  (should-error (parse-date "2020-1-1 2021"))	;; another duplicate year
+  (should-error (parse-date "2020-1-1 30"))	;; extra 30 (not a day))
+  (should-error (parse-date "2020-1-1 12"))	;; extra 12 (not a month)
+  (should-error (parse-date "15:47 15:15"))	;; duplicate time
+  (should-error (parse-date "2020-1-1 +0800 -0800"))	;; duplicate TZ
+  (should-error (parse-date "15:47 PM"))	;; PM in the afternoon
+  (should-error (parse-date "2020-1-1 PM"))	;; PM without a time
+  ;; Range tests.
+  (should-error (parse-date "2021-12-32"))
+  (should-error (parse-date "2021-12-0"))
+  (should-error (parse-date "2021-13-3"))
+  (should-error (parse-date "0000-12-3"))
+  (should-error (parse-date "20021 Dec 3"))
+  (should-error (parse-date "24:21:14"))
+  (should-error (parse-date "14:60:21"))
+  (should-error (parse-date "14:21:60"))
+
+  ;; Test ISO-8601 dates.
+  (dolist (format '(nil iso8601 iso-8601))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54-0200" format) t)
+                   "1998-09-12 14:21:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54-0230" format) t)
+                   "1998-09-12 14:51:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54-02:00" format) t)
+                   "1998-09-12 14:21:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54-02" format) t)
+                   "1998-09-12 14:21:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54+0230" format) t)
+                   "1998-09-12 09:51:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54+02" format) t)
+                   "1998-09-12 10:21:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (parse-date "1998-09-12T12:21:54Z" format) t)
+                   "1998-09-12 12:21:54"))
+    (should (equal (parse-date "1998-09-12T12:21:54")
+                   (encode-time 54 21 12 12 9 1998)))))
+
+(provide 'parse-date-tests)
+
+;;; parse-date-tests.el ends here

--gKQbAfc6jm--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Dec 2021 09:30:02 +0000
Resent-Message-ID: <handler.52209.B52209.16403381921317 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16403381921317
          (code B ref 52209); Fri, 24 Dec 2021 09:30:02 +0000
Received: (at 52209) by debbugs.gnu.org; 24 Dec 2021 09:29:52 +0000
Received: from localhost ([127.0.0.1]:35681 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n0gtc-0000L7-A6
	for submit <at> debbugs.gnu.org; Fri, 24 Dec 2021 04:29:52 -0500
Received: from quimby.gnus.org ([95.216.78.240]:40346)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n0gtZ-0000Kl-NE
 for 52209 <at> debbugs.gnu.org; Fri, 24 Dec 2021 04:29:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=zBB7Mhr8l0Y3u/ykjmr922KhAphfjXjDwcqaB5Ltzcs=; b=lAeFdvd1qVkiBRqx9Hc+wAEZkH
 7KRNl47FlyuSP0qxbQrmSOVMFn3LQLPmNUeYBrFZN6gfpGESg1TYeqERS658P8C2h2Ot70jlZ6teE
 VOl56B/WH6W6xrB5VXiUKaGa3NCs9Gd1PVAINlEOSB4xIHQWXHxN++uZqdgTGki2UIcI=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n0gtQ-000277-Hs; Fri, 24 Dec 2021 10:29:43 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEVBR1MTEhVTn+s/
 Z52/r6z///8nA0HJAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UMGAkCD3dY9nwAAAGoSURBVDjLbZOB
 dYMwDESlmgGs0AFaOwMY3AFc4v1nqk4yAZLCSx74c6eTMMQSM4sIfpGII4kQk+ASIHYQquNYFwo8
 b7rWezdAFAg/pspzYvlUwCdFXYgkVpFJQXOFH0wUuehKH16WgREA1BXqFXGtwUyhZgMsEiMz/Kpb
 wmJqMBEAtGNHwYpoCPYiFq08wWT/+rRYJ9aLg0bdbfgMIqH8L7wUFAMVoLd+AlohOIi9nRQorZHN
 avpViKGgYwdUDDTZh2IgVNJKdjvtIABo66GiiM6S6ADVZnJvFn9yRaxhgLk/bCLkxQ8Q7g8Z80W1
 +QQ2a711miDYQa59kzHADsEOUiplgOkF5GUXABR6gpSRqrCDlA+gbj/oG3FnPHiAlG0iXeLNbi3V
 apeLS+gjDULJybdLmj+mBEOua01f0UAY6/fsb1yV9j76Y1ckEnm2BzC/g+jbYX0Hvh1uB/ANJ2yS
 OL8pyED9x8rKb7a6XoB5Gch6HkBrQbKaYD0DssQQvAFI1CvnSw2tDsmG0V5S4ZuiPdYFUNTPZ0uZ
 1pc+sH+19kNeAOHEmr/tP8Z4f61SELGbAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTEyLTI0VDA5
 OjAyOjE1KzAwOjAwF5gWKQAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0xMi0yNFQwOTowMjoxNSsw
 MDowMGbFrpUAAAAASUVORK5CYII=
X-Now-Playing: James Taylor's _Sweet Baby James_: "Suite For 20 G"
Date: Fri, 24 Dec 2021 10:29:29 +0100
In-Reply-To: <25028.53876.304365.706795@HIDDEN> (Bob Rogers's message
 of "Thu, 23 Dec 2021 14:48:04 -0500")
Message-ID: <87zgoq2vwm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Bob Rogers <rogers-emacs@HIDDEN> writes: > OK,
 I have proceeded along those lines; WIP attached for feedback. I > changed
 the name to "parse-date" to avoid confusion; I was otherwise > stuck when
 trying to come up with a sensible name for th [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> OK, I have proceeded along those lines; WIP attached for feedback.  I
> changed the name to "parse-date" to avoid confusion; I was otherwise
> stuck when trying to come up with a sensible name for the test file,
> since parse-time-tests.el was already taken (though I suppose I could
> have added to the existing file).

Sounds good to me.

> Which (additional) formats would you like?  I'm assuming we need iso8601
> and rfc822 for compatibility (in which case rfc2822 will be easy to
> provide in addition), and us-date and euro-date to disambiguate the
> month/day order.  Would the third format correspond to ISO 2001-01-03?
> Do we want to support that?

Probably not -- you mostly see that in Sweden.

> +(defun parse-date (time-string &optional format)

I think it'd be better if this was a cl-defmethod with an eql specifier
for the format.

> +   iso8601 => parse the string according to the ISO-8601
> +standard.  See `parse-iso8601-time-string'.
> +
> +   iso-8601 => synonym for iso8601.

And synonyms aren't necessary -- they just confuse people reading the
code.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Dec 2021 15:59:02 +0000
Resent-Message-ID: <handler.52209.B52209.1640361539646 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.1640361539646
          (code B ref 52209); Fri, 24 Dec 2021 15:59:02 +0000
Received: (at 52209) by debbugs.gnu.org; 24 Dec 2021 15:58:59 +0000
Received: from localhost ([127.0.0.1]:37924 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n0myB-0000AK-98
	for submit <at> debbugs.gnu.org; Fri, 24 Dec 2021 10:58:59 -0500
Received: from rgrjr.com ([69.164.211.47]:38142)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n0my8-0000A8-0Z
 for 52209 <at> debbugs.gnu.org; Fri, 24 Dec 2021 10:58:57 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 4498B1D6BB2;
 Fri, 24 Dec 2021 15:59:08 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 2AB385FEC6; 
 Fri, 24 Dec 2021 10:58:55 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25029.60989.564217.290743@HIDDEN>
Date: Fri, 24 Dec 2021 10:58:53 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87zgoq2vwm.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Fri, 24 Dec 2021 10:29:29 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > Which (additional) formats would you like?  I'm assuming we need iso8601
   > and rfc822 for compatibility (in which case rfc2822 will be easy to
   > provide in addition), and us-date and euro-date to disambiguate the
   > month/day order.  Would the third format correspond to ISO 2001-01-03?
   > Do we want to support that?

   Probably not -- you mostly see that in Sweden.

OK (<phew> ;-}).

   > +(defun parse-date (time-string &optional format)

   I think it'd be better if this was a cl-defmethod with an eql
   specifier for the format.

OK, good; cl-case was easier to start, but I was also beginning to think
in terms of cl-defmethod.

   > +   iso8601 => parse the string according to the ISO-8601
   > +standard.  See `parse-iso8601-time-string'.
   > +
   > +   iso-8601 => synonym for iso8601.

   And synonyms aren't necessary -- they just confuse people reading the
   code.

OK.  I added the synonym because RFCs are always spelled without the
hyphen, but I wasn't sure about the convention for ISO standards.  And
it seems that there isn't a well defined precedent in the Emacs sources;
C programmers mostly avoid the hyphen, but Elisp programmers are more
evenly split:

    rogers@orion> find . -name '*.el' | xargs cat | tr A-Z a-z | grep -c 'iso-[0-9]'
    702
    rogers@orion> find . -name '*.el' | xargs cat | tr A-Z a-z | grep -c 'iso[0-9]'
    798
    rogers@orion> find . -name '*.[ch]' | xargs cat | tr A-Z a-z | grep -c 'iso-[0-9]'
    47
    rogers@orion> find . -name '*.[ch]' | xargs cat | tr A-Z a-z | grep -c 'iso[0-9]'
    148
    rogers@orion> 

So which do you prefer?

   I'm also looking at defining a date-parse-error condition with a few
error symbol "subclasses," but I'm wondering about the tradeoff between
having enough error symbols for precision in error reporting
vs. cluttering the code with too many.  Thoughts?

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Dec 2021 11:59:02 +0000
Resent-Message-ID: <handler.52209.B52209.16404335116555 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16404335116555
          (code B ref 52209); Sat, 25 Dec 2021 11:59:02 +0000
Received: (at 52209) by debbugs.gnu.org; 25 Dec 2021 11:58:31 +0000
Received: from localhost ([127.0.0.1]:38583 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n15h1-0001hf-EO
	for submit <at> debbugs.gnu.org; Sat, 25 Dec 2021 06:58:31 -0500
Received: from quimby.gnus.org ([95.216.78.240]:50534)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n15gy-0001hO-1H
 for 52209 <at> debbugs.gnu.org; Sat, 25 Dec 2021 06:58:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=a+gYsgS0KFtl9nOpZxgawx/IC1FZeofmVMVqIp6oDDQ=; b=bUvaYM9Uj5nz2WUKs3L829QN4W
 s/+pq7YnOzq9stSC06RmcdsN/6xCXOFvNH8IGamSSsnW2dT1oAv04TB9gd7Zd+cuA92ZwMcR43SdT
 vYrk7xZgWkLN+7akGiudX+hobeWb8KtE9Z5I2AHjSdQd5kXbUvKDko1nAYAfcUYiCdLs=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n15gn-0003U9-4d; Sat, 25 Dec 2021 12:58:20 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEXxRJPVQ4dcOkIm
 GCQgFB7jPYnR0qP7+7hiVqTo7L7///8o2i64AAAAAWJLR0QKaND0VgAAAAd0SU1FB+UMFhQ5Jv15
 xjgAAAGwSURBVDjLdZPPUsJADMZLHe6AeK9Q8SqbjA/Q7MEjjtMXQAY9eyg+geIT+Lrmz2ZLUXNY
 lv31+7JN0qKwmC2BI1ynv8XIzxEsqiGYRYywBF7CxE7GupaIzerl0O23NayLk5hD83LQ6OpsJn6A
 t4cUHYQelHR/yPFMkwzqoEbdXleseicVdMfj8Zt/d012ip8C+Pz4wb9vGVyQOL0LEEkHnmTeiOBV
 gWhrT1I/nIG7AdBzTVKv/wBfpwCbHqhVGIDXX2CEcHZdB2Ql9NwdwSaBviQifaP0hiVBsIrvtZY7
 wAz6dkh1vfFPPAJND7ZEqfCXDHDVC3giDMwjE1p5z4kgDUQtIxXjQvq3RYoxg6ggUlgsIyFvoBkC
 lIcV6KuPdTKjHNpOlo2OwhDoEE8UuNV/ILI/yQ6sJlxc0JyeQ0ClICsgYvKscnLyFECeo9Td0MqS
 k6V0SQKjfCv6pbBL+jlmxVgAmoJSCYJ+tXU8yW1PKNgwoFQqv4UDOXcrlazlO3cgEpSeMLhpi2mx
 mWuLzEs6y6BqRwYgAzO9epxOi/FFb2VPUGhbBm0ZU2hbBaxbVvwA3vQHOudokaMAAAAldEVYdGRh
 dGU6Y3JlYXRlADIwMjEtMTItMjJUMjA6NTc6MzgrMDA6MDCWfrAzAAAAJXRFWHRkYXRlOm1vZGlm
 eQAyMDIxLTEyLTIyVDIwOjU3OjM4KzAwOjAw5yMIjwAAAABJRU5ErkJggg==
X-Now-Playing: Vanishing Twin's _Ookii Gekkou_: "Phase One Million"
Date: Sat, 25 Dec 2021 12:58:14 +0100
In-Reply-To: <25029.60989.564217.290743@HIDDEN> (Bob Rogers's message
 of "Fri, 24 Dec 2021 10:58:53 -0500")
Message-ID: <87bl1428x5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Bob Rogers <rogers-emacs@HIDDEN> writes: > So
 which do you prefer? With a hyphen. 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> So which do you prefer?

With a hyphen.

>    I'm also looking at defining a date-parse-error condition with a few
> error symbol "subclasses," but I'm wondering about the tradeoff between
> having enough error symbols for precision in error reporting
> vs. cluttering the code with too many.  Thoughts?

Having a `date-parse-error' would be fine, but I'm unsure about the
utility of having a bunch of sub-errors, but perhaps you have a use case
in mind?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Dec 2021 22:51:01 +0000
Resent-Message-ID: <handler.52209.B52209.16404726152126 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16404726152126
          (code B ref 52209); Sat, 25 Dec 2021 22:51:01 +0000
Received: (at 52209) by debbugs.gnu.org; 25 Dec 2021 22:50:15 +0000
Received: from localhost ([127.0.0.1]:40018 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n1Frj-0000YE-9M
	for submit <at> debbugs.gnu.org; Sat, 25 Dec 2021 17:50:15 -0500
Received: from rgrjr.com ([69.164.211.47]:38374)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n1Frg-0000Y3-N7
 for 52209 <at> debbugs.gnu.org; Sat, 25 Dec 2021 17:50:13 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id D295B1D6BB2;
 Sat, 25 Dec 2021 22:50:24 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id D3C835FE8B; 
 Sat, 25 Dec 2021 17:50:11 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25031.40994.286546.498819@HIDDEN>
Date: Sat, 25 Dec 2021 17:50:10 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87bl1428x5.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Sat, 25 Dec 2021 12:58:14 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > I'm also looking at defining a date-parse-error condition with a
   > few error symbol "subclasses," but I'm wondering about the tradeoff
   > between having enough error symbols for precision in error
   > reporting vs. cluttering the code with too many.  Thoughts?

   Having a `date-parse-error' would be fine, but I'm unsure about the
   utility of having a bunch of sub-errors, but perhaps you have a use
   case in mind?

My only motivation is that I think it would make the resulting error
message clearer.  For example, passing a malformed ISO 8601 date to
iso8601-parse just signals wrong-type-argument, which is not very
helpful.  Multiple errors would allow me to specify the problem in
detail, while still classifying them as date/time parsing errors.  Here
are four that I have in mind:

	Unknown date/time token: X
	Illegal date/time value for field: <field>, X
	Duplicate date/time value for field: <field>, X
	Date/time value for field out of range: <field>, X, <min>, <max>

This doesn't quite cover the 14 calls to `error' that are in the current
version of the code, in that they wouldn't be as precise, but they
should be adequate.

   On the other hand, this might be overkill for callers of parse-date,
who, being deep in their own logic, might only care that some date they
have to deal with is invalid.  Which is why I wanted an opinion from
someone with the big picture -- I admit I am biased (and a bit annoyed)
from too often having to study the code to figure out why some perfectly
reasonable date I supply is being misinterpreted.

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 26 Dec 2021 11:32:02 +0000
Resent-Message-ID: <handler.52209.B52209.164051828523714 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164051828523714
          (code B ref 52209); Sun, 26 Dec 2021 11:32:02 +0000
Received: (at 52209) by debbugs.gnu.org; 26 Dec 2021 11:31:25 +0000
Received: from localhost ([127.0.0.1]:40295 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n1RkK-0006AQ-Q6
	for submit <at> debbugs.gnu.org; Sun, 26 Dec 2021 06:31:24 -0500
Received: from quimby.gnus.org ([95.216.78.240]:59044)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n1RkH-0006A7-Oi
 for 52209 <at> debbugs.gnu.org; Sun, 26 Dec 2021 06:31:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=lYXtyINJYN/F6bJnzZsHRZLtWMLU/hqpdokRpU0BH0c=; b=RiPtx75fHdEt9qNvUwpI/Qdap3
 w49OPSzmqqa21gN9LtEmI0MKn3NFuxqCNIUh6/zRF+QtTEizzqXWrpMPmykouqHGdWFxkhhfGyeww
 J/DXHTWQm7/mH92gtaEIwqhaFQlpocxocLooIHXPfSlKU/rkFLmXt8YMcCQWcgaT6wKw=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n1Rk8-0004SF-DT; Sun, 26 Dec 2021 12:31:14 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEVWTFCpYWg3MTT/
 //+VP7zNAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+UMGgsaLhCnYp4AAAEqSURBVCjPbdJBasMwEAXQ
 iUjAaNWUeO92FeYUpdB9GuJNj5BTiNBFyLInmGY1/FP2j+SkLlQGW88jyaORRR4k+1YyRFTYYArg
 LJjgwCU3FLWMM4jFKz5z+cC31kgySdJJREThEitMwF+khqWoYpFwgj8TOfsT8AU/clhOELhancNF
 BW2ORQqi18uVKMRqHMd9wIk+cBs2/gufg4uv79A5cpkBJfW/cJlgWyL3h4rSRb6BHcEkr9g08POW
 UDb9QR4jwiqXzWICS1GW7298EkNgHS9LmjYcrWROuTXTVj6LmzNn4OjDlrY4PKgPHbupAieeCSw3
 xHZhLeLclGip8JqSWq2ysdpqPEslolip1DpHJDFFXoHS0FXIas+SvNTfw9sp3LHa1W4DW6wlP+Oo
 wtnMVjPkAAAAQnRFWHRjb21tZW50AENSRUFUT1I6IGdkLWpwZWcgdjEuMCAodXNpbmcgSUpHIEpQ
 RUcgdjgwKSwgcXVhbGl0eSA9IDEwMAqhrIJaAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTEyLTI2
 VDExOjI2OjQ2KzAwOjAwf7sMEwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0xMi0yNlQxMToyNjo0
 NiswMDowMA7mtK8AAAAASUVORK5CYII=
X-Now-Playing: Anne Clark's _R.V.S.P._: "The Last Emotion"
Date: Sun, 26 Dec 2021 12:31:07 +0100
In-Reply-To: <25031.40994.286546.498819@HIDDEN> (Bob Rogers's message
 of "Sat, 25 Dec 2021 17:50:10 -0500")
Message-ID: <87ee5zzjpg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Bob Rogers <rogers-emacs@HIDDEN> writes: > On the
 other hand, this might be overkill for callers of parse-date, > who, being
 deep in their own logic, might only care that some date they > have to deal
 with is invalid. Which is why I wanted a [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

>    On the other hand, this might be overkill for callers of parse-date,
> who, being deep in their own logic, might only care that some date they
> have to deal with is invalid.  Which is why I wanted an opinion from
> someone with the big picture -- I admit I am biased (and a bit annoyed)
> from too often having to study the code to figure out why some perfectly
> reasonable date I supply is being misinterpreted.

Better errors messages are possible without making many specific error
symbols, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 28 Dec 2021 15:53:01 +0000
Resent-Message-ID: <handler.52209.B52209.16407067585215 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16407067585215
          (code B ref 52209); Tue, 28 Dec 2021 15:53:01 +0000
Received: (at 52209) by debbugs.gnu.org; 28 Dec 2021 15:52:38 +0000
Received: from localhost ([127.0.0.1]:47244 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n2EmC-0001M1-Uq
	for submit <at> debbugs.gnu.org; Tue, 28 Dec 2021 10:52:38 -0500
Received: from rgrjr.com ([69.164.211.47]:39056)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n2Em9-0001Lr-Kz
 for 52209 <at> debbugs.gnu.org; Tue, 28 Dec 2021 10:52:35 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id A90071D6BB2;
 Tue, 28 Dec 2021 15:52:45 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id DA0FD6010E; 
 Tue, 28 Dec 2021 10:52:32 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="YAYPog+/V1"
Content-Transfer-Encoding: 7bit
Message-ID: <25035.12991.328986.987982@HIDDEN>
Date: Tue, 28 Dec 2021 10:52:31 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87ee5zzjpg.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)


--YAYPog+/V1
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Sun, 26 Dec 2021 12:31:07 +0100

   Better errors messages are possible without making many specific error
   symbols, though.

OK, I think I have a good solution that uses a single error symbol; let
me know what you think.  (Having never done much with Elisp conditions,
I was still thinking in terms of Common Lisp, so I had to go scratch my
head for a while.)

   I am currently working on broadening what the parser will accept,
though I think it is close to a usable state.  I am using the
documentation for the Perl Date::Parse module to see what it accepts,
and will then look at the corresponding Python and Ruby modules for
further ideas.  I am not planning to adopt everything I see, though; in
particular, I think it's a good idea for new code to stick to insisting
on four-digit years except when the caller has specified a format that
determines the month/day order.

					-- Bob


--YAYPog+/V1
Content-Type: text/x-patch
Content-Description: 
Content-Disposition: inline;
	filename="rgr-parse-date-211228.patch"
Content-Transfer-Encoding: 7bit

diff --git a/lisp/calendar/parse-date.el b/lisp/calendar/parse-date.el
new file mode 100644
index 0000000000..10bd939e91
--- /dev/null
+++ b/lisp/calendar/parse-date.el
@@ -0,0 +1,472 @@
+;;; parse-date.el --- parsing time/date strings -*- lexical-binding: t -*-
+
+;; Copyright (C) 2021 Free Software Foundation, Inc.
+
+;; Author: Bob Rogers <rogers@HIDDEN>
+;; Keywords: util
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; 'parse-date' parses a time and/or date in a string and returns a
+;; list of values, just like `decode-time', where unspecified elements
+;; in the string are returned as nil (except unspecified DST is
+;; returned as -1).  `encode-time' may be applied on these values to
+;; obtain an internal time value.  If left to its own devices, it
+;; accepts a wide variety of formats, but can be told to insist on a
+;; particular date/time format.
+
+;; Historically, `parse-time-string' was used for this purpose, but it
+;; was focused on email date formats, and gradually but imperfectly
+;; extended to handle other formats.  'parse-date' is compatible in
+;; that it parses the same input formats and uses the same return
+;; value format, but is stricter in that it signals an error for
+;; tokens that `parse-time-string' would simply ignore.
+
+;;; TODO:
+;;
+;; * Add a euro-date format for DD/MM/YYYY ?
+;;
+
+;;; Code:
+
+(require 'cl-lib)
+(require 'iso8601)
+(require 'parse-time)
+
+(define-error 'date-parse-error "Date/time parse error" 'error)
+
+(defconst parse-date--ends-with-alpha-tz-re
+  (concat " \\(" (mapconcat #'car parse-time-zoneinfo "\\|") "\\)$")
+  "Recognize an alphanumeric timezone at the end of the string.")
+
+(defun parse-date--guess-rfc822-formats (date-string)
+  (let ((case-fold-search t))
+    (cond ((string-match "(" date-string) 'rfc2822)
+          ((string-match parse-date--ends-with-alpha-tz-re date-string)
+            ;; Alphabetic timezones are legacy syntax.
+            'rfc822)
+          ((string-match " [-+][0-9][0-9][0-9][0-9][ \t\n]*\\($\\}(\\)"
+                         date-string)
+            ;; Note that an ISO-8601 timezone has a colon in the middle
+            ;; and no preceding space.
+            'rfc2822)
+          (t nil))))
+
+(defun parse-date--guess-format (date-string)
+  (cond ((iso8601-valid-p date-string) 'iso-8601)
+        ((parse-date--guess-rfc822-formats date-string))
+        (t nil)))
+
+(defun parse-date--ignore-char? (char)
+  ;; Ignore whitespace and commas.
+  (or (eq char ?\ ) (eq char ?\t) (eq char ?\r) (eq char ?\n) (eq char ?,)))
+
+(defun parse-date--tokenize-string (string &optional strip-fws?)
+  "Turn STRING into tokens, separated only by whitespace and commas.
+Multiple commas are ignored.  Pure digit sequences are turned
+into integers.  If STRIP-FWS? is true, then folding whitespace as
+defined by RFC2822 (strictly, the CFWS production that also
+accepts comments) is stripped out by treating it like whitespace;
+if it's value is the symbol `first', we exit when we see the
+first '(' (per RFC2822), else we strip them all (per RFC822)."
+  (let ((index 0)
+	(end (length string))
+        (fws-eof? (eq strip-fws? 'first))
+	(list ()))
+    (when fws-eof?
+      ;; In order to stop on the first "(", we need to see it as
+      ;; non-whitespace.
+      (setq strip-fws? nil))
+    (cl-flet ((skip-ignored ()
+                ;; Skip ignored characters at index (the scan
+                ;; position).  Skip RFC822 comments in matched parens
+                ;; if strip-fws? is true, but do not complain about
+                ;; unterminated comments.
+                (let ((char nil)
+                      (nest 0))
+                  (while (and (< index end)
+                              (setq char (aref string index))
+                              (or (> nest 0)
+                                  (parse-date--ignore-char? char)
+                                  (and strip-fws? (eql char ?\())))
+                    (cl-incf index)
+                    ;; FWS bookkeeping.
+                    (cond ((not strip-fws?))
+                          ((and (eq char ?\\)
+                                (< (1+ index) end))
+	                    ;; Move to the next char but don't check
+	                    ;; it to see if it might be a paren.
+                            (cl-incf index))
+                          ((eq char ?\() (cl-incf nest))
+                          ((eq char ?\)) (cl-decf nest)))))))
+      (skip-ignored)		;; Skip leading whitespace.
+      (while (and (< index end)
+                  (not (and fws-eof?
+                            (eq (aref string index) ?\())))
+        (let* ((start index)
+               (char (aref string index))
+               (all-digits (<= ?0 char ?9)))
+          ;; char is valid; look for more valid characters.
+          (when (and strip-fws?
+                     (eq char ?\\)
+                     (< (1+ index) end))
+            ;; Escaped character, which might be a "(".  If so, we are
+            ;; correct to include it in the token, even though the
+            ;; caller is sure to barf.  If not, we violate RFC2?822 by
+            ;; not removing the backslash, but no characters in valid
+            ;; RFC2?822 dates need escaping anyway, so it shouldn't
+            ;; matter that this is not done strictly correctly.  --
+            ;; rgr, 24-Dec-21.
+            (cl-incf index))
+          (while (and (< (cl-incf index) end)
+                      (setq char (aref string index))
+                      (not (or (parse-date--ignore-char? char)
+                               (and strip-fws?
+                                    (eq char ?\()))))
+            (unless (<= ?0 char ?9)
+              (setq all-digits nil))
+            (when (and strip-fws?
+                       (eq char ?\\)
+                       (< (1+ index) end))
+              ;; Escaped character, see above.
+              (cl-incf index)))
+          (push (if all-digits
+                    (cl-parse-integer string :start start :end index)
+                  (substring string start index))
+                list)
+          (skip-ignored)))
+      (nreverse list))))
+
+(defconst parse-date--slot-names
+  '(second minute hour day month year weekday dst zone)
+  "Names of return value slots, for better error messages
+See the decoded-time defstruct.")
+
+(defconst parse-date--slot-ranges
+  '((0 60) (0 59) (0 23) (1 31) (1 12) (1 9999))
+  "Numeric slot ranges, for bounds checking.
+Note that RFC2822 explicitly requires that seconds go up to 60,
+to allow for leap seconds (see Mills, D., 'Network Time
+Protocol', STD 12, RFC 1119, September 1989).")
+
+(defun parse-date--x822 (time-string obs-format?)
+  ;; Parse an RFC2822 or (if obs-format? is true) RFC822 date.  The
+  ;; strict syntax for the former is as follows:
+  ;;
+  ;;	[ day-of-week "," ] day FWS month-name FWS year FWS time [CFWS]
+  ;;
+  ;; where "time" is:
+  ;;
+  ;;	2DIGIT ":" 2DIGIT [ ":" 2DIGIT ] FWS ( "+" / "-" ) 4DIGIT
+  ;;
+  ;; RFC822 also accepts comments in random places (which is handled
+  ;; by parse-date--tokenize-string) and two-digit years.  We are
+  ;; somewhat more lax in what we accept (specifically, the hours
+  ;; don't have to be two digits, and the TZ and the comma after the
+  ;; DOW are optional), but we do insist that the items that are
+  ;; present do appear in this order.
+  (let ((tokens (parse-date--tokenize-string (downcase time-string)
+                                            (if obs-format? 'all 'first)))
+        (time (list nil nil nil nil nil nil nil -1 nil)))
+    (cl-labels ((set-matched-slot (slot index token)
+                  ;; Assign a slot value from match data if index is
+                  ;; non-nil, else from token, signalling an error if
+                  ;; it's already been assigned or is out of range.
+                  (let ((value (if index
+                                   (cl-parse-integer (match-string index token))
+                                 token))
+                        (range (nth slot parse-date--slot-ranges)))
+                    (unless (equal (nth slot time)
+                                   (if (= slot 7) -1 nil))
+                      (signal 'date-parse-error
+                              (list "Duplicate slot value"
+                                    (nth slot parse-date--slot-names) token)))
+                    (when (and range
+                               (not (<= (car range) value (cadr range))))
+                      (signal 'date-parse-error
+                              (list "Slot out of range"
+                                    (nth slot parse-date--slot-names)
+                                    token (car range) (cadr range))))
+                    (setf (nth slot time) value)))
+                (set-numeric (slot token)
+                  (unless (natnump token)
+                    (signal 'date-parse-error
+                              (list "Not a number"
+                                    (nth slot parse-date--slot-names) token)))
+                  (set-matched-slot slot nil token)))
+      ;; Check for weekday.
+      (let ((dow (assoc (car tokens) parse-time-weekdays)))
+        (when dow
+          ;; Day of the week.
+          (set-matched-slot 6 nil (cdr dow))
+          (pop tokens)))
+      ;; Day.
+      (set-numeric 3 (pop tokens))
+      ;; Alphabetic month.
+      (let* ((month (pop tokens))
+             (match (assoc month parse-time-months)))
+        (if match
+            (set-matched-slot 4 nil (cdr match))
+          (signal 'date-parse-error
+                  (list "Expected an alphabetic month" month))))
+      ;; Year.
+      (let ((year (pop tokens)))
+        ;; Check the year for the right number of digits.
+        (cond ((> year 1000)
+                (set-numeric 5 year))
+              ((or (not obs-format?)
+                   (>= year 100))
+                "Four digit years are required but found '%s'" year)
+              ((>= year 50)
+                ;; second half of the 20th century.
+                (set-numeric 5 (+ 1900 year)))
+              (t
+                ;; first half of the 21st century.
+                (set-numeric 5 (+ 2000 year)))))
+      ;; Time.
+      (let ((time (pop tokens)))
+        (cond ((or (null time) (natnump time))
+                (signal 'date-parse-error
+                        (list "Expected a time" time)))
+              ((string-match
+                "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\):\\([0-9][0-9]\\)$"
+                time)
+                (set-matched-slot 2 1 time)
+                (set-matched-slot 1 2 time)
+                (set-matched-slot 0 3 time))
+              ((string-match "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\)$" time)
+                ;; Time without seconds.
+                (set-matched-slot 2 1 time)
+                (set-matched-slot 1 2 time)
+                (set-matched-slot 0 nil 0))
+              (t
+                (signal 'date-parse-error
+                        (list "Expected a time" time)))))
+      ;; Timezone.
+      (let* ((zone (pop tokens))
+             (match (assoc zone parse-time-zoneinfo)))
+        (cond (match
+                (set-matched-slot 8 nil (cadr match))
+                (set-matched-slot 7 nil (caddr match)))
+              ((and (stringp zone)
+                    (string-match "^[-+][0-9][0-9][0-9][0-9]$" zone))
+                ;; Numeric time zone.
+                (set-matched-slot
+                  8 nil
+                  (* 60
+                     (+ (cl-parse-integer zone :start 3 :end 5)
+                        (* 60 (cl-parse-integer zone :start 1 :end 3)))
+                     (if (= (aref zone 0) ?-) -1 1))))
+              (zone
+                (signal 'date-parse-error
+                        (list "Expected a timezone" zone)))))
+      (when tokens
+        (signal 'date-parse-error
+                (list "Extra token(s)" (car tokens)))))
+    time))
+
+(defun parse-date--default (time-string two-digit-year?)
+  ;; Do the standard parsing thing.  This is mostly free form, in that
+  ;; tokens may appear in any order, but we expect to introduce some
+  ;; state dependence.
+  (let ((tokens (parse-date--tokenize-string (downcase time-string)))
+        (time (list nil nil nil nil nil nil nil -1 nil)))
+    (cl-flet ((set-matched-slot (slot index token)
+                ;; Assign a slot value from match data if index is
+                ;; non-nil, else from token, signalling an error if
+                ;; it's already been assigned or is out of range.
+                (let ((value (if index
+                                 (cl-parse-integer (match-string index token))
+                               token))
+                      (range (nth slot parse-date--slot-ranges)))
+                  (unless (equal (nth slot time)
+                                 (if (= slot 7) -1 nil))
+                    (signal 'date-parse-error
+                              (list "Duplicate slot value"
+                                    (nth slot parse-date--slot-names) token)))
+                  (when (and range
+                             (not (<= (car range) value (cadr range))))
+                    (signal 'date-parse-error
+                            (list "Slot out of range"
+                                         (nth slot parse-date--slot-names)
+                                         token (car range) (cadr range))))
+                  (setf (nth slot time) value))))
+      (while tokens
+        (let ((token (pop tokens))
+              (match nil))
+          (cond ((numberp token)
+                  ;; A bare number could be a month, day, or year.
+                  ;; The order of these tests matters greatly.
+                  (cond ((>= token 1000)
+                          (set-matched-slot 5 nil token))
+                        ((and (<= 1 token 31)
+                              (not (nth 3 time)))
+                          ;; Assume days come before months or years.
+                          (set-matched-slot 3 nil token))
+                        ((and (<= 1 token 12)
+                              (not (nth 4 time)))
+                          ;; Assume days come before years.
+                          (set-matched-slot 4 nil token))
+                        ((or (nth 5 time)
+                             (not two-digit-year?)
+                             (> token 100))
+                          (signal 'date-parse-error
+                                  (list "Unrecognized token" token)))
+                        ;; It's a two-digit year.
+                        ((>= token 50)
+                          ;; second half of the 20th century.
+                          (set-matched-slot 5 nil (+ 1900 token)))
+                        (t
+                          ;; first half of the 21st century.
+                          (set-matched-slot 5 nil (+ 2000 token)))))
+                ((setq match (assoc token parse-time-weekdays))
+                  (set-matched-slot 6 nil (cdr match)))
+                ((setq match (assoc token parse-time-months))
+                  (set-matched-slot 4 nil (cdr match)))
+                ((setq match (assoc token parse-time-zoneinfo))
+                  (set-matched-slot 8 nil (cadr match))
+                  (set-matched-slot 7 nil (caddr match)))
+                ((string-match "^[-+][0-9][0-9][0-9][0-9]$" token)
+                  ;; Numeric time zone.
+                  (set-matched-slot
+                    8 nil
+                    (* 60
+                       (+ (cl-parse-integer token :start 3 :end 5)
+                          (* 60 (cl-parse-integer token :start 1 :end 3)))
+                       (if (= (aref token 0) ?-) -1 1))))
+                ((string-match
+                  "^\\([0-9][0-9][0-9][0-9]\\)[-/]\\([0-9][0-9]?\\)[-/]\\([0-9][0-9]?\\)$"
+                  token)
+                  ;; ISO-8601-style date (YYYY-MM-DD).
+                  (set-matched-slot 5 1 token)
+                  (set-matched-slot 4 2 token)
+                  (set-matched-slot 3 3 token))
+                ((string-match
+                  "^\\([0-9][0-9]?\\)[-/]\\([0-9][0-9]?\\)[-/]\\([0-9][0-9][0-9][0-9]\\)$"
+                  token)
+                  ;; US date (MM-DD-YYYY), but we insist on four
+                  ;; digits for the year.
+                  (set-matched-slot 4 1 token)
+                  (set-matched-slot 3 2 token)
+                  (set-matched-slot 5 3 token))
+                ((string-match
+                  "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\):\\([0-9][0-9]\\)$"
+                  token)
+                  (set-matched-slot 2 1 token)
+                  (set-matched-slot 1 2 token)
+                  (set-matched-slot 0 3 token))
+                ((string-match "^\\([0-9][0-9]?\\):\\([0-9][0-9]\\)$" token)
+                  ;; Time without seconds.
+                  (set-matched-slot 2 1 token)
+                  (set-matched-slot 1 2 token)
+                  (set-matched-slot 0 nil 0))
+                ((member token '("am" "pm"))
+                  (unless (nth 2 time)
+                    (signal 'date-parse-error
+                            (list "Missing time" token)))
+                  (unless (<= (nth 2 time) 12)
+                    (signal 'date-parse-error
+                            (list "Time already past noon" token)))
+                  (when (equal token "pm")
+                    (cl-incf (nth 2 time) 12)))
+                (t
+                  (signal 'date-parse-error
+                          (list "Unrecognized token" token)))))))
+    time))
+
+;;;###autoload
+(cl-defgeneric parse-date (time-string &optional format)
+  "Parse TIME-STRING according to FORMAT, returning a list.
+The FORMAT value is a symbol that may be one of the following:
+
+   iso-8601 => parse the string according to the ISO-8601
+standard.  See `parse-iso8601-time-string'.
+
+   rfc822 => parse an RFC822 (old email) date, which allows
+two-digit years and internal '()' comments.  In dates of the form
+'11 Jan 12', the 11 is assumed to be the day, and the 12 is
+assumed to mean 2012.  Be sure you really want this; the format
+is more limited than most human-supplied dates.
+
+   rfc2822 => parse an RFC2822 (new email) date, which allows
+only four-digit years.  Again, this is a fairly restricted
+format, with fields required to be in a specified order and
+representation.
+
+   us-date => parse a US-style date, of the form MM/DD/YYYY, but
+allowing two-digit years.  In dates of the form '01/11/12', the 1
+is the month, 11 is the day, and the 12 is assumed to mean 2012.
+
+   nil => like us-date with two-digit years disallowed.
+
+Anything else is treated as iso-8601 if it looks similar, else
+us-date with two-digit years disallowed.
+
+   * For all formats except iso-8601, parsing is case-insensitive.
+
+   * Commas and whitespace are ignored.
+
+   * In date specifications, either '/' or '-' may be used to
+separate components, but all three components must be given.
+
+   * A date that starts with four digits is YYYY-MM-DD, ISO-8601
+style, but a date that ends with four digits is MM-DD-YYYY [at
+least in us-date format].
+
+   * Two digit years, when allowed, are in the 1900's when
+between 50 and 99 inclusive and in the 2000's when between 0 and
+49 inclusive.
+
+A `date-parse-error' is signalled when time values are duplicated,
+unrecognized, or out of range.  No consistency checks between
+fields are done.  For instance, the weekday is not checked to see
+that it corresponds to the date, and parse-date complains about
+the 32nd of March (or any other month) but blithely accepts the
+29th of February in non-leap years -- or the 31st of February in
+any year.
+
+The result is a list of (SEC MIN HOUR DAY MON YEAR DOW DST TZ),
+which can be accessed as a decoded-time defstruct (q.v.),
+e.g. `decoded-time-year' to extract the year, and turned into an
+Emacs timestamp by `encode-time'.  The values returned are
+identical to those of `decode-time', but any unknown values other
+than DST are returned as nil, and an unknown DST value is
+returned as -1.")
+
+(cl-defmethod parse-date (time-string (_format (eql iso-8601)))
+  (iso8601-parse time-string))
+
+(cl-defmethod parse-date (time-string (_format (eql rfc2822)))
+  (parse-date--x822 time-string nil))
+
+(cl-defmethod parse-date (time-string (_format (eql rfc822)))
+  (parse-date--x822 time-string t))
+
+(cl-defmethod parse-date (time-string (_format (eql us-date)))
+  (parse-date--default time-string t))
+
+(cl-defmethod parse-date (time-string (_format (eql nil)))
+  (parse-date--default time-string nil))
+
+(cl-defmethod parse-date (time-string _format)
+  ;; Re-dispatch after guessing the format.
+  (parse-date time-string (parse-date--guess-format time-string)))
+
+(provide 'parse-date)
+
+;;; parse-date.el ends here
diff --git a/test/lisp/calendar/parse-date-tests.el b/test/lisp/calendar/parse-date-tests.el
new file mode 100644
index 0000000000..bd2b344d71
--- /dev/null
+++ b/test/lisp/calendar/parse-date-tests.el
@@ -0,0 +1,247 @@
+;;; parse-date-tests.el --- Test suite for parse-date.el  -*- lexical-binding:t -*-
+
+;; Copyright (C) 2016-2021 Free Software Foundation, Inc.
+
+;; Author: Lars Ingebrigtsen <larsi@HIDDEN>
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;;; Code:
+
+(require 'ert)
+(require 'parse-date)
+
+(ert-deftest parse-date-tests ()
+  "Test basic parse-date functionality."
+
+  ;; Test tokenization.
+  (should (equal (parse-date--tokenize-string " ") '()))
+  (should (equal (parse-date--tokenize-string " a b") '("a" "b")))
+  (should (equal (parse-date--tokenize-string "a bbc dde") '("a" "bbc" "dde")))
+  (should (equal (parse-date--tokenize-string " , a 27 b,, c 14:32 ")
+                 '("a" 27 "b" "c" "14:32")))
+  ;; Some folding whitespace tests.
+  (should (equal (parse-date--tokenize-string " a b (end) c" 'first)
+                 '("a" "b")))
+  (should (equal (parse-date--tokenize-string "(quux)a (foo (bar)) b(baz)" t)
+                 '("a" "b")))
+  (should (equal (parse-date--tokenize-string "a b\\cde" 'all)
+                 ;; Strictly incorrect, but strictly unnecessary syntax.
+                 '("a" "b\\cde")))
+  (should (equal (parse-date--tokenize-string "a b\\ de" 'all)
+                 '("a" "b\\ de")))
+  (should (equal (parse-date--tokenize-string "a \\de \\(f" 'all)
+                 '("a" "\\de" "\\(f")))
+
+  ;; Start with some compatible RFC822 dates.
+  (dolist (format '(nil rfc822 rfc2822))
+    (should (equal (parse-date "Mon, 22 Feb 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "22 Feb 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 nil -1 3600)))
+    (should (equal (parse-date "Mon, 22 February 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "Mon, 22 feb 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "Monday, 22 february 2016 19:35:42 +0100" format)
+                   '(42 35 19 22 2 2016 1 -1 3600)))
+    (should (equal (parse-date "Monday, 22 february 2016 19:35:42 PST" format)
+                   '(42 35 19 22 2 2016 1 nil -28800)))
+    (should (equal (parse-date "Friday, 21 Sep 2018 13:47:58 PDT" format)
+                   '(58 47 13 21 9 2018 5 t -25200)))
+    (should (equal (parse-date "Friday, 21 Sep 2018 13:47:58" format)
+                   '(58 47 13 21 9 2018 5 -1 nil))))
+  ;; These are not allowed by the default format.
+  (should (equal (parse-date "22 Feb 16 19:35:42 +0100" 'rfc822)
+                 '(42 35 19 22 2 2016 nil -1 3600)))
+  (should (equal (parse-date "22 Feb 96 19:35:42 +0100" 'rfc822)
+                 '(42 35 19 22 2 1996 nil -1 3600)))
+  ;; Try them again with comments.
+  (should (equal (parse-date "22 Feb (today) 16 19:35:42 +0100" 'rfc822)
+                 '(42 35 19 22 2 2016 nil -1 3600)))
+  (should (equal (parse-date "22 Feb 96 (long ago) 19:35:42 +0100" 'rfc822)
+                 '(42 35 19 22 2 1996 nil -1 3600)))
+  (should (equal (parse-date
+                  "Friday, 21 Sep(comment \\) with \\( parens)18 19:35:42"
+                  'rfc822)
+                 '(42 35 19 21 9 2018 5 -1 nil)))
+  (should (equal (parse-date
+                  "Friday, 21 Sep 18 19:35:42 (unterminated comment"
+                  'rfc822)
+                 '(42 35 19 21 9 2018 5 -1 nil)))
+
+  ;; Test some RFC822 error cases
+  (dolist (test '(("33 1 2022" ("Slot out of range" day 33 1 31))
+                  ("0 1 2022" ("Slot out of range" day 0 1 31))
+                  ("1 1 2020 2021" ("Expected an alphabetic month" 1))
+                  ("1 Jan 2020 2021" ("Expected a time" 2021))
+                  ("1 Jan 2020 20:21 2000" ("Expected a timezone" 2000))
+                  ("1 Jan 2020 20:21 +0200 33" ("Extra token(s)" 33))))
+    (should (equal (condition-case err (parse-date (car test) 'rfc822)
+                     (date-parse-error (cdr err)))
+                   (cadr test))))
+
+  ;; And these are not allowed by rfc822 because of missing time.
+  (should (equal (parse-date "Friday, 21 Sep 2018" nil)
+                 '(nil nil nil 21 9 2018 5 -1 nil)))
+  (should (equal (parse-date "22 Feb 2016 +0100" nil)
+                 '(nil nil nil 22 2 2016 nil -1 3600)))
+
+  ;; Test the default format with both hyphens and slashes in dates.
+  (dolist (case '(;; Month can be numeric if date uses hyphens/slashes.
+                  ("Friday, 2018-09-21" (nil nil nil 21 9 2018 5 -1 nil))
+                  ;; Year can come last if four digits.
+                  ("Friday, 9-21-2018" (nil nil nil 21 9 2018 5 -1 nil))
+                  ;; Day of week is optional
+                  ("2018-09-21" (nil nil nil 21 9 2018 nil -1 nil))
+                  ;; The order of date, time, etc., does not matter.
+                  ("13:47:58, +0100, 2018-09-21, Friday"
+                   (58 47 13 21 9 2018 5 -1 3600))
+                  ;; Month, day, or both, can be a single digit.
+                  ("Friday, 2018-9-08" (nil nil nil 8 9 2018 5 -1 nil))
+                  ("Friday, 2018-09-8" (nil nil nil 8 9 2018 5 -1 nil))
+                  ("Friday, 2018-9-8" (nil nil nil 8 9 2018 5 -1 nil))))
+    (let ((string (car case))
+          (expected (cadr case)))
+      ;; Test with hyphens.
+      (should (equal (parse-date string nil) expected))
+      (while (string-match "-" string)
+        (setq string (replace-match "/" t t string)))
+      ;; Test with slashes.
+      (should (equal (parse-date string nil) expected))))
+
+  ;; Time by itself is recognized as such.
+  (should (equal (parse-date "03:47:58" nil)
+                 '(58 47 3 nil nil nil nil -1 nil)))
+  ;; A leading zero for hours is optional.
+  (should (equal (parse-date "3:47:58" nil)
+                 '(58 47 3 nil nil nil nil -1 nil)))
+  ;; Missing seconds are assumed to be zero.
+  (should (equal (parse-date "3:47" nil)
+                 '(0 47 3 nil nil nil nil -1 nil)))
+  ;; AM/PM are understood (in any case combination).
+  (dolist (am '(am AM Am))
+    (should (equal (parse-date (format "3:47 %s" am) nil)
+                   '(0 47 3 nil nil nil nil -1 nil))))
+  (dolist (pm '(pm PM Pm))
+    (should (equal (parse-date (format "3:47 %s" pm) nil)
+                   '(0 47 15 nil nil nil nil -1 nil))))
+
+  ;; Ensure some cases fail.
+  (should-error (parse-date "22 Feb 196" 'us-date))
+  (should-error (parse-date "22 Feb 16 19:35:42" nil))
+  (should-error (parse-date "22 Feb 96 19:35:42" nil))	;; two-digit year
+  (should-error (parse-date "2 Feb 2021 1996" nil))	;; duplicate year
+
+  (dolist (test '(("22 Feb 196" 'us-date	;; bad year
+                   ("Unrecognized token" 196))
+                  ("22 Feb 16 19:35:42" nil	;; two-digit year
+                   ("Unrecognized token" 16))
+                  ("22 Feb 96 19:35:42" nil	;; two-digit year
+                   ("Unrecognized token" 96))
+                  ("2 Feb 2021 1996" nil
+                   ("Duplicate slot value" year 1996))
+                  ("2020-1-1 2021" nil
+                   ("Duplicate slot value" year 2021))
+                  ("22 Feb 196" 'us-date
+                   ("Unrecognized token" 196))
+                  ("22 Feb 16 19:35:42" nil
+                   ("Unrecognized token" 16))
+                  ("22 Feb 96 19:35:42" nil
+                   ("Unrecognized token" 96))
+                  ("2 Feb 2021 1996" nil
+                   ("Duplicate slot value" year 1996))
+                  ("2020-1-1 30" nil
+                   ("Unrecognized token" 30))
+                  ("2020-1-1 12" nil
+                   ("Unrecognized token" 12))
+                  ("15:47 15:15" nil
+                   ("Duplicate slot value" hour "15:15"))
+                  ("2020-1-1 +0800 -0800" t
+                   ("Duplicate slot value" zone -28800))
+                  ("15:47 PM" nil
+                   ("Time already past noon" "pm"))
+                  ("15:47 AM" nil
+                   ("Time already past noon" "am"))
+                  ("2020-1-1 PM" nil
+                   ("Missing time" "pm"))
+                  ;; Range tests
+                  ("2021-12-32" nil
+                   ("Slot out of range" day "2021-12-32" 1 31))
+                  ("2021-12-0" nil
+                   ("Slot out of range" day "2021-12-0" 1 31))
+                  ("2021-13-3" nil
+                   ("Slot out of range" month "2021-13-3" 1 12))
+                  ("0000-12-3" nil
+                   ("Slot out of range" year "0000-12-3" 1 9999))
+                  ("20021 Dec 3" nil
+                   ("Slot out of range" year 20021 1 9999))
+                  ("24:21:14" nil
+                   ("Slot out of range" hour "24:21:14" 0 23))
+                  ("14:60:21" nil
+                   ("Slot out of range" minute "14:60:21" 0 59))
+                  ("14:21:61" nil
+                   ("Slot out of range" second "14:21:61" 0 60))))
+    (should (equal (condition-case err (parse-date (car test) (cadr test))
+                     (date-parse-error (cdr err)))
+                   (caddr test))))
+  (should (equal (parse-date "14:21:60" nil)	;; a leap second!
+                 '(60 21 14 nil nil nil nil -1 nil)))
+
+  ;; Test ISO-8601 dates.
+  (dolist (format '(t iso-8601))
+    (should (equal (parse-date "1998-09-12T12:21:54-0200" format)
+                   '(54 21 12 12 9 1998 nil nil -7200)))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (encode-time
+                      (parse-date "1998-09-12T12:21:54-0230" format))
+                    t)
+                   "1998-09-12 14:51:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (encode-time
+                      (parse-date "1998-09-12T12:21:54-02:00" format))
+                    t)
+                   "1998-09-12 14:21:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (encode-time
+                      (parse-date "1998-09-12T12:21:54-02" format))
+                    t)
+                   "1998-09-12 14:21:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (encode-time
+                      (parse-date "1998-09-12T12:21:54+0230" format))
+                    t)
+                   "1998-09-12 09:51:54"))
+    (should (equal (format-time-string
+                    "%Y-%m-%d %H:%M:%S"
+                    (encode-time
+                     (parse-date "1998-09-12T12:21:54+02" format))
+                    t)
+                   "1998-09-12 10:21:54"))
+    (should (equal (parse-date "1998-09-12T12:21:54Z" t)
+                   '(54 21 12 12 9 1998 nil nil 0)))
+    (should (equal (parse-date "1998-09-12T12:21:54" format)
+                   '(54 21 12 12 9 1998 nil -1 nil)))))
+
+(provide 'parse-date-tests)
+
+;;; parse-date-tests.el ends here

--YAYPog+/V1--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 29 Dec 2021 15:20:02 +0000
Resent-Message-ID: <handler.52209.B52209.164079115722656 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164079115722656
          (code B ref 52209); Wed, 29 Dec 2021 15:20:02 +0000
Received: (at 52209) by debbugs.gnu.org; 29 Dec 2021 15:19:17 +0000
Received: from localhost ([127.0.0.1]:49929 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n2ajU-0005tL-OK
	for submit <at> debbugs.gnu.org; Wed, 29 Dec 2021 10:19:16 -0500
Received: from quimby.gnus.org ([95.216.78.240]:42606)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n2ajT-0005t6-1p
 for 52209 <at> debbugs.gnu.org; Wed, 29 Dec 2021 10:19:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=RyXnmiqWWuZuzY/0naw37kJGm5jDH/yDxblvHowaWiw=; b=KWSbeHnoMq178PGSA25ZrNzs9J
 TacF4rBJ4aa6r7aEacDxHrzG2drtg4rlCalifRo1E/5TdWGUlsW0eYRg2URD0ETYebEb3PCrU8kjx
 3Z460KEoyWcv9WLevGeZ9f9X/KaLDkuvYPLgv59KFuLPawqo3eRdy02B/9syXoTDjf+Q=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n2ajI-00075t-MB; Wed, 29 Dec 2021 16:19:07 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN> <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEW4t7VGR0qHhXv/
 ///x/LKyAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+UMHQ46Mgo+4CEAAAGxSURBVCjPnZHBitswEIZ/
 RFMUHQuGdk9uaIKjpwhlL+0pBY9xdVoMhsRP4Zq2JDotJQohJ1XUxtZTdrx9g+qkb/5h5p8Z4H/e
 InfFiFY1NjJc3B+OpTYG4PXFmRGQKnoI2YqwpvrpFFsOyXerhOr9SXtAxO0vR/XB8h9ilSREx0Zn
 2QxvtrOC7jCn3bUzUfnAeUm5uNx9qmK8MRST6dsMw1whKfrwA6maRAsiMnO7GH7vZiAqYlXFA5t6
 W56PH/wo1MiwLte0wKQsuKn2S5PQs7IdKyJdmiuNme86hrDcOwrSZtwnevu0psMQKp60r05+TWW8
 bDTSqbIzNNvYYzVVnxnMYYoDBIJsWbHDOI8K2T5QOdnR8sLw+O3KaWLzk4X2u3e1CTZq3mjj9gnD
 7hSg+i914Zy5Ba+h6MjzkOE6G5zpExW6L6UMI8Oxzl9tykzrgJ52fYkpV21nX2Avmhyru8VAO7sX
 4gKpI66uu7GpOzqtMWjM8ID3Ywre3+zW8glTRNk9ppkQEBwbFsfi/nweRLsCcj7b13JqFOcjd0Su
 7Cu2mf5b/K2vPipWXqAh4yXwF3+OrVImlzwHAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTEyLTI5
 VDE0OjU4OjQ5KzAwOjAwLcSN4wAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0xMi0yOVQxNDo1ODo0
 OSswMDowMFyZNV8AAAAASUVORK5CYII=
X-Now-Playing: Four Tet's _Paws_: "No More Mosquitoes (600m 6ip remix)"
Date: Wed, 29 Dec 2021 16:19:03 +0100
In-Reply-To: <25035.12991.328986.987982@HIDDEN> (Bob Rogers's message
 of "Tue, 28 Dec 2021 10:52:31 -0500")
Message-ID: <87o84z782g.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Bob Rogers <rogers-emacs@HIDDEN> writes: > I am
 currently working on broadening what the parser will accept, > though I think
 it is close to a usable state. Makes sense to me. Perhaps Paul has some
 comments; added to the CCs. 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

>    I am currently working on broadening what the parser will accept,
> though I think it is close to a usable state.

Makes sense to me.  Perhaps Paul has some comments; added to the CCs.

> +(cl-defmethod parse-date (time-string (_format (eql iso-8601)))

By the way, this should be

(cl-defmethod parse-date (time-string (_format (eql 'iso-8601)))

now -- we're transitioning to eval-ing the eql specifier.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 29 Dec 2021 19:30:02 +0000
Resent-Message-ID: <handler.52209.B52209.164080619431447 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>, Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164080619431447
          (code B ref 52209); Wed, 29 Dec 2021 19:30:02 +0000
Received: (at 52209) by debbugs.gnu.org; 29 Dec 2021 19:29:54 +0000
Received: from localhost ([127.0.0.1]:50398 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n2ee2-0008B9-Av
	for submit <at> debbugs.gnu.org; Wed, 29 Dec 2021 14:29:54 -0500
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39500)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1n2ee0-0008As-M2
 for 52209 <at> debbugs.gnu.org; Wed, 29 Dec 2021 14:29:53 -0500
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6D4A91600FC;
 Wed, 29 Dec 2021 11:29:46 -0800 (PST)
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 rfE8RBBswkLC; Wed, 29 Dec 2021 11:29:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id BF903160142;
 Wed, 29 Dec 2021 11:29:44 -0800 (PST)
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 Y2Lqi8anLUWk; Wed, 29 Dec 2021 11:29:44 -0800 (PST)
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 913931600FC;
 Wed, 29 Dec 2021 11:29:44 -0800 (PST)
Message-ID: <cedd5301-0320-29a1-fdb8-39ec2bf267e9@HIDDEN>
Date: Wed, 29 Dec 2021 11:29:44 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Content-Language: en-US
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN> <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN> <87o84z782g.fsf@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <87o84z782g.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.4 (---)

On 12/29/21 07:19, Lars Ingebrigtsen wrote:
> Bob Rogers <rogers-emacs@HIDDEN> writes:
> 
>>     I am currently working on broadening what the parser will accept,
>> though I think it is close to a usable state.
> 
> Makes sense to me.  Perhaps Paul has some comments; added to the CCs.

My first comment is "be careful what you're getting into" :-). I'm 
trying to retire from date-parsing as its users are never happy and 
rightly so. But here goes. I took a quick look at 
<https://bugs.gnu.org/52209#58> and have a few comments.

* Calling it parse-date is a bit confusing, as it parses both dates and 
times. I suggest calling it parse-timestamp or parse-date-time instead. 
(I know the existing package is called parse-time but we can't fix that.)

* If the package is called X, the error should be called X-error. 
Currently the package is called parse-date and the error is called 
date-parse-error, which is confusing.

* The patch should also modify the comment at the start of parse-time.el 
to indicate parse-date-time as another possibility.

* I suggest preferring the symbol 'rfc-email' for parsing email-related 
dates, for consistency with the --rfc-email option of GNU 'date'. This 
should use the current RFC (5322 now, perhaps updated later). I suppose 
you could also advertise 'rfc-822' for strict RFC 822 conformance, and 
similarly 'rfc2822' for strict 2822 conformance, but I expect these 
alternatives would be less useful in practice.


> +   nil => like us-date with two-digit years disallowed.

This doesn't sound like a good default. For example, it completely 
mishandles dates in Brazil, which use DD/MM/YYYY format.

> +Anything else is treated as iso-8601 if it looks similar, else
> +us-date with two-digit years disallowed.

This might be a better default (for nil), but it should have an explicit 
name other than nil.

> +   * For all formats except iso-8601, parsing is case-insensitive.

It's pretty common for ISO 8601 parsers to be case-insensitive. For 
example, Java's OffsetDateTime.parse(CharSequence) allow both lower and 
upper case T and Z. Perhaps some people need strict ISO 8601 parsers, 
but I imagine a more-generous parser would be more useful. So you could 
have iso-8601 and iso-8601-strict; or you could have a strictness arg; 
or something like that.

> +   * Commas and whitespace are ignored.

This is quite wrong for some formats, if you want to be strict. And even 
if not, commas are part of ISO 8601 format and can't be ignored if I 
understand what you mean by "ignored".


> +   * Two digit years, when allowed, are in the 1900's when
> +between 50 and 99 inclusive and in the 2000's when between 0 and
> +49 inclusive.

This disagrees with the POSIX standard for 'date' (supported by GNU 
'date'), which says 69-99 are treated as 1969-1999 and 00-68 are treated 
as 2000-2068. I suggest going with the POSIX heuristic if you're going 
to use a fixed heuristic for dates at all.

Better might be to have an optional argument of context specifying the 
default time for incomplete timestamps. You can use that the context to 
fill in more-significant parts that are missing. E.g., if the year is 
missing, you take it from the context; if the century is missing, you 
take that from the context. The default context would be empty, i.e., 
missing years or centuries would be an error.

For more formats that need parsing, see:

https://en.wikipedia.org/wiki/Date_format_by_country
https://metacpan.org/search?q=datetime%3A%3Aformat

You don't need to support them all now, but you should take a look at 
what's out there and make sure the API can be extended to handle them.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 29 Dec 2021 22:02:02 +0000
Resent-Message-ID: <handler.52209.B52209.164081527124198 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Paul Eggert <eggert@HIDDEN>
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164081527124198
          (code B ref 52209); Wed, 29 Dec 2021 22:02:02 +0000
Received: (at 52209) by debbugs.gnu.org; 29 Dec 2021 22:01:11 +0000
Received: from localhost ([127.0.0.1]:50532 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n2h0M-0006I4-GU
	for submit <at> debbugs.gnu.org; Wed, 29 Dec 2021 17:01:10 -0500
Received: from rgrjr.com ([69.164.211.47]:39322)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n2h0K-0006Hr-01
 for 52209 <at> debbugs.gnu.org; Wed, 29 Dec 2021 17:01:05 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id D81351D6BB2;
 Wed, 29 Dec 2021 22:01:15 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id F02D76017A; 
 Wed, 29 Dec 2021 17:01:02 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25036.55965.149104.938898@HIDDEN>
Date: Wed, 29 Dec 2021 17:01:01 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <cedd5301-0320-29a1-fdb8-39ec2bf267e9@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <cedd5301-0320-29a1-fdb8-39ec2bf267e9@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Paul Eggert <eggert@HIDDEN>
   Date: Wed, 29 Dec 2021 11:29:44 -0800

   On 12/29/21 07:19, Lars Ingebrigtsen wrote:
   > Bob Rogers <rogers-emacs@HIDDEN> writes:
   > 
   >>     I am currently working on broadening what the parser will accept,
   >> though I think it is close to a usable state.
   > 
   > Makes sense to me.  Perhaps Paul has some comments; added to the CCs.

   My first comment is "be careful what you're getting into" :-).  I'm
   trying to retire from date-parsing as its users are never happy and
   rightly so.

No worries; I have spent more of my career than I like to think about
dealing with date/time issues, so I know what a can of worms I am in the
process of opening.

   But here goes.  I took a quick look at
   <https://bugs.gnu.org/52209#58> and have a few comments.

They are greatly appreciated; thank you.

   * Calling it parse-date is a bit confusing, as it parses both dates and 
   times. I suggest calling it parse-timestamp or parse-date-time instead. 
   (I know the existing package is called parse-time but we can't fix that.)

Lars originally suggested parse-time, but there's already a
parse-time-tests.el, so I switched to parse-date so I could use
parse-date-tests.el to correspond.  So the namespace is already crowded.
But I would be OK with either of those alternatives.  Since it will
actually give you either date or time, or both, parse-date-time might
make more sense.

   * If the package is called X, the error should be called X-error. 
   Currently the package is called parse-date and the error is called 
   date-parse-error, which is confusing.

My thought was that for the "parse-date" function, the verb should come
before the noun, and in "date-parse-error", the "date" is an adjective
further modifying "parse error."  But I think I'm way fussier about
these things than anybody I know, so your point is well taken.

   * The patch should also modify the comment at the start of
   parse-time.el to indicate parse-date-time as another possibility.

I took that as a late-stage task, something to do alongside updating
Elisp documentation.  (Which I haven't even begun to look at.)

   * I suggest preferring the symbol 'rfc-email' for parsing
   email-related dates, for consistency with the --rfc-email option of
   GNU 'date'. This should use the current RFC (5322 now, perhaps
   updated later). 

I started with RFC822 and RFC2822 because I had copies of these lying
around; you're right that I should have looked for more recent
standards.  And using rfc-email as a synonym for the latest version is a
good idea.

   I suppose you could also advertise 'rfc-822' for strict RFC 822
   conformance, and similarly 'rfc2822' for strict 2822 conformance, but
   I expect these alternatives would be less useful in practice.

Anyone parsing email headers would need their date parser to support
RFC822 in case they encountered very old emails, but (since later
standards are backward-compatible) it's not clear what supporting
intermediate standards would buy.

   > +   nil => like us-date with two-digit years disallowed.

   This doesn't sound like a good default. For example, it completely 
   mishandles dates in Brazil, which use DD/MM/YYYY format.

I subsequently added a euro-date format for DD/MM (with various lengths
of years).

   > +Anything else is treated as iso-8601 if it looks similar, else
   > +us-date with two-digit years disallowed.

   This might be a better default (for nil), but it should have an explicit 
   name other than nil.

Suggestions?

   > +   * For all formats except iso-8601, parsing is case-insensitive.

   It's pretty common for ISO 8601 parsers to be case-insensitive. For 
   example, Java's OffsetDateTime.parse(CharSequence) allow both lower and 
   upper case T and Z. Perhaps some people need strict ISO 8601 parsers, 
   but I imagine a more-generous parser would be more useful. So you could 
   have iso-8601 and iso-8601-strict; or you could have a strictness arg; 
   or something like that.

Actually, I am handing those off to the existing iso8601-parse code,
which doesn't like lowercase T (at least).

   > +   * Commas and whitespace are ignored.

   This is quite wrong for some formats, if you want to be strict.  And
   even if not, commas are part of ISO 8601 format and can't be ignored
   if I understand what you mean by "ignored".

I see I need to clarify the docstring to state that these other bulleted
comments also do not apply to ISO-8601 dates.

   > +   * Two digit years, when allowed, are in the 1900's when
   > +between 50 and 99 inclusive and in the 2000's when between 0 and
   > +49 inclusive.

   This disagrees with the POSIX standard for 'date' (supported by GNU 
   'date'), which says 69-99 are treated as 1969-1999 and 00-68 are treated 
   as 2000-2068. I suggest going with the POSIX heuristic if you're going 
   to use a fixed heuristic for dates at all.

I was just following the existing parse-time-string heuristic.  So which
do you think should rule:  POSIX or parse-time-string compatibility?

   Better might be to have an optional argument of context specifying the 
   default time for incomplete timestamps. You can use that the context to 
   fill in more-significant parts that are missing. E.g., if the year is 
   missing, you take it from the context; if the century is missing, you 
   take that from the context. The default context would be empty, i.e., 
   missing years or centuries would be an error.

Again, I'm just doing what parse-time-string is doing, namely leaving
everything that is not specified nil, and letting the caller decide how
to apply defaults.  The only exception is when time is specified without
seconds; in that case, the seconds are set to zero (which is also
compatible with parse-time-string).

   And even defaulting from context is not straightforward:  If given a
date without a year that is not today, should that be in the future or
in the past?  There's a can of worms I don't need to touch.  ;-}

   For more formats that need parsing, see:

   https://en.wikipedia.org/wiki/Date_format_by_country
   https://metacpan.org/search?q=datetime%3A%3Aformat

   You don't need to support them all now, but you should take a look at 
   what's out there and make sure the API can be extended to handle them.

Excellent; thank you!  I have been looking at date parsing module
documentation but so far the ones I've seen have not been very clear
about what they actually accept.

					-- Bob Rogers
					   http://www.rgrjr.com/




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 30 Dec 2021 05:33:01 +0000
Resent-Message-ID: <handler.52209.B52209.16408423769811 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Paul Eggert <eggert@HIDDEN>, Lars Ingebrigtsen <larsi@HIDDEN>, 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16408423769811
          (code B ref 52209); Thu, 30 Dec 2021 05:33:01 +0000
Received: (at 52209) by debbugs.gnu.org; 30 Dec 2021 05:32:56 +0000
Received: from localhost ([127.0.0.1]:50893 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n2o3c-0002YB-8U
	for submit <at> debbugs.gnu.org; Thu, 30 Dec 2021 00:32:56 -0500
Received: from rgrjr.com ([69.164.211.47]:39408)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n2o3Y-0002Xz-0y
 for 52209 <at> debbugs.gnu.org; Thu, 30 Dec 2021 00:32:54 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 186471D6BB2;
 Thu, 30 Dec 2021 05:33:04 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 5D7785FE2E; 
 Thu, 30 Dec 2021 00:32:51 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cNrU+IIpKv"
Content-Transfer-Encoding: 7bit
Message-ID: <25037.17537.313178.136412@HIDDEN>
Date: Thu, 30 Dec 2021 00:32:49 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <25036.55965.149104.938898@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <cedd5301-0320-29a1-fdb8-39ec2bf267e9@HIDDEN>
 <25036.55965.149104.938898@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)


--cNrU+IIpKv
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   From: Bob Rogers <rogers-emacs@HIDDEN>
   Date: Wed, 29 Dec 2021 17:01:01 -0500

      From: Paul Eggert <eggert@HIDDEN>
      Date: Wed, 29 Dec 2021 11:29:44 -0800

      * I suggest preferring the symbol 'rfc-email' for parsing
      email-related dates, for consistency with the --rfc-email option
      of GNU 'date'. This should use the current RFC (5322 now, perhaps
      updated later).

The only update I saw at https://www.rfc-editor.org (RFC6854) only
affects addressing syntax.

   I started with RFC822 and RFC2822 because I had copies of these lying
   around; you're right that I should have looked for more recent
   standards.  And using rfc-email as a synonym for the latest version is a
   good idea.

FYI, there is no substantial difference between RFC2822 and RFC5322 in
date/time syntax.  They hide the whitespace in different productions,
but the end result is the same.  So I'll change the format name to
rfc5322 and add rfc-email as a synonym.

					-- Bob


--cNrU+IIpKv
Content-Type: text/x-patch
Content-Description: 
Content-Disposition: inline;
	filename="email-date-spec-changes.patch"
Content-Transfer-Encoding: 7bit

--- rfc2822-date.text	2021-12-30 00:15:38.588023882 -0500
+++ rfc5322-date.text	2021-12-29 23:41:39.492629354 -0500
@@ -1,15 +1,15 @@
 
 3.3. Date and Time Specification
 
- Date and time occur in several header fields. This section
+ Date and time values occur in several header fields. This section
  specifies the syntax for a full date and time specification. Though
  folding white space is permitted throughout the date-time
  specification, it is RECOMMENDED that a single space be used in each
  place that FWS appears (whether it is required or optional); some older
- implementations may not interpret other occurrences of folding white
+ implementations will not interpret longer sequences of folding white
  space correctly.
 
- date-time = [ day-of-week "," ] date FWS time [CFWS]
+ date-time = [ day-of-week "," ] date time [CFWS]
 
  day-of-week = ([FWS] day-name) / obs-day-of-week
 
@@ -18,17 +18,15 @@
 
  date = day month year
 
- day = ([FWS] 1*2DIGIT) / obs-day
+ day = ([FWS] 1*2DIGIT FWS) / obs-day
 
- month = (FWS month-name FWS) / obs-month
-
- month-name = "Jan" / "Feb" / "Mar" / "Apr" /
+ month = "Jan" / "Feb" / "Mar" / "Apr" /
  "May" / "Jun" / "Jul" / "Aug" /
  "Sep" / "Oct" / "Nov" / "Dec"
 
- year = 4*DIGIT / obs-year
+ year = (FWS 4*DIGIT FWS) / obs-year
 
- time = time-of-day FWS zone
+ time = time-of-day zone
 
  time-of-day = hour ":" minute [ ":" second ]
 
@@ -38,7 +36,7 @@
 
  second = 2DIGIT / obs-second
 
- zone = (( "+" / "-" ) 4DIGIT) / obs-zone
+ zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
 
  The day is the numeric day of the month. The year is any numeric year
  1900 or later.
@@ -54,28 +52,27 @@
  day is ahead of (i.e., east of) or behind (i.e., west of) Universal
  Time. The first two digits indicate the number of hours difference from
  Universal Time, and the last two digits indicate the number of
- minutes difference from Universal Time. (Hence, +hhmm means
+ additional minutes difference from Universal Time. (Hence, +hhmm means
  +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) minutes). The
  form "+0000" SHOULD be used to indicate a time zone at Universal
  Time. Though "-0000" also indicates Universal Time, it is used to
  indicate that the time was generated on a system that may be in a local
- time zone other than Universal Time and therefore indicates that the
- date-time contains no
+ time zone other than Universal Time and that the date-time contains no
  information about the local time zone.
 
  A date-time specification MUST be semantically valid. That is, the
- day-of-the-week (if included) MUST be the day implied by the date, the
+ day-of-week (if included) MUST be the day implied by the date, the
  numeric day-of-month MUST be between 1 and the number of days allowed
  for the specified month (in the specified year), the time-of-day MUST
  be in the range 00:00:00 through 23:59:60 (the number of seconds
- allowing for a leap second; see [STD12]), and the zone MUST be within
- the range -9959 through +9959.
+ allowing for a leap second; see [RFC1305]), and the last two digits of
+ the zone MUST be within the range 00 through 59.
 
 4.3. Obsolete Date and Time
 
  The syntax for the obsolete date format allows a 2 digit year in the
- date field and allows for a list of alphabetic time zone specifications
- that were used in earlier versions of this standard. It also
+ date field and allows for a list of alphabetic time zone specifiers
+ that were used in earlier versions of this specification. It also
  permits comments and folding white space between many of the tokens.
 
  obs-day-of-week = [CFWS] day-name [CFWS]
@@ -138,3 +135,8 @@
  and "Z" is equivalent to "+0000". However, because of the error in
  [RFC0822], they SHOULD all be considered equivalent to "-0000" unless
  there is out-of-band information confirming their meaning.
+
+ Other multi-character (usually between 3 and 5) alphabetic time zones
+ have been used in Internet messages. Any such time zone whose meaning
+ is not known SHOULD be considered equivalent to "-0000" unless there is
+ out-of-band information confirming their meaning.

--cNrU+IIpKv--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 30 Dec 2021 21:09:01 +0000
Resent-Message-ID: <handler.52209.B52209.164089852710565 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164089852710565
          (code B ref 52209); Thu, 30 Dec 2021 21:09:01 +0000
Received: (at 52209) by debbugs.gnu.org; 30 Dec 2021 21:08:47 +0000
Received: from localhost ([127.0.0.1]:54714 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n32fH-0002kL-Dd
	for submit <at> debbugs.gnu.org; Thu, 30 Dec 2021 16:08:47 -0500
Received: from rgrjr.com ([69.164.211.47]:39642)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n32fF-0002kB-14
 for 52209 <at> debbugs.gnu.org; Thu, 30 Dec 2021 16:08:45 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id F3C241D6BA4;
 Thu, 30 Dec 2021 21:08:56 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 7BE695FE2E; 
 Thu, 30 Dec 2021 16:08:44 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25038.8156.470964.935330@HIDDEN>
Date: Thu, 30 Dec 2021 16:08:44 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87o84z782g.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Wed, 29 Dec 2021 16:19:03 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   . . .

   > +(cl-defmethod parse-date (time-string (_format (eql iso-8601)))

   By the way, this should be

   (cl-defmethod parse-date (time-string (_format (eql 'iso-8601)))

   now -- we're transitioning to eval-ing the eql specifier.

Thanks for the heads-up; now done.

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 01 Jan 2022 14:48:01 +0000
Resent-Message-ID: <handler.52209.B52209.164104844429941 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164104844429941
          (code B ref 52209); Sat, 01 Jan 2022 14:48:01 +0000
Received: (at 52209) by debbugs.gnu.org; 1 Jan 2022 14:47:24 +0000
Received: from localhost ([127.0.0.1]:57962 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n3ffH-0007mr-UG
	for submit <at> debbugs.gnu.org; Sat, 01 Jan 2022 09:47:24 -0500
Received: from quimby.gnus.org ([95.216.78.240]:44622)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n3ffG-0007mb-2E
 for 52209 <at> debbugs.gnu.org; Sat, 01 Jan 2022 09:47:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
 :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=4YqX9e3780QDP8Dt2C2RrxY0Ww6mp+IwlI8UnfkGLLs=; b=t8YC5p4dxo4tA0t3ujX9kVFjGs
 Tn0Z/te1Hwg22U7cUffih0XOwY9O3O+po59ffjILSxsL5iRKvxFv3EAh5EsYOWJss9wdJlfOah1Tk
 UF4XNEg5hos0LJME96HZkaTVLCsZuFxXB4Sx0CFb14S60vLqwdusowZq5oKDHxXOJs0E=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n3ff5-0003qt-L7; Sat, 01 Jan 2022 15:47:14 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN> <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN> <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEXk284dFxavnJOM
 dm5bQz6Yg3v///+dUZfgAAAAAWJLR0QGYWa4fQAAAAd0SU1FB+YBAQ4jCUT+/iUAAAGbSURBVDjL
 lZO7dsIwDIZd2gfAwd1bE+8lUva6FjuHJO//KtXFhgBlqBZz9EW3X8I59+If7MOJfT6Cr2dgqyA/
 gvdnIDwDXsEffm1rs3a06K8VyOQ9ARj6ZvAqP3bZw7BQ9oFy6/dNuiAfjjEihRxQQFeBshhhgH6I
 ErJzJhWFeYBzZFuiglDBSOo1O9RBWKoQ9+MdOJmG5tnYk2u/8sEqUQVbk+pn5d8r2Bk4iqOBpq8+
 7Ei1xtz01WeQiE0SQBWYhpyr/0l0Yn4LgnhISmEDrwYkV5FME1ZgGoYio6RpvBZvYCI2CTzcAK6O
 BYH9qW63nVuJCUbgdD3dgsA1VDG8A02umcgrcn07vkGFIkJuQsC+nZROgaEAwcizuPlybIMU4MuC
 5cw7uaSSWdhfRhmSl2IgtxMiWJZFhTFQO5EAaw7J2s3aCQcUgGk8x4Sgm+WDzcLqbB1vM7qa+yAD
 lBAEdpLMESDnzv1MPR4LEd/9uwLZMuuNSDOyPzDoGkgmnP01gr+CuAfkgWGcYLrcsLMn3RzpGgxP
 wKP9H/wCro6L3ezBcMcAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDEtMDFUMTQ6MzU6MDkrMDA6
 MDDso93NAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTAxLTAxVDE0OjM1OjA5KzAwOjAwnf5lcQAA
 AABJRU5ErkJggg==
X-Now-Playing: Heidi Berry's _Miracle_: "The Mountain"
Date: Sat, 01 Jan 2022 15:47:05 +0100
In-Reply-To: <25038.8156.470964.935330@HIDDEN> (Bob Rogers's message
 of "Thu, 30 Dec 2021 16:08:44 -0500")
Message-ID: <87lezz5x92.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: I wonder whether we should look at this another way. We
 currently
 have two built-in date parsing functions in Emacs: `iso8601-parse' and
 `parse-time-string', 
 and both parse strings according to well-d [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

I wonder whether we should look at this another way.  We currently have
two built-in date parsing functions in Emacs: `iso8601-parse' and
`parse-time-string', and both parse strings according to well-defined
standards (ISO8601 and RFC822bis, respectively).  (But the latter's doc
string didn't explicitly say so, so people thought it was a DWIM
parser.)

DWIM date parsing is impossible, though, because there's an infinite
variety of date formats out there, and variants are ambiguous.  And
adding an infinite number of date parsers to Emacs doesn't seem
attractive.

So how about just adding something that makes parsing common date
formats easier, but without being DWIM or being hard-coded.  Like:

(parse-time "%Y/%m/%d" "2021/01/01")
=3D> (nil nil nil 01 01 2021)

or something.

It could be regexp-ey

(parse-time "%Y.*%m.*%d" "2021  01-01")

and basically accept the same things that format-time-string accepts,
like:

(with-locale-environment "fr_FR"
  (parse-time "%d +%h" "5 ao=C3=BBt"))
=3D> (nil nil nil 5 8 nil)

I think that'd be more generally useful.

--=20
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Andreas Schwab <schwab@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 01 Jan 2022 14:57:02 +0000
Resent-Message-ID: <handler.52209.B52209.164104900332232 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: Bob Rogers <rogers-emacs@HIDDEN>, 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164104900332232
          (code B ref 52209); Sat, 01 Jan 2022 14:57:02 +0000
Received: (at 52209) by debbugs.gnu.org; 1 Jan 2022 14:56:43 +0000
Received: from localhost ([127.0.0.1]:59182 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n3foI-0008No-Rx
	for submit <at> debbugs.gnu.org; Sat, 01 Jan 2022 09:56:43 -0500
Received: from mail-out.m-online.net ([212.18.0.9]:37391)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <whitebox@HIDDEN>) id 1n3foH-0008Nb-4f
 for 52209 <at> debbugs.gnu.org; Sat, 01 Jan 2022 09:56:41 -0500
Received: from frontend01.mail.m-online.net (unknown [192.168.8.182])
 by mail-out.m-online.net (Postfix) with ESMTP id 4JR4pb0JGZz1qwGt;
 Sat,  1 Jan 2022 15:56:38 +0100 (CET)
Received: from localhost (dynscan1.mnet-online.de [192.168.6.70])
 by mail.m-online.net (Postfix) with ESMTP id 4JR4pZ2fC2z1qqkB;
 Sat,  1 Jan 2022 15:56:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at mnet-online.de
Received: from mail.mnet-online.de ([192.168.8.182])
 by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new,
 port 10024)
 with ESMTP id a11BeDTl7fCz; Sat,  1 Jan 2022 15:56:37 +0100 (CET)
X-Auth-Info: xxoJQhWibjS//Bfll4PbRVd3gMrdLU4TBXZjJwHXYhXlPke8SpiUvanFwpR9Pej6
Received: from igel.home (ppp-46-244-189-188.dynamic.mnet-online.de
 [46.244.189.188])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.mnet-online.de (Postfix) with ESMTPSA;
 Sat,  1 Jan 2022 15:56:37 +0100 (CET)
Received: by igel.home (Postfix, from userid 1000)
 id 2226B2C3A8F; Sat,  1 Jan 2022 15:56:37 +0100 (CET)
From: Andreas Schwab <schwab@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN> <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN> <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN> <87lezz5x92.fsf@HIDDEN>
X-Yow: Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no
 BOUNDS --
Date: Sat, 01 Jan 2022 15:56:37 +0100
In-Reply-To: <87lezz5x92.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Sat,
 01 Jan 2022 15:47:05 +0100")
Message-ID: <87h7an7bdm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.90 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.5 (-)

On Jan 01 2022, Lars Ingebrigtsen wrote:

> So how about just adding something that makes parsing common date
> formats easier, but without being DWIM or being hard-coded.  Like:
>
> (parse-time "%Y/%m/%d" "2021/01/01")
> => (nil nil nil 01 01 2021)

Aka strptime.

-- 
Andreas Schwab, schwab@HIDDEN
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 02 Jan 2022 00:42:02 +0000
Resent-Message-ID: <handler.52209.B52209.164108409116995 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>, Andreas Schwab <schwab@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164108409116995
          (code B ref 52209); Sun, 02 Jan 2022 00:42:02 +0000
Received: (at 52209) by debbugs.gnu.org; 2 Jan 2022 00:41:31 +0000
Received: from localhost ([127.0.0.1]:59643 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n3owF-0004Q2-2k
	for submit <at> debbugs.gnu.org; Sat, 01 Jan 2022 19:41:31 -0500
Received: from rgrjr.com ([69.164.211.47]:40214)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n3owD-0004Pv-Gq
 for 52209 <at> debbugs.gnu.org; Sat, 01 Jan 2022 19:41:30 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 300B31D6BB2;
 Sun,  2 Jan 2022 00:41:41 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 945A45FEC6; 
 Sat,  1 Jan 2022 19:41:28 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25040.62646.635818.692654@HIDDEN>
Date: Sat, 1 Jan 2022 19:41:26 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87lezz5x92.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Sat, 01 Jan 2022 15:47:05 +0100

   I wonder whether we should look at this another way.  We currently have
   two built-in date parsing functions in Emacs: `iso8601-parse' and
   `parse-time-string', and both parse strings according to well-defined
   standards (ISO8601 and RFC822bis, respectively).  (But the latter's doc
   string didn't explicitly say so, so people thought it was a DWIM
   parser.)

   DWIM date parsing is impossible, though, because there's an infinite
   variety of date formats out there, and variants are ambiguous.  And
   adding an infinite number of date parsers to Emacs doesn't seem
   attractive.

After perusing [1], I had started to think in terms just three basic
formats:  dmy (formerly euro-date), ymd, and mdy (formerly us-date),
plus possibly adding "." as a date separator.  That doesn't cover
everything but ought to broaden the set to make most of the world happy,
especially if I add a few hacks I have in mind to broaden recognition of
four-digit years and alphabetic months.  The rest I think could be left
to "patches welcome."

   And in that context, it may make more sense to say, "Use the original
parse-time-string if you know you have email dates, or iso8601-parse if
you have dates that conform to ISO-8601," rather than having parse-date
handle them itself.

   So how about just adding something that makes parsing common date
   formats easier, but without being DWIM or being hard-coded . . .

   I think that'd be more generally useful.

Perhaps, but I see that as a different problem:  One where you have a
date or set of dates in a precise format and just need to knock them
out.  I was trying to solve the problem where you have date(s) that you
only know the general origin (e.g. North America) and don't know whether
they are numeric, alphabetic, or how precise, and just want the parser
to do the best it can, and signal a reasonably informative error rather
than return an incorrect result.

   ================
   From: Andreas Schwab <schwab@HIDDEN>
   Date: Sat, 01 Jan 2022 15:56:37 +0100

   On Jan 01 2022, Lars Ingebrigtsen wrote:

   > (parse-time "%Y/%m/%d" "2021/01/01")
   > => (nil nil nil 01 01 2021)

   Aka strptime.

Oh, you're talking about the POSIX strptime, not the Perl Date::Parse
strptime, which is free-form.  Not being a C programmer, I was not aware
of the POSIX version.  But now I know where the odd name came from.  ;-}

					-- Bob

[1]  https://en.wikipedia.org/wiki/Date_format_by_country




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 03 Jan 2022 11:35:01 +0000
Resent-Message-ID: <handler.52209.B52209.164120968924478 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164120968924478
          (code B ref 52209); Mon, 03 Jan 2022 11:35:01 +0000
Received: (at 52209) by debbugs.gnu.org; 3 Jan 2022 11:34:49 +0000
Received: from localhost ([127.0.0.1]:34282 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n4Lc1-0006Mj-DK
	for submit <at> debbugs.gnu.org; Mon, 03 Jan 2022 06:34:49 -0500
Received: from quimby.gnus.org ([95.216.78.240]:35680)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n4Lbz-0006MS-7K
 for 52209 <at> debbugs.gnu.org; Mon, 03 Jan 2022 06:34:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=oAL6sCQvLy8rLohfi30IWA+gcEtvC7/wE5UVjOlMB0s=; b=hhMR1x+xEHRlgu+nIOaJviKeSq
 /hzH+rw3tp0n4sFK3V4KXS5b5qVTOEUXhAVltnRHCKBIYVXfS4izhA0OK+yQxJooiP5788g23UgGQ
 ATqK2huZxJPzv4g7iW+/5ZPnfj4taEafIgubiPiCL4HkdcYdK0JJFwS5kPejMF6qDEaY=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n4Lbn-0003y6-Tb; Mon, 03 Jan 2022 12:34:39 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN> <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN> <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN> <87lezz5x92.fsf@HIDDEN>
 <87h7an7bdm.fsf@HIDDEN> <25040.62646.635818.692654@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEXh39ixp6Xk4tyC
 paqLtdhwmln///9J99hjAAAAAWJLR0QGYWa4fQAAAAlwSFlzAAAuIwAALiMBeKU/dgAAAAd0SU1F
 B+YBAwsDAupqCW8AAAFwSURBVDjLfZTLbgIxDEUdq907PPZOKj4Addi3mmFf2ub/fwXbeUwyAowE
 wSf32glmAB6HW5cEjggAowZbyt6ZvAAGZFamKduATKqKliuSuAmUlwJs32t42SweuFUEvxNnFYRd
 n2cvINd21AMnwJpCWeIgEJCbcufmxfBtIFpTsrT+3xaJDcjJDmhX6lqyn8syVyAte78vwHcKiB2Y
 nymWBqAD85Tt2jlCVRwqIANYweVvBDHsDVxSmgarorimlP4bgAImEyTzOouVTQE6A0mjgjJCL8Es
 6UsarazG1RRTD/SuHgF8CQ4FfOWSGeglApwM2O8OHvLJWe4mBs3f8kQA5QllnR5W8FNGBYtCp4qP
 An7X6VpnWsE6qrCC92fglI4r4I58CMCuhJwjQ74BxQFYf/IJsdkONZiHfw90u/LWDRAfbUU8eQBM
 rDdKAcl1TwaMQVDwDXB7jgTnKByBkITVpFZgzz448Lwjj52gPWm6uAPVZ4pWjBaclQAAAA5lWElm
 SUkqAAgAAAAAAAAAAABvylxHAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTAxLTAzVDExOjAzOjAx
 KzAwOjAw0T8TnAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wMS0wM1QxMTowMzowMSswMDowMKBi
 qyAAAAAASUVORK5CYII=
X-Now-Playing: Genesis's _Duke_: "Turn It On Again"
Date: Mon, 03 Jan 2022 12:34:33 +0100
In-Reply-To: <25040.62646.635818.692654@HIDDEN> (Bob Rogers's message
 of "Sat, 1 Jan 2022 19:41:26 -0500")
Message-ID: <87mtkd3vee.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Bob Rogers <rogers-emacs@HIDDEN> writes: > And
 in that context, it may make more sense to say,
 "Use the original > parse-time-string
 if you know you have email dates, or iso8601-parse if > you have dates that
 conform to ISO-8601," rather tha [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

>    And in that context, it may make more sense to say, "Use the original
> parse-time-string if you know you have email dates, or iso8601-parse if
> you have dates that conform to ISO-8601," rather than having parse-date
> handle them itself.

Yeah.  And rename `parse-time-string' to something less confusing.

>    So how about just adding something that makes parsing common date
>    formats easier, but without being DWIM or being hard-coded . . .
>
>    I think that'd be more generally useful.
>
> Perhaps, but I see that as a different problem:  One where you have a
> date or set of dates in a precise format and just need to knock them
> out.  I was trying to solve the problem where you have date(s) that you
> only know the general origin (e.g. North America) and don't know whether
> they are numeric, alphabetic, or how precise, and just want the parser
> to do the best it can, and signal a reasonably informative error rather
> than return an incorrect result.

Yes, I think a function like that would be welcomed by many...  but
would then lead to an endless series of patches as it'd be extended
because it doesn't work correctly on dates from, say, Iceland.  That is,
a DWIM function would never be finished.

>    On Jan 01 2022, Lars Ingebrigtsen wrote:
>
>    > (parse-time "%Y/%m/%d" "2021/01/01")
>    > => (nil nil nil 01 01 2021)
>
>    Aka strptime.
>
> Oh, you're talking about the POSIX strptime, not the Perl Date::Parse
> strptime, which is free-form.  Not being a C programmer, I was not aware
> of the POSIX version.  But now I know where the odd name came from.  ;-}

POSIX strptime isn't very useful, because if you know the format that
precisely, you might as well just write a regexp for it yourself.  But
something like that, but with more sloppiness (i.e., allowing regexp
matching for the non-time bits) might be useful.  (And I think if we had
that, then implementing DWIM-ish parsing of, say, US dates on top of
that would be a matter of writing a series of these strings to match
them.  Probably.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 04 Jan 2022 04:46:01 +0000
Resent-Message-ID: <handler.52209.B52209.164127154522537 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164127154522537
          (code B ref 52209); Tue, 04 Jan 2022 04:46:01 +0000
Received: (at 52209) by debbugs.gnu.org; 4 Jan 2022 04:45:45 +0000
Received: from localhost ([127.0.0.1]:36719 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n4bhh-0005rR-Cu
	for submit <at> debbugs.gnu.org; Mon, 03 Jan 2022 23:45:45 -0500
Received: from rgrjr.com ([69.164.211.47]:40942)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n4bhe-0005rG-2P
 for 52209 <at> debbugs.gnu.org; Mon, 03 Jan 2022 23:45:44 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 66D431D6BB2;
 Tue,  4 Jan 2022 04:45:53 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 06C5D5FE2E; 
 Mon,  3 Jan 2022 23:45:41 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25043.53490.928476.622599@HIDDEN>
Date: Mon, 3 Jan 2022 23:45:38 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87mtkd3vee.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.1 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Mon, 03 Jan 2022 12:34:33 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   >    And in that context, it may make more sense to say, "Use the original
   > parse-time-string if you know you have email dates, or iso8601-parse if
   > you have dates that conform to ISO-8601," rather than having parse-date
   > handle them itself.

   Yeah.  And rename `parse-time-string' to something less confusing.

I would certainly have found that helpful.

   FWIW, I did some grepping of the elisp sources to count the callers
of parse-time-string to seen how much trouble it would be to rename
(there are around 60 of them), and found that ietf-drums-parse-date is
just encode-time of parse-time-string.  Since ietf-drums.el declares
itself "Functions for parsing RFC 2822 headers," perhaps
parse-date--x822 should find a new home as ietf-drums-parse-date-string,
and parse-time-string could then be made obsolescent in its favor.

   >    So how about just adding something that makes parsing common date
   >    formats easier, but without being DWIM or being hard-coded . . .
   >
   >    I think that'd be more generally useful.
   >
   > Perhaps, but I see that as a different problem:  One where you have a
   > date or set of dates in a precise format and just need to knock them
   > out.  I was trying to solve the problem where you have date(s) that you
   > only know the general origin (e.g. North America) and don't know whether
   > they are numeric, alphabetic, or how precise, and just want the parser
   > to do the best it can, and signal a reasonably informative error rather
   > than return an incorrect result.

   Yes, I think a function like that would be welcomed by many...  but
   would then lead to an endless series of patches as it'd be extended
   because it doesn't work correctly on dates from, say, Iceland.  That
   is, a DWIM function would never be finished.

But then, as I think someone on the list might have said very recently,
neither is Emacs.  ;-}

   POSIX strptime isn't very useful, because if you know the format that
   precisely, you might as well just write a regexp for it yourself.

Agreed.  And even writing and debugging regexps can often be less than
straightforward.  What you are suggesting is effectively expanding the
set of metacharacters with percent-escapes, which could makes it easier,
or could make it worse.

   But something like that, but with more sloppiness (i.e., allowing
   regexp matching for the non-time bits) might be useful.

One thing regexps can't do (at least not without adding a fair bit of
complexity) is allow components to be in different order or omitted.  So
it still just takes one approximate date/time, and the caller is back to
writing regexps to validate before passing it to the "real" parser.

   I was thinking that the next dimension in which to extend parse-date
would be to add keywords to refine what is accepted, on top of the basic
MDY order, e.g.:

	:date-separators "-/"
	:time-separators ":."
	:two-numbers-are :month-year	;; or (e.g.) :day-month
	:timezone :required	;; could be :optional or :forbidden
	:timezone-has-colon t	;; RFC5322 forbids, ISO-8601 requires

Some keywords could even be regexp-valued.  Others could be "umbrella"
keywords that change the defaults for subsets of more specific keywords.
In any case, that should make patching to add new features easier and
(eventually) allow for much more fine tuning by callers.

   (And I think if we had that, then implementing DWIM-ish parsing of,
   say, US dates on top of that would be a matter of writing a series of
   these strings to match them.  Probably.)

If I understand you correctly, this parse-date-DWIMishly would go
through the string and recognize (say) that it had come to something
that matches "%M/%d/%Y", concatenate that to a strptime-like format
string it was building, and then call parse-date-strptime-style (or
whatever) with that and the original string.  But it seems to me that if
it could recognize that it had found "%M/%d/%Y" in the string, it would
be much easier to just fill in the month, day, and year right then.

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 05 Jan 2022 15:47:02 +0000
Resent-Message-ID: <handler.52209.B52209.164139757929013 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164139757929013
          (code B ref 52209); Wed, 05 Jan 2022 15:47:02 +0000
Received: (at 52209) by debbugs.gnu.org; 5 Jan 2022 15:46:19 +0000
Received: from localhost ([127.0.0.1]:41478 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n58UV-0007Xt-8y
	for submit <at> debbugs.gnu.org; Wed, 05 Jan 2022 10:46:19 -0500
Received: from quimby.gnus.org ([95.216.78.240]:56270)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1n58UT-0007Xf-9Q
 for 52209 <at> debbugs.gnu.org; Wed, 05 Jan 2022 10:46:17 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
 :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=6rbvgV7ZroBSGyskNNucqc1421nvS8hW7K2kCKCrMbs=; b=MoA9fkuxsu4AmdDfk3LsnePTnS
 chHQFUrtXjpNiPufqpr0bPmKaGKCJ9qVr101Bp5ySQATCRh1K6whYMY4MhJwcObqeapIgEYW05B+3
 U0F0UlKZLvJXit95cp2aGBR22eYKHKrXEBuBAEeh0nZh7MugnrSoC89di3AT16zKckHA=;
Received: from [84.212.220.105] (helo=xo)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1n58UH-0005jh-UF; Wed, 05 Jan 2022 16:46:09 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN> <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN> <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN> <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN> <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN> <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN> <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN> <87lezz5x92.fsf@HIDDEN>
 <87h7an7bdm.fsf@HIDDEN> <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN> <25043.53490.928476.622599@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEXw8PBdXV2joqP/
 //8t2MV5AAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YBBQ8hEesE+ZEAAAFTSURBVCjPjZGxasMwEIYv
 ojF2phI6ZDShMa6ewkuGbg00xngKpRLGT6GaJiSeMpQQMgnTmuSesifZqV269IaTvtPp190J4Jfd
 5O8rt3S3O0UwFPXqXgopDXjzu2iYybk0aY6onz1nvhaRBZl46/XnI6XxAgvEM0fEI3C8XJYIVbiF
 WwN5BqyanMGHAE+ablYcCXjqG03EShMoW0elNIRg440PSaIxZiIt0H0yA0yjslfHBl7yRmZ87PXG
 L7qDKaoOxr2D5jkG5dmmGTdA1CNKn5gDlqLyQ/vo7E1qBE0wbcTIF9oKuH5PrVRUs3uV1u3GN520
 LdIy0x2w/EP9wMB1ulJdzq5DoIRRG+z56/If481H0YfhHh7S+KteYp6e8j3AIanUNiwcr6a34nix
 yAIhNgeaRRSn1dPsVZTUNkvSJIsCKXZmWLFYJKtgtxFB19efcr4ByGtiboM3kVUAAAAldEVYdGRh
 dGU6Y3JlYXRlADIwMjItMDEtMDVUMTU6MzM6MTcrMDA6MDB0j0NLAAAAJXRFWHRkYXRlOm1vZGlm
 eQAyMDIyLTAxLTA1VDE1OjMzOjE3KzAwOjAwBdL79wAAAABJRU5ErkJggg==
X-Now-Playing: Neil Young & Crazy Horse's _Zuma_: "Drive Back"
Date: Wed, 05 Jan 2022 16:46:01 +0100
In-Reply-To: <25043.53490.928476.622599@HIDDEN> (Bob Rogers's message
 of "Mon, 3 Jan 2022 23:45:38 -0500")
Message-ID: <87lezudw3q.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Bob Rogers <rogers-emacs@HIDDEN> writes: > One
 thing regexps can't do (at least not without adding a fair bit of >
 complexity)
 is allow components to be in different order or omitted. So > it still just
 takes one approximate date/time, and t [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> One thing regexps can't do (at least not without adding a fair bit of
> complexity) is allow components to be in different order or omitted.  So
> it still just takes one approximate date/time, and the caller is back to
> writing regexps to validate before passing it to the "real" parser.

Yes.  But you can't just have a function that you can give any string to
and it'll tell you what the date contained in it is.  "1.2" is a
perfectly normal way to specify "January second" in some countries, but no
amount of general DWIM is going to take us there.  The caller has to say
what they expect the format to be is.

>    I was thinking that the next dimension in which to extend parse-date
> would be to add keywords to refine what is accepted, on top of the basic
> MDY order, e.g.:
>
> 	:date-separators "-/"
> 	:time-separators ":."
> 	:two-numbers-are :month-year	;; or (e.g.) :day-month
> 	:timezone :required	;; could be :optional or :forbidden
> 	:timezone-has-colon t	;; RFC5322 forbids, ISO-8601 requires
>
> Some keywords could even be regexp-valued.  Others could be "umbrella"
> keywords that change the defaults for subsets of more specific keywords.
> In any case, that should make patching to add new features easier and
> (eventually) allow for much more fine tuning by callers.

I think it'd be easier to just write a regexp than to use a date-parsing
function like that.  =F0=9F=98=80

>    (And I think if we had that, then implementing DWIM-ish parsing of,
>    say, US dates on top of that would be a matter of writing a series of
>    these strings to match them.  Probably.)
>
> If I understand you correctly, this parse-date-DWIMishly would go
> through the string and recognize (say) that it had come to something
> that matches "%M/%d/%Y", concatenate that to a strptime-like format
> string it was building, and then call parse-date-strptime-style (or
> whatever) with that and the original string.  But it seems to me that if
> it could recognize that it had found "%M/%d/%Y" in the string, it would
> be much easier to just fill in the month, day, and year right then.

Well, I was thinking more like looping over a common set of formats and
see whether we have a match.  For the US, looping over "%M.*%d.*%Y?",
"%M.*%b.*%Y?" and "%M.*%B.*%Y?" would probably cover most of the
American-language dates.

--=20
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 05 Jan 2022 22:50:02 +0000
Resent-Message-ID: <handler.52209.B52209.16414229996795 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16414229996795
          (code B ref 52209); Wed, 05 Jan 2022 22:50:02 +0000
Received: (at 52209) by debbugs.gnu.org; 5 Jan 2022 22:49:59 +0000
Received: from localhost ([127.0.0.1]:39240 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1n5F6V-0001lX-G3
	for submit <at> debbugs.gnu.org; Wed, 05 Jan 2022 17:49:59 -0500
Received: from rgrjr.com ([69.164.211.47]:41446)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1n5F6S-0001lN-Qa
 for 52209 <at> debbugs.gnu.org; Wed, 05 Jan 2022 17:49:58 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 6BAB31D6BB2;
 Wed,  5 Jan 2022 22:50:07 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 157B35FE8B; 
 Wed,  5 Jan 2022 17:49:55 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown
Content-Transfer-Encoding: 7bit
Message-ID: <25046.8337.837242.510788@HIDDEN>
Date: Wed, 5 Jan 2022 17:49:53 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87lezudw3q.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <25023.40959.627321.685762@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN>
 <87lezudw3q.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -1.1 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Wed, 05 Jan 2022 16:46:01 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > One thing regexps can't do (at least not without adding a fair bit of
   > complexity) is allow components to be in different order or omitted.  So
   > it still just takes one approximate date/time, and the caller is back to
   > writing regexps to validate before passing it to the "real" parser.

   Yes.  But you can't just have a function that you can give any string to
   and it'll tell you what the date contained in it is.  "1.2" is a
   perfectly normal way to specify "January second" in some countries, but no
   amount of general DWIM is going to take us there.  The caller has to say
   what they expect the format to be is.

Granted, but (as with any API) how much they need to say can be greatly
reduced by suitable defaults.

   >    I was thinking that the next dimension in which to extend parse-date
   > would be to add keywords to refine what is accepted, on top of the basic
   > MDY order, e.g.:
   >
   > 	:date-separators "-/"
   > 	:time-separators ":."
   > 	:two-numbers-are :month-year	;; or (e.g.) :day-month
   > 	:timezone :required	;; could be :optional or :forbidden
   > 	:timezone-has-colon t	;; RFC5322 forbids, ISO-8601 requires
   >
   > Some keywords could even be regexp-valued.  Others could be "umbrella"
   > keywords that change the defaults for subsets of more specific keywords.
   > In any case, that should make patching to add new features easier and
   > (eventually) allow for much more fine tuning by callers.

   I think it'd be easier to just write a regexp than to use a date-parsing
   function like that.   

Again, suitable defaults should take care of that.  (And I'm beginning
to suspect you're better at writing regexps than I am.  ;-)

   > . . .

   Well, I was thinking more like looping over a common set of formats
   and see whether we have a match.  For the US, looping over
   "%M.*%d.*%Y?", "%M.*%b.*%Y?" and "%M.*%B.*%Y?" would probably cover
   most of the American-language dates.

Except that (according to "man strptime" on my system), "%M" is the
descriptor for minute, which rather makes the point that composing these
is not straightforward.  It also occurs to me that using ".*" could be
dangerous if it matches into the time or timezone fields.

   And (also based on my reading of "man strptime") you wouldn't need to
specify "%b" and "%B" separately, as they are treated equivalently, but
if you wanted to be DWIMmy about two-digit years, you'd have to cover
"%y" as well as "%Y":

     %m[-/]%d[-/]%y
     %m[-/]%d[-/]%Y
     %m[-/]%b[-/]%y
     %m[-/]%b[-/]%Y

This does not strike me as an improvement.

   In any case, I would like to bring parse-date.el to completion soon,
so here is what I plan to do:

   1.  Drop ISO-8601 parsing, and point the documentation to
iso8601-parse.

   2.  Drop email date parsing and use the code to create a patch that
updates ietf-drums.el, which could perhaps start the process to replace
parse-time-string.

   3.  Restrict parse-date formats to mdy, dmy, and ymd, with some extra
heuristics for four-digit years and alphanumeric months, then call it a
day.

   If you think the resulting parse-date is worth the trouble, then it
can become part of Emacs; if not, then I will offer it to ELPA.  Either
way, parse-date will be off my plate.  But I don't think I will take up
the mantle of writing a strptime-like date parser, as I don't think it
will be very useful.

					-- Bob




Message received at fakecontrol@fakecontrolmessage:


Received: (at fakecontrol) by fakecontrolmessage;
To: internal_control <at> debbugs.gnu.org
From: Debbugs Internal Request <help-debbugs@HIDDEN>
Subject: Internal Control
Message-Id: bug archived.
Date: Thu, 03 Feb 2022 12:24:04 +0000
User-Agent: Fakemail v42.6.9

# This is a fake control message.
#
# The action:
# bug archived.
thanks
# This fakemail brought to you by your local debbugs
# administrator


Message received at control <at> debbugs.gnu.org:


Received: (at control) by debbugs.gnu.org; 20 Feb 2022 12:24:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 20 07:24:34 2022
Received: from localhost ([127.0.0.1]:59490 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLlGT-0003Sb-Sl
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 07:24:34 -0500
Received: from quimby.gnus.org ([95.216.78.240]:53846)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1nLlGS-0003SN-44
 for control <at> debbugs.gnu.org; Sun, 20 Feb 2022 07:24:32 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=+B8/NbkBgxUZLtWvhz4OWjgQDr6aHc8VjbDQT4LFnlg=; b=Rrd+q4XscAkQ+F9+xss4NSopxD
 xv6b3HezVSHV2x2MicFyI5+ekAadX6mgOl/m3JQgvUzeZYJsgXTfjFoezXcGjUQ6YA9YmLUoD6eQ+
 9B/9mZrwjeKmnxWDEX4QF6w4mjLNjrFGUnLMnP+uqFJ1daKXrr+6UOIY+EBdtGWc5qIU=;
Received: from [84.212.220.105] (helo=giant)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1nLlGJ-0001cj-PE
 for control <at> debbugs.gnu.org; Sun, 20 Feb 2022 13:24:26 +0100
Date: Sun, 20 Feb 2022 13:24:23 +0100
Message-Id: <87czjhvi88.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: control message for bug #52209
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  unarchive 52209 quit 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

unarchive 52209
quit





Message received at fakecontrol@fakecontrolmessage:


Received: (at fakecontrol) by fakecontrolmessage;
To: internal_control <at> debbugs.gnu.org
From: Debbugs Internal Request <help-debbugs@HIDDEN>
Subject: Internal Control
Message-Id: bug No longer marked as fixed in versions 29.1 and reopened.
Date: Sun, 20 Feb 2022 12:25:02 +0000
User-Agent: Fakemail v42.6.9

# This is a fake control message.
#
# The action:
# bug No longer marked as fixed in versions 29.1 and reopened.
thanks
# This fakemail brought to you by your local debbugs
# administrator


Message received at control <at> debbugs.gnu.org:


Received: (at control) by debbugs.gnu.org; 20 Feb 2022 12:24:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Feb 20 07:24:38 2022
Received: from localhost ([127.0.0.1]:59493 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLlGY-0003Sr-1W
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 07:24:38 -0500
Received: from quimby.gnus.org ([95.216.78.240]:53858)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1nLlGX-0003SS-3s
 for control <at> debbugs.gnu.org; Sun, 20 Feb 2022 07:24:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc:
 MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=e1yvwNuDlCZIC8tG7D9Ho/gF/2F/5Svs/IJOWYTU95A=; b=qTyZtwAqlJTH0xkKi+u3c+7Ux4
 imoh7pTZ/yWWeNX8seQCbDgUkkhmVcn667yQ/ebrcSVknw1G0UPPPhDp706diG+6PR3x4Ec69vp5O
 uJ4Vpwl2cX6nSi1xEyVHLccdHa+KsCf0DCAZvbZZLAecWxb7x5CJddjuJ7qRU8NIRVyc=;
Received: from [84.212.220.105] (helo=giant)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1nLlGO-0001cp-OB
 for control <at> debbugs.gnu.org; Sun, 20 Feb 2022 13:24:31 +0100
Date: Sun, 20 Feb 2022 13:24:28 +0100
Message-Id: <87bkz1vi83.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: Lars Ingebrigtsen <larsi@HIDDEN>
Subject: control message for bug #52209
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  reopen 52209 tags 52209 - fixed patch quit 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

reopen 52209
tags 52209 - fixed patch
quit





Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Feb 2022 12:26:02 +0000
Resent-Message-ID: <handler.52209.B52209.164535992713442 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 52209 <at> debbugs.gnu.org
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164535992713442
          (code B ref 52209); Sun, 20 Feb 2022 12:26:02 +0000
Received: (at 52209) by debbugs.gnu.org; 20 Feb 2022 12:25:27 +0000
Received: from localhost ([127.0.0.1]:59501 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLlHL-0003Uk-Bx
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 07:25:27 -0500
Received: from quimby.gnus.org ([95.216.78.240]:53892)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1nLlHJ-0003UX-V1
 for 52209 <at> debbugs.gnu.org; Sun, 20 Feb 2022 07:25:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
 In-Reply-To:Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=ttxiqYbAeZOZPfhXSqjA6KKv/6WYbZODNPOMHTXT/GU=; b=qePjk2yr1Hxh06Qe9qxDBids4Y
 VIYRjgM/VgLrAhCjUZbsCuAmqfFQIkkh5v7cQf//oWD8PaLCtH1FZVXs5Npow8BdwXa50v1OB+8jR
 K2pGyXfPaPWZaknbmbmvLlIUsVu73w8UczidihAkM/zFx9L/Nl4uWyKxI4jwfZvvj7/U=;
Received: from [84.212.220.105] (helo=giant)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>) id 1nLlHB-0001dE-EA
 for 52209 <at> debbugs.gnu.org; Sun, 20 Feb 2022 13:25:20 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <25105.33397.961104.269676@HIDDEN> (Bob Rogers's message
 of "Sat, 19 Feb 2022 18:51:17 -0500")
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <875yrjpp03.fsf@HIDDEN> <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN> <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN> <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN> <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN> <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN> <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN> <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN> <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEU9NTViT02gg37/
 //+reOmVAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YCFAwPKvxL7eoAAAGmSURBVCjPdZLBauMwEIbH
 RjI4pxLiUPe8hc1bmBCHHu3gEUinDViL5afoIe7ZBmvZ5rSGCKI+5Y7acwUGfZrR+P9/BPD9arDG
 sEQHwLVHNPr65yoBcvdOx1L8fhdUcQ7RevS9KCCx1iv06Mz2FXhifY/3ACOw2DpJYHcJwYkO0aF9
 ThpgAqnicDL7A4GlylLPuwD7IbQRlAx4XVpJKsRwJjBP28kotR1uBwIlnJFKIAFrlbBaChpKQBsf
 HODtBYDgw6H4BKaVuH5Ygc1tAwxz4XoUZYM0DS3a+kG0Pf8LyXHxU93ors9ukIrF1FF1NnI9Q3qc
 TQVw1vJ0B3ZEM1UctdzPwNZDR5HUGgn4qTQWcWxxf4E0ORhSU+msYpAiCXUNZde9QKrV2+L7J2sN
 +/Sz0EexfJkLkaA1BM9GzI6khzbQOTYaS5w7giwn2wbLuSPbeVbO1U/6P91hjxtssoxTChfgfPJS
 DdNdIWnjloa/OROARUUnk3JsV8FCXPzbrdZjm8YzQAzjjzQufvEAEVQb6n1YxReqFMUji16/IALY
 AAGH4vs39R/6Aaur4OLNiwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wMi0yMFQxMjoxNTo0Misw
 MDowMEtlZi4AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDItMjBUMTI6MTU6NDIrMDA6MDA6ON6S
 AAAAAElFTkSuQmCC
X-Now-Playing: Meat Beat Manifesto's _Psyche-Out_: "Psyche-Out (version 1)"
Date: Sun, 20 Feb 2022 13:25:16 +0100
Message-ID: <87a6elvi6r.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: (Resending because bug report was archived.) Bob Rogers
 <rogers-emacs@HIDDEN>
 writes: > Here's what I have for this phase of the plan; let me know what
 you > think. It took longer than expected because it became a project unto
 > itself, and so my procrastinator kicked in, making it lon [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

(Resending because bug report was archived.)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> Here's what I have for this phase of the plan; let me know what you
> think.  It took longer than expected because it became a project unto
> itself, and so my procrastinator kicked in, making it longer still.  :-/

:-)

Have you benchmarked your new implementation versus the current one?
It's important that the parsing is performant, otherwise it'd slow down
many things that parse a large number of date strings.

Some minor comments about the code:

> +(defsubst ietf-drums-date--ignore-char? (char)
> +  ;; Ignore whitespace and commas.
> +  (or (eq char ?\ ) (eq char ?\t) (eq char ?\r) (eq char ?\n) (eq char ?,)))

In Emacs Lisp, we don't use Scheme-style predicate names -- we use -p
instead.

> +(defun ietf-drums-date--tokenize-string (string &optional comment-eof?)

And the same with booleans -- we don't use foo? for those, but just foo.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Andreas Schwab <schwab@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Feb 2022 13:05:02 +0000
Resent-Message-ID: <handler.52209.B52209.16453622421820 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16453622421820
          (code B ref 52209); Sun, 20 Feb 2022 13:05:02 +0000
Received: (at 52209) by debbugs.gnu.org; 20 Feb 2022 13:04:02 +0000
Received: from localhost ([127.0.0.1]:59550 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLlsg-0000TI-4X
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 08:04:02 -0500
Received: from mail-out.m-online.net ([212.18.0.9]:39971)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <whitebox@HIDDEN>) id 1nLlsd-0000Sr-PQ
 for 52209 <at> debbugs.gnu.org; Sun, 20 Feb 2022 08:04:00 -0500
Received: from frontend01.mail.m-online.net (unknown [192.168.8.182])
 by mail-out.m-online.net (Postfix) with ESMTP id 4K1lxT4Mb7z1qxln;
 Sun, 20 Feb 2022 14:03:56 +0100 (CET)
Received: from localhost (dynscan1.mnet-online.de [192.168.6.70])
 by mail.m-online.net (Postfix) with ESMTP id 4K1lxS5nljz1qqkG;
 Sun, 20 Feb 2022 14:03:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at mnet-online.de
Received: from mail.mnet-online.de ([192.168.8.182])
 by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new,
 port 10024)
 with ESMTP id MBuq5Dsl9y-4; Sun, 20 Feb 2022 14:03:56 +0100 (CET)
X-Auth-Info: mt+exuV4j+er9WWZ60VxEWpuQZ1vU3n5x5J8FR/FH0mtmA69qzlvEmZeoiNcfxJ3
Received: from igel.home (ppp-46-244-179-255.dynamic.mnet-online.de
 [46.244.179.255])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mail.mnet-online.de (Postfix) with ESMTPSA;
 Sun, 20 Feb 2022 14:03:56 +0100 (CET)
Received: by igel.home (Postfix, from userid 1000)
 id 73B0C2C394B; Sun, 20 Feb 2022 14:03:55 +0100 (CET)
From: Andreas Schwab <schwab@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <875yrjpp03.fsf@HIDDEN> <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN> <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN> <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN> <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN> <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN> <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN> <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN> <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN>
X-Yow: Let's climb to the TOP of that MOUNTAIN and think about STRIP MINING!!
Date: Sun, 20 Feb 2022 14:03:55 +0100
In-Reply-To: <25105.33397.961104.269676@HIDDEN> (Bob Rogers's message
 of "Sat, 19 Feb 2022 18:51:17 -0500")
Message-ID: <87wnhphepw.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.5 (-)

On Feb 19 2022, Bob Rogers wrote:

> +  (or (eq char ?\ ) (eq char ?\t) (eq char ?\r) (eq char ?\n) (eq char ?,)))

     (memq char '(?\s ?\t ?\r ?\n ?,))

-- 
Andreas Schwab, schwab@HIDDEN
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 20 Feb 2022 22:15:01 +0000
Resent-Message-ID: <handler.52209.B52209.164539527915867 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Lars Ingebrigtsen <larsi@HIDDEN>, Andreas Schwab <schwab@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164539527915867
          (code B ref 52209); Sun, 20 Feb 2022 22:15:01 +0000
Received: (at 52209) by debbugs.gnu.org; 20 Feb 2022 22:14:39 +0000
Received: from localhost ([127.0.0.1]:34083 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nLuTW-00047r-Ll
	for submit <at> debbugs.gnu.org; Sun, 20 Feb 2022 17:14:38 -0500
Received: from rgrjr.com ([69.164.211.47]:50368)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1nLuTU-00047j-V4
 for 52209 <at> debbugs.gnu.org; Sun, 20 Feb 2022 17:14:37 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 2C2AB1D6BB0;
 Sun, 20 Feb 2022 22:14:46 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id BFAE15FD38; 
 Sun, 20 Feb 2022 17:14:36 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25106.48460.775490.619228@HIDDEN>
Date: Sun, 20 Feb 2022 17:14:36 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <87ilt9vicd.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN>
 <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN>
 <87wnhphepw.fsf@HIDDEN> <87ilt9vicd.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Sun, 20 Feb 2022 13:21:54 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > Here's what I have for this phase of the plan; let me know what you
   > think.  It took longer than expected because it became a project unto
   > itself, and so my procrastinator kicked in, making it longer still.  :-/

   :-)

   Have you benchmarked your new implementation versus the current one?
   It's important that the parsing is performant, otherwise it'd slow down
   many things that parse a large number of date strings.

No benchmarking; I will do that presently.

   Some minor comments about the code:

   > +(defsubst ietf-drums-date--ignore-char? (char) . . .

   In Emacs Lisp, we don't use Scheme-style predicate names -- we use -p
   instead . . .

   And the same with booleans -- we don't use foo? for those, but just foo.

OK.

   ================
   From: Andreas Schwab <schwab@HIDDEN>
   Date: Sun, 20 Feb 2022 14:03:55 +0100

   On Feb 19 2022, Bob Rogers wrote:

   > +  (or (eq char ?\ ) (eq char ?\t) (eq char ?\r) (eq char ?\n) (eq char ?,)))

	(memq char '(?\s ?\t ?\r ?\n ?,))

Good eye; I had been adding to that set incrementally, so I missed the
forest for the trees.

					-- Bob




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 23 Feb 2022 23:16:01 +0000
Resent-Message-ID: <handler.52209.B52209.16456581394734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Lars Ingebrigtsen <larsi@HIDDEN>, Andreas Schwab <schwab@HIDDEN>, 52209 <at> debbugs.gnu.org, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16456581394734
          (code B ref 52209); Wed, 23 Feb 2022 23:16:01 +0000
Received: (at 52209) by debbugs.gnu.org; 23 Feb 2022 23:15:39 +0000
Received: from localhost ([127.0.0.1]:46820 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nN0rC-0001EI-Mc
	for submit <at> debbugs.gnu.org; Wed, 23 Feb 2022 18:15:38 -0500
Received: from rgrjr.com ([69.164.211.47]:51022)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1nN0rA-0001E9-NS
 for 52209 <at> debbugs.gnu.org; Wed, 23 Feb 2022 18:15:37 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id 8075E1D6BAE;
 Wed, 23 Feb 2022 23:15:45 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id F37BA60189; 
 Wed, 23 Feb 2022 18:15:35 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="LHiePXryFa"
Content-Transfer-Encoding: 7bit
Message-ID: <25110.49174.412406.711346@HIDDEN>
Date: Wed, 23 Feb 2022 18:15:34 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <25106.48460.775490.619228@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <875yrjpp03.fsf@HIDDEN>
 <25024.42989.718735.680188@HIDDEN>
 <871r26i5n0.fsf@HIDDEN>
 <25028.53876.304365.706795@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN>
 <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN>
 <87wnhphepw.fsf@HIDDEN> <87ilt9vicd.fsf@HIDDEN>
 <25106.48460.775490.619228@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--LHiePXryFa
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   From: Bob Rogers <rogers-emacs@HIDDEN>
   Date: Sun, 20 Feb 2022 17:14:36 -0500

      From: Lars Ingebrigtsen <larsi@HIDDEN>
      Date: Sun, 20 Feb 2022 13:21:54 +0100

      Bob Rogers <rogers-emacs@HIDDEN> writes:

      > Here's what I have for this phase of the plan; let me know what you
      > think.  It took longer than expected because it became a project unto
      > itself, and so my procrastinator kicked in, making it longer still.  :-/

      :-)

      Have you benchmarked your new implementation versus the current one?
      It's important that the parsing is performant, otherwise it'd slow down
      many things that parse a large number of date strings.

   No benchmarking; I will do that presently.

Benchmarking code and results attached.  I extracted a handful of
non-error cases from the tests as being more representative than any of
the error cases; the resulting numbers make it seem like any difference
between the two implementations is in the noise.

   But this is my first foray into elisp benchmarking, so I may have
overlooked something.  Fortunately, email dates are not that diverse, so
I am hoping this sampling may be broad enough.

					-- Bob


--LHiePXryFa
Content-Type: text/x-emacs-lisp
Content-Disposition: inline;
	filename="ietf-drums-date-timings.el"
Content-Transfer-Encoding: 7bit

;;; ietf-drums-date-timings.el --- timing ietf-drums-date.el -*- lexical-binding: t -*-

;; Copyright (C) 2022 Free Software Foundation, Inc.

;; Author: Bob Rogers <rogers@HIDDEN>

(defun run-timings (parse-fn)
  (dolist (case '(("Mon, 22 Feb 2016 19:35:42 +0100"
                   (42 35 19 22 2 2016 1 -1 3600)
                   (22219 21758))
                  ("22 Feb 2016 19:35:42 +0100"
                   (42 35 19 22 2 2016 nil -1 3600)
                   (22219 21758))
                  ("Mon, 22 February 2016 19:35:42 +0100"
                   (42 35 19 22 2 2016 1 -1 3600)
                   (22219 21758))
                  ("Mon, 22 feb 2016 19:35:42 +0100"
                   (42 35 19 22 2 2016 1 -1 3600)
                   (22219 21758))
                  ("Monday, 22 february 2016 19:35:42 +0100"
                   (42 35 19 22 2 2016 1 -1 3600)
                   (22219 21758))
                  ("Monday, 22 february 2016 19:35:42 PST"
                   (42 35 19 22 2 2016 1 nil -28800)
                   (22219 54158))
                  ("Friday, 21 Sep 2018 13:47:58 PDT"
                   (58 47 13 21 9 2018 5 t -25200)
                   (23461 22782))
                  ("Friday, 21 Sep 2018 13:47:58"
                   (58 47 13 21 9 2018 5 -1 nil)
                   (23461 11982))))
    (funcall parse-fn (car case))))

(benchmark-run-compiled 10000 (run-timings #'ietf-drums-parse-date))
;; (7.220905228 83 3.3420971879999968)
;; (7.24936647 83 3.3321491059999993)
;; (7.3240701370000005 84 3.371737411)
;; (/ (+ 7.249 7.324 7.324) 3) 7.299

(defun ietf-drums-old-parse-date (string)
  "Return an Emacs time spec from STRING."
  (encode-time (parse-time-string string)))

(benchmark-run 10000 (run-timings #'ietf-drums-old-parse-date))
;; (7.249068317 83 3.3251401939999994)
;; (7.317397244 84 3.3750772899999983)
;; (7.268244294 84 3.3820036280000005)
;; (/ (+ 7.249 7.317 7.268) 3) 7.278

--LHiePXryFa--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 24 Feb 2022 09:20:03 +0000
Resent-Message-ID: <handler.52209.B52209.16456943964522 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.16456943964522
          (code B ref 52209); Thu, 24 Feb 2022 09:20:03 +0000
Received: (at 52209) by debbugs.gnu.org; 24 Feb 2022 09:19:56 +0000
Received: from localhost ([127.0.0.1]:47523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNAI0-0001Ar-9r
	for submit <at> debbugs.gnu.org; Thu, 24 Feb 2022 04:19:56 -0500
Received: from quimby.gnus.org ([95.216.78.240]:43438)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1nNAHy-0001AW-IY
 for 52209 <at> debbugs.gnu.org; Thu, 24 Feb 2022 04:19:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:
 References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
 List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=Ju8VX1d8HERbmqnGDrqCqnE6FYHxU31POOcPQxoJ6m8=; b=ssp/qF2l8xneeIG58b+5EEHhm7
 EgYzXdBmIRUBKtzIG2NSEtIHnQ93ds6pruCJjWEN01ltU3/4TZFaYos+mG6BMo8z+bk7Xo7z2vfs9
 srcy78RnkguEYq51XFDUS2QbRLe//sDUIVJctNasTjaZvpxpCB1EiWvs4EN4tICND6ws=;
Received: from [84.212.220.105] (helo=giant)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1nNAHn-0003qj-V2; Thu, 24 Feb 2022 10:19:46 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN> <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN> <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN> <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN> <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN> <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN> <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN> <87wnhphepw.fsf@HIDDEN>
 <87ilt9vicd.fsf@HIDDEN> <25106.48460.775490.619228@HIDDEN>
 <25110.49174.412406.711346@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj
 SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEWJgHTa2NZIQTr/
 ///FtiXEAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YCGAg1E8s4rP8AAAF7SURBVCjPfdDBThsxEAbg
 2Sitqj1FUYxETyQHlPopXJQg2NMW7aCyp4AaKexTOFWMopx6SDivo1KZ/yk7dlALF+b2ee3Z+YcU
 /y9KmDJPuGLqeznxhqQEoTzuDAVdOeztzf3H4SJ+UdTzk6fT7BYI+Y767eTkzs2w9xEI2X65EDQR
 yEbLBnjWggDq+DvBhZL/jC38TBpI6z5aq/1cAwlBMD17AdbwfJ6uHVlS0zdTv4Xpfn/GTmDUWDX2
 PggG/KM3ck220BF+/mu0NHQS8RhmYxoWCBBsoT9ZAQ4o1lYVOk/INOyuGFYH5HrzVDiG5NnaPja+
 HrCW2Ns95RtfXnOTO3pA0PDfrrhOkPKXzFWpaGXp3+TkXkc4oByk9bopV8QlZC8CkrdcBrRBxWuy
 AgF6CV+Z68/487iLkM4XV1h1IyrxZY3VwEX4Od+c4bd2MkGHMjZUtxDIaGs2WY0E6RoKmye00Btb
 x9kFEgdfBD/tB3LWmPcivIaEkZf4C95g2gEFswnBAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTAy
 LTI0VDA4OjUzOjE5KzAwOjAwzyT0ogAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wMi0yNFQwODo1
 MzoxOSswMDowML55TB4AAAAASUVORK5CYII=
X-Now-Playing: Bobbie Gentry's _The Girl From Chickasaw County (6): Fancy_:
 "Apartment 21"
Date: Thu, 24 Feb 2022 10:19:43 +0100
In-Reply-To: <25110.49174.412406.711346@HIDDEN> (Bob Rogers's message
 of "Wed, 23 Feb 2022 18:15:34 -0500")
Message-ID: <877d9k4o5s.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview: Bob Rogers <rogers-emacs@HIDDEN> writes: >
 Benchmarking
 code and results attached. I extracted a handful of > non-error cases from
 the tests as being more representative than any of > the error cases; the
 resulting numbers make it seem like [...] 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> Benchmarking code and results attached.  I extracted a handful of
> non-error cases from the tests as being more representative than any of
> the error cases; the resulting numbers make it seem like any difference
> between the two implementations is in the noise.
>
>    But this is my first foray into elisp benchmarking, so I may have
> overlooked something.  Fortunately, email dates are not that diverse, so
> I am hoping this sampling may be broad enough.

[...]

> (benchmark-run-compiled 10000 (run-timings #'ietf-drums-parse-date))
> ;; (7.220905228 83 3.3420971879999968)
> ;; (7.24936647 83 3.3321491059999993)
> ;; (7.3240701370000005 84 3.371737411)
> ;; (/ (+ 7.249 7.324 7.324) 3) 7.299

[...]

> (benchmark-run 10000 (run-timings #'ietf-drums-old-parse-date))
> ;; (7.249068317 83 3.3251401939999994)
> ;; (7.317397244 84 3.3750772899999983)
> ;; (7.268244294 84 3.3820036280000005)
> ;; (/ (+ 7.249 7.317 7.268) 3) 7.278

Thanks; that looks quite promising.  Can you send a new version of the
patch, and I'll get it pushed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Feb 2022 00:50:02 +0000
Resent-Message-ID: <handler.52209.B52209.164575016110734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164575016110734
          (code B ref 52209); Fri, 25 Feb 2022 00:50:02 +0000
Received: (at 52209) by debbugs.gnu.org; 25 Feb 2022 00:49:21 +0000
Received: from localhost ([127.0.0.1]:50737 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNOnQ-0002n3-72
	for submit <at> debbugs.gnu.org; Thu, 24 Feb 2022 19:49:21 -0500
Received: from rgrjr.com ([69.164.211.47]:51196)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1nNOnN-0002mt-Gy
 for 52209 <at> debbugs.gnu.org; Thu, 24 Feb 2022 19:49:18 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id E70B31D6BB2;
 Fri, 25 Feb 2022 00:49:25 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 5FEB760116; 
 Thu, 24 Feb 2022 19:49:16 -0500 (EST)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ftCty46yS8"
Content-Transfer-Encoding: 7bit
Message-ID: <25112.10122.651114.221297@HIDDEN>
Date: Thu, 24 Feb 2022 19:49:14 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <877d9k4o5s.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <87zgoq2vwm.fsf@HIDDEN>
 <25029.60989.564217.290743@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN>
 <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN>
 <87wnhphepw.fsf@HIDDEN> <87ilt9vicd.fsf@HIDDEN>
 <25106.48460.775490.619228@HIDDEN>
 <25110.49174.412406.711346@HIDDEN>
 <877d9k4o5s.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


--ftCty46yS8
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Thu, 24 Feb 2022 10:19:43 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > Benchmarking code and results attached.  I extracted a handful of
   > non-error cases from the tests as being more representative than any of
   > the error cases; the resulting numbers make it seem like any difference
   > between the two implementations is in the noise.

   Thanks; that looks quite promising.  Can you send a new version of the
   patch, and I'll get it pushed?

Here it is; there should be no changes from what I last sent other than
from the suggestions you and Andreas made.  Thanks,

					-- Bob


--ftCty46yS8
Content-Type: text/x-patch
Content-Disposition: inline;
	filename="0001-Enhanced-date-parsing-for-ietf-drums.el.patch"
Content-Transfer-Encoding: quoted-printable

=46rom bdf96f4132cb0433dfcd48b862175ef9bbcc41bb Mon Sep 17 00:00:00 2001
From: Bob Rogers <rogers@HIDDEN>
Date: Tue, 1 Feb 2022 14:36:31 -0500
Subject: [PATCH] Enhanced date parsing for ietf-drums.el

* lisp/mail/ietf-drums-date.el (added):
   + (ietf-drums-parse-date-string):  parse-time-string replacement
     which is compatible but can be made stricter if desired.
* test/lisp/mail/ietf-drums-date-tests.el (added):
   + Add tests for ietf-drums-parse-date-string.
* lisp/mail/ietf-drums.el:
   + (ietf-drums-parse-date):  Use ietf-drums-parse-date-string.
---
 lisp/mail/ietf-drums-date.el            | 274 ++++++++++++++++++++++++=

 lisp/mail/ietf-drums.el                 |   6 +-
 test/lisp/mail/ietf-drums-date-tests.el | 176 +++++++++++++++
 3 files changed, 455 insertions(+), 1 deletion(-)
 create mode 100644 lisp/mail/ietf-drums-date.el
 create mode 100644 test/lisp/mail/ietf-drums-date-tests.el

diff --git a/lisp/mail/ietf-drums-date.el b/lisp/mail/ietf-drums-date.e=
l
new file mode 100644
index 0000000000..6f64ae7337
--- /dev/null
+++ b/lisp/mail/ietf-drums-date.el
@@ -0,0 +1,274 @@
+;;; ietf-drums-date.el --- parse time/date for ietf-drums.el -*- lexic=
al-binding: t -*-
+
+;; Copyright (C) 2022 Free Software Foundation, Inc.
+
+;; Author: Bob Rogers <rogers@HIDDEN>
+;; Keywords: mail, util
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published b=
y
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.=

+
+;;; Commentary:
+
+;; 'ietf-drums-parse-date-string' parses a time and/or date in a
+;; string and returns a list of values, just like `decode-time', where=

+;; unspecified elements in the string are returned as nil (except
+;; unspecified DST is returned as -1).  `encode-time' may be applied
+;; on these values to obtain an internal time value.
+
+;; Historically, `parse-time-string' was used for this purpose, but it=

+;; was gradually but imperfectly extended to handle other date
+;; formats.  'ietf-drums-parse-date-string' is compatible in that it
+;; uses the same return value format and parses the same email date
+;; formats by default, but can be made stricter if desired.
+
+;;; Code:
+
+(require 'cl-lib)
+(require 'parse-time)
+
+(define-error 'date-parse-error "Date/time parse error" 'error)
+
+(defconst ietf-drums-date--slot-names
+  '(second minute hour day month year weekday dst zone)
+  "Names of return value slots, for better error messages
+See the decoded-time defstruct.")
+
+(defconst ietf-drums-date--slot-ranges
+  '((0 60) (0 59) (0 23) (1 31) (1 12) (1 9999))
+  "Numeric slot ranges, for bounds checking.
+Note that RFC5322 explicitly requires that seconds go up to 60,
+to allow for leap seconds (see Mills, D., 'Network Time
+Protocol', STD 12, RFC 1119, September 1989).")
+
+(defsubst ietf-drums-date--ignore-char-p (char)
+  ;; Ignore whitespace and commas.
+  (memq char '(=3F\s =3F\t =3F\r =3F\n =3F,)))
+
+(defun ietf-drums-date--tokenize-string (string &optional comment-eof)=

+  "Turn STRING into tokens, separated only by whitespace and commas.
+Multiple commas are ignored.  Pure digit sequences are turned
+into integers.  If COMMENT-EOF is true, then a comment as
+defined by RFC5322 (strictly, the CFWS production that also
+accepts comments) is treated as an end-of-file, and no further
+tokens are recognized, otherwise we strip out all comments and
+treat them as whitespace (per RFC822)."
+  (let ((index 0)
+=09(end (length string))
+=09(list ()))
+    (cl-flet ((skip-ignored ()
+                ;; Skip ignored characters at index (the scan
+                ;; position).  Skip RFC822 comments in matched parens,=

+                ;; but do not complain about unterminated comments.
+                (let ((char nil)
+                      (nest 0))
+                  (while (and (< index end)
+                              (setq char (aref string index))
+                              (or (> nest 0)
+                                  (ietf-drums-date--ignore-char-p char=
)
+                                  (and (not comment-eof) (eql char =3F=
\())))
+                    (cl-incf index)
+                    ;; FWS bookkeeping.
+                    (cond ((and (eq char =3F\\)
+                                (< (1+ index) end))
+=09                    ;; Move to the next char but don't check
+=09                    ;; it to see if it might be a paren.
+                            (cl-incf index))
+                          ((eq char =3F\() (cl-incf nest))
+                          ((eq char =3F\)) (cl-decf nest)))))))
+      (skip-ignored)=09=09;; Skip leading whitespace.
+      (while (and (< index end)
+                  (not (and comment-eof
+                            (eq (aref string index) =3F\())))
+        (let* ((start index)
+               (char (aref string index))
+               (all-digits (<=3D =3F0 char =3F9)))
+          ;; char is valid; look for more valid characters.
+          (when (and (eq char =3F\\)
+                     (< (1+ index) end))
+            ;; Escaped character, which might be a "(".  If so, we are=

+            ;; correct to include it in the token, even though the
+            ;; caller is sure to barf.  If not, we violate RFC2=3F822 =
by
+            ;; not removing the backslash, but no characters in valid
+            ;; RFC2=3F822 dates need escaping anyway, so it shouldn't
+            ;; matter that this is not done strictly correctly.  --
+            ;; rgr, 24-Dec-21.
+            (cl-incf index))
+          (while (and (< (cl-incf index) end)
+                      (setq char (aref string index))
+                      (not (or (ietf-drums-date--ignore-char-p char)
+                               (eq char =3F\())))
+            (unless (<=3D =3F0 char =3F9)
+              (setq all-digits nil))
+            (when (and (eq char =3F\\)
+                       (< (1+ index) end))
+              ;; Escaped character, see above.
+              (cl-incf index)))
+          (push (if all-digits
+                    (cl-parse-integer string :start start :end index)
+                  (substring string start index))
+                list)
+          (skip-ignored)))
+      (nreverse list))))
+
+(defun ietf-drums-parse-date-string (time-string &optional error no-82=
2)
+  "Parse an RFC5322 or RFC822 date, passed as TIME-STRING.
+The optional ERROR parameter causes syntax errors to be flagged
+by signalling an instance of the date-parse-error condition.  The
+optional NO-822 parameter disables the more lax RFC822 syntax,
+which is permitted by default.
+
+The result is a list of (SEC MIN HOUR DAY MON YEAR DOW DST TZ),
+which can be accessed as a decoded-time defstruct (q.v.),
+e.g. `decoded-time-year' to extract the year, and turned into an
+Emacs timestamp by `encode-time'.
+
+The strict syntax for RFC5322 is as follows:
+
+   [ day-of-week \",\" ] day FWS month-name FWS year FWS time [CFWS]
+
+where the \"time\" production is:
+
+   2DIGIT \":\" 2DIGIT [ \":\" 2DIGIT ] FWS ( \"+\" / \"-\" ) 4DIGIT
+
+and FWS is \"folding white space,\" and CFWS is \"comments and/or
+folding white space\", where comments are included in nesting
+parentheses and are equivalent to white space.  RFC822 also
+accepts comments in random places (all of which is handled by
+ietf-drums-date--tokenize-string) and two-digit years.  For
+two-digit years, 50 and up are interpreted as 1950 through 1999
+and 00 through 49 as 200 through 2049.
+
+We are somewhat more lax in what we accept (specifically, the
+hours don't have to be two digits, and the TZ and the comma after
+the DOW are optional), but we do insist that the items that are
+present do appear in this order.  Unspecified/unrecognized
+elements in the string are returned as nil (except unspecified
+DST is returned as -1)."
+  (let ((tokens (ietf-drums-date--tokenize-string (downcase time-strin=
g)
+                                                  no-822))
+        (time (list nil nil nil nil nil nil nil -1 nil)))
+    (cl-labels ((set-matched-slot (slot index token)
+                  ;; Assign a slot value from match data if index is
+                  ;; non-nil, else from token, signalling an error if
+                  ;; enabled and it's out of range.
+                  (let ((value (if index
+                                   (cl-parse-integer (match-string ind=
ex token))
+                                 token)))
+                    (when error
+                      (let ((range (nth slot ietf-drums-date--slot-ran=
ges)))
+                        (when (and range
+                                   (not (<=3D (car range) value (cadr =
range))))
+                          (signal 'date-parse-error
+                                  (list "Slot out of range"
+                                        (nth slot ietf-drums-date--slo=
t-names)
+                                        token (car range) (cadr range)=
)))))
+                    (setf (nth slot time) value)))
+                (set-numeric (slot token)
+                  ;; Only assign the slot if the token is a number.
+                  (cond ((natnump token)
+                          (set-matched-slot slot nil token))
+                        (error
+                          (signal 'date-parse-error
+                                  (list "Not a number"
+                                        (nth slot ietf-drums-date--slo=
t-names)
+                                        token))))))
+      ;; Check for weekday.
+      (let ((dow (assoc (car tokens) parse-time-weekdays)))
+        (when dow
+          ;; Day of the week.
+          (set-matched-slot 6 nil (cdr dow))
+          (pop tokens)))
+      ;; Day.
+      (set-numeric 3 (pop tokens))
+      ;; Alphabetic month.
+      (let* ((month (pop tokens))
+             (match (assoc month parse-time-months)))
+        (cond (match
+                (set-matched-slot 4 nil (cdr match)))
+              (error
+                (signal 'date-parse-error
+                        (list "Expected an alphabetic month" month)))
+              (t
+                (push month tokens))))
+      ;; Year.
+      (let ((year (pop tokens)))
+        ;; Check the year for the right number of digits.
+        (cond ((not (natnump year))
+                (when error
+                  (signal 'date-parse-error
+                          (list "Expected a year" year)))
+                (push year tokens))
+              ((>=3D year 1000)
+                (set-numeric 5 year))
+              ((or no-822
+                   (>=3D year 100))
+                (when error
+                  (signal 'date-parse-error
+                          (list "Four-digit years are required" year))=
)
+                (push year tokens))
+              ((>=3D year 50)
+                ;; second half of the 20th century.
+                (set-numeric 5 (+ 1900 year)))
+              (t
+                ;; first half of the 21st century.
+                (set-numeric 5 (+ 2000 year)))))
+      ;; Time.
+      (let ((time (pop tokens)))
+        (cond ((or (null time) (natnump time))
+                (when error
+                  (signal 'date-parse-error
+                          (list "Expected a time" time)))
+                (push time tokens))
+              ((string-match
+                "^\\([0-9][0-9]=3F\\):\\([0-9][0-9]\\):\\([0-9][0-9]\\=
)$"
+                time)
+                (set-matched-slot 2 1 time)
+                (set-matched-slot 1 2 time)
+                (set-matched-slot 0 3 time))
+              ((string-match "^\\([0-9][0-9]=3F\\):\\([0-9][0-9]\\)$" =
time)
+                ;; Time without seconds.
+                (set-matched-slot 2 1 time)
+                (set-matched-slot 1 2 time)
+                (set-matched-slot 0 nil 0))
+              (error
+                (signal 'date-parse-error
+                        (list "Expected a time" time)))))
+      ;; Timezone.
+      (let* ((zone (pop tokens))
+             (match (assoc zone parse-time-zoneinfo)))
+        (cond (match
+                (set-matched-slot 8 nil (cadr match))
+                (set-matched-slot 7 nil (caddr match)))
+              ((and (stringp zone)
+                    (string-match "^[-+][0-9][0-9][0-9][0-9]$" zone))
+                ;; Numeric time zone.
+                (set-matched-slot
+                  8 nil
+                  (* 60
+                     (+ (cl-parse-integer zone :start 3 :end 5)
+                        (* 60 (cl-parse-integer zone :start 1 :end 3))=
)
+                     (if (=3D (aref zone 0) =3F-) -1 1))))
+              ((and zone error)
+                (signal 'date-parse-error
+                        (list "Expected a timezone" zone)))))
+      (when (and tokens error)
+        (signal 'date-parse-error
+                (list "Extra token(s)" (car tokens)))))
+    time))
+
+(provide 'ietf-drums-date)
+
+;;; ietf-drums-date.el ends here
diff --git a/lisp/mail/ietf-drums.el b/lisp/mail/ietf-drums.el
index 85aa27235f..d1ad671b16 100644
--- a/lisp/mail/ietf-drums.el
+++ b/lisp/mail/ietf-drums.el
@@ -294,9 +294,13 @@ ietf-drums-unfold-fws
     (replace-match " " t t))
   (goto-char (point-min)))
=20
+(declare-function ietf-drums-parse-date-string "ietf-drums-date"
+                  (time-string &optional error=3F no-822=3F))
+
 (defun ietf-drums-parse-date (string)
   "Return an Emacs time spec from STRING."
-  (encode-time (parse-time-string string)))
+  (require 'ietf-drums-date)
+  (encode-time (ietf-drums-parse-date-string string)))
=20
 (defun ietf-drums-narrow-to-header ()
   "Narrow to the header section in the current buffer."
diff --git a/test/lisp/mail/ietf-drums-date-tests.el b/test/lisp/mail/i=
etf-drums-date-tests.el
new file mode 100644
index 0000000000..2d4b39dfae
--- /dev/null
+++ b/test/lisp/mail/ietf-drums-date-tests.el
@@ -0,0 +1,176 @@
+;;; ietf-drums-date-tests.el --- Test suite for ietf-drums-date.el  -*=
- lexical-binding:t -*-
+
+;; Copyright (C) 2022 Free Software Foundation, Inc.
+
+;; Author: Bob Rogers <rogers@HIDDEN>
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published b=
y
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.=

+
+;;; Commentary:
+
+;;; Code:
+
+(require 'ert)
+(require 'ietf-drums)
+(require 'ietf-drums-date)
+
+(ert-deftest ietf-drums-date-tests ()
+  "Test basic ietf-drums-parse-date-string functionality."
+
+  ;; Test tokenization.
+  (should (equal (ietf-drums-date--tokenize-string " ") '()))
+  (should (equal (ietf-drums-date--tokenize-string " a b") '("a" "b"))=
)
+  (should (equal (ietf-drums-date--tokenize-string "a bbc dde")
+                 '("a" "bbc" "dde")))
+  (should (equal (ietf-drums-date--tokenize-string " , a 27 b,, c 14:3=
2 ")
+                 '("a" 27 "b" "c" "14:32")))
+  ;; Some folding whitespace tests.
+  (should (equal (ietf-drums-date--tokenize-string " a b (end) c" t)
+                 '("a" "b")))
+  (should (equal (ietf-drums-date--tokenize-string "(quux)a (foo (bar)=
) b(baz)")
+                 '("a" "b")))
+  (should (equal (ietf-drums-date--tokenize-string "a b\\cde")
+                 ;; Strictly incorrect, but strictly unnecessary synta=
x.
+                 '("a" "b\\cde")))
+  (should (equal (ietf-drums-date--tokenize-string "a b\\ de")
+                 '("a" "b\\ de")))
+  (should (equal (ietf-drums-date--tokenize-string "a \\de \\(f")
+                 '("a" "\\de" "\\(f")))
+
+  ;; Start with some compatible RFC822 dates.
+  (dolist (case '(("Mon, 22 Feb 2016 19:35:42 +0100"
+                   (42 35 19 22 2 2016 1 -1 3600)
+                   (22219 21758))
+                  ("22 Feb 2016 19:35:42 +0100"
+                   (42 35 19 22 2 2016 nil -1 3600)
+                   (22219 21758))
+                  ("Mon, 22 February 2016 19:35:42 +0100"
+                   (42 35 19 22 2 2016 1 -1 3600)
+                   (22219 21758))
+                  ("Mon, 22 feb 2016 19:35:42 +0100"
+                   (42 35 19 22 2 2016 1 -1 3600)
+                   (22219 21758))
+                  ("Monday, 22 february 2016 19:35:42 +0100"
+                   (42 35 19 22 2 2016 1 -1 3600)
+                   (22219 21758))
+                  ("Monday, 22 february 2016 19:35:42 PST"
+                   (42 35 19 22 2 2016 1 nil -28800)
+                   (22219 54158))
+                  ("Friday, 21 Sep 2018 13:47:58 PDT"
+                   (58 47 13 21 9 2018 5 t -25200)
+                   (23461 22782))
+                  ("Friday, 21 Sep 2018 13:47:58"
+                   (58 47 13 21 9 2018 5 -1 nil)
+                   (23461 11982))))
+            (let* ((input (car case))
+                   (parsed (cadr case))
+                   (encoded (caddr case)))
+              ;; The input should parse the same without RFC822.
+              (should (equal (ietf-drums-parse-date-string input) pars=
ed))
+              (should (equal (ietf-drums-parse-date-string input nil t=
) parsed))
+              ;; Check the encoded date (the official output, though
+              ;; the decoded-time is easier to debug).
+              (should (equal (ietf-drums-parse-date input) encoded))))=

+
+  ;; Two-digit years are not allowed by the "modern" format.
+  (should (equal (ietf-drums-parse-date-string "22 Feb 16 19:35:42 +01=
00")
+                 '(42 35 19 22 2 2016 nil -1 3600)))
+  (should (equal (ietf-drums-parse-date-string "22 Feb 16 19:35:42 +01=
00" nil t)
+                 '(nil nil nil 22 2 nil nil -1 nil)))
+  (should (equal (should-error (ietf-drums-parse-date-string
+                                "22 Feb 16 19:35:42 +0100" t t))
+                 '(date-parse-error "Four-digit years are required" 16=
)))
+  (should (equal (ietf-drums-parse-date-string "22 Feb 96 19:35:42 +01=
00")
+                 '(42 35 19 22 2 1996 nil -1 3600)))
+  (should (equal (ietf-drums-parse-date-string "22 Feb 96 19:35:42 +01=
00" nil t)
+                 '(nil nil nil 22 2 nil nil -1 nil)))
+  (should (equal (should-error (ietf-drums-parse-date-string
+                                "22 Feb 96 19:35:42 +0100" t t))
+                 '(date-parse-error "Four-digit years are required" 96=
)))
+
+  ;; Try some dates with comments.
+  (should (equal (ietf-drums-parse-date-string
+                  "22 Feb (today) 16 19:35:42 +0100")
+                 '(42 35 19 22 2 2016 nil -1 3600)))
+  (should (equal (ietf-drums-parse-date-string
+                  "22 Feb (today) 16 19:35:42 +0100" nil t)
+                 '(nil nil nil 22 2 nil nil -1 nil)))
+  (should (equal (should-error (ietf-drums-parse-date-string
+                                "22 Feb (today) 16 19:35:42 +0100" t t=
))
+                 '(date-parse-error "Expected a year" nil)))
+  (should (equal (ietf-drums-parse-date-string
+                  "22 Feb 96 (long ago) 19:35:42 +0100")
+                 '(42 35 19 22 2 1996 nil -1 3600)))
+  (should (equal (ietf-drums-parse-date-string
+                  "Friday, 21 Sep(comment \\) with \\( parens)18 19:35=
:42")
+                 '(42 35 19 21 9 2018 5 -1 nil)))
+  (should (equal (ietf-drums-parse-date-string
+                  "Friday, 21 Sep 18 19:35:42 (unterminated comment")
+                 '(42 35 19 21 9 2018 5 -1 nil)))
+
+  ;; Test some RFC822 error cases
+  (dolist (test '(("33 1 2022" ("Slot out of range" day 33 1 31))
+                  ("0 1 2022" ("Slot out of range" day 0 1 31))
+                  ("1 1 2020 2021" ("Expected an alphabetic month" 1))=

+                  ("1 Jan 2020 2021" ("Expected a time" 2021))
+                  ("1 Jan 2020 20:21 2000" ("Expected a timezone" 2000=
))
+                  ("1 Jan 2020 20:21 +0200 33" ("Extra token(s)" 33)))=
)
+    (should (equal (should-error (ietf-drums-parse-date-string (car te=
st) t))
+                   (cons 'date-parse-error (cadr test)))))
+
+  (dolist (test '(("22 Feb 196" nil=09=09;; bad year
+                   ("Four-digit years are required" 196))
+                  ("22 Feb 16 19:35:24" t=09;; two-digit year
+                   ("Four-digit years are required" 16))
+                  ("22 Feb 96 19:35:42" t=09;; two-digit year
+                   ("Four-digit years are required" 96))
+                  ("2 Feb 2021 1996" nil
+                   ("Expected a time" 1996))
+                  ("22 Fub 1996" nil
+                   ("Expected an alphabetic month" "fub"))
+                  ("1 Jan 2020 30" nil
+                   ("Expected a time" 30))
+                  ("1 Jan 2020 16:47 15:15" nil
+                   ("Expected a timezone" "15:15"))
+                  ("1 Jan 2020 16:47 +0800 -0800" t
+                   ("Extra token(s)" "-0800"))
+                  ;; Range tests
+                  ("32 Dec 2021" nil
+                   ("Slot out of range" day 32 1 31))
+                  ("0 Dec 2021" nil
+                   ("Slot out of range" day 0 1 31))
+                  ("3 13 2021" nil
+                   ("Expected an alphabetic month" 13))
+                  ("3 Dec 0000" t
+                   ("Four-digit years are required" 0))
+                  ("3 Dec 20021" nil
+                   ("Slot out of range" year 20021 1 9999))
+                  ("1 Jan 2020 24:21:14" nil
+                   ("Slot out of range" hour "24:21:14" 0 23))
+                  ("1 Jan 2020 14:60:21" nil
+                   ("Slot out of range" minute "14:60:21" 0 59))
+                  ("1 Jan 2020 14:21:61" nil
+                   ("Slot out of range" second "14:21:61" 0 60))))
+    (should (equal (should-error
+                    (ietf-drums-parse-date-string (car test) t (cadr t=
est)))
+                   (cons 'date-parse-error (caddr test)))))
+  (should (equal (ietf-drums-parse-date-string
+                  "1 Jan 2020 14:21:60")=09;; a leap second!
+                 '(60 21 14 1 1 2020 nil -1 nil))))
+
+(provide 'ietf-drums-date-tests)
+
+;;; ietf-drums-date-tests.el ends here
--=20
2.34.1


--ftCty46yS8--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Feb 2022 02:18:01 +0000
Resent-Message-ID: <handler.52209.B52209.164575543120958 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Bob Rogers <rogers-emacs@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164575543120958
          (code B ref 52209); Fri, 25 Feb 2022 02:18:01 +0000
Received: (at 52209) by debbugs.gnu.org; 25 Feb 2022 02:17:11 +0000
Received: from localhost ([127.0.0.1]:50843 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNQAQ-0005Ry-Nu
	for submit <at> debbugs.gnu.org; Thu, 24 Feb 2022 21:17:10 -0500
Received: from quimby.gnus.org ([95.216.78.240]:51944)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <larsi@HIDDEN>) id 1nNQAO-0005Ri-NT
 for 52209 <at> debbugs.gnu.org; Thu, 24 Feb 2022 21:17:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
 s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
 :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=+THl4um3HTnoQHKhj6OLdy8Q9XbNuD+OaTmQ7kQxTOE=; b=OERuMyxxsMBkYsLS5qr60mGdZm
 KQn7MrRhH+CekUb1Z77iJ1nRmrIlFOf8nNXWwDFk12jJck9NrHeWvPT9Bl4FlwF5ZLh6NPn0rB1Je
 D7c+4BDUz9oDxelDch7IEZ1Au+qlKPnoYlaj6ANPcixZ8POGnZjUpJQzUvXlbgEL9PpA=;
Received: from [84.212.220.105] (helo=giant)
 by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.92) (envelope-from <larsi@HIDDEN>)
 id 1nNQAE-0004ar-2o; Fri, 25 Feb 2022 03:17:00 +0100
From: Lars Ingebrigtsen <larsi@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <87bl1428x5.fsf@HIDDEN> <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN> <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN> <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN> <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN> <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN> <87wnhphepw.fsf@HIDDEN>
 <87ilt9vicd.fsf@HIDDEN> <25106.48460.775490.619228@HIDDEN>
 <25110.49174.412406.711346@HIDDEN> <877d9k4o5s.fsf@HIDDEN>
 <25112.10122.651114.221297@HIDDEN>
X-Now-Playing: Tenniscoats's _Tan-Tan Therapy_: "Marui Hito (Everyone)"
Date: Fri, 25 Feb 2022 03:16:56 +0100
In-Reply-To: <25112.10122.651114.221297@HIDDEN> (Bob Rogers's message
 of "Thu, 24 Feb 2022 19:49:14 -0500")
Message-ID: <878rtz1yhz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 @@CONTACT_ADDRESS@@ for details.
 Content preview:  Bob Rogers <rogers-emacs@HIDDEN> writes: > Here
 it is; there should be no changes from what I last sent other than > from
 the suggestions you and Andreas made. Thanks, I got a test error: 
 Content analysis details:   (-2.9 points, 5.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Bob Rogers <rogers-emacs@HIDDEN> writes:

> Here it is; there should be no changes from what I last sent other than
> from the suggestions you and Andreas made.  Thanks,

I got a test error:

Test ietf-drums-date-tests condition:
    (ert-test-failed
     ((should
       (equal
	(ietf-drums-parse-date input)
	encoded))
      :form
      (equal
       (23460 55918)
       (23461 11982))
      :value nil :explanation
      (list-elt 0
		(different-atoms
		 (23460 "#x5ba4" "?=E5=AE=A4")
		 (23461 "#x5ba5" "?=E5=AE=A5")))))
   FAILED  1/1  ietf-drums-date-tests (0.000406 sec) at lisp/mail/ietf-drum=
s-date-tests.el:30


--=20
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates
Resent-From: Bob Rogers <rogers-emacs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 25 Feb 2022 02:33:01 +0000
Resent-Message-ID: <handler.52209.B52209.164575635022753 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 52209
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 52209 <at> debbugs.gnu.org, Andreas Schwab <schwab@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Received: via spool by 52209-submit <at> debbugs.gnu.org id=B52209.164575635022753
          (code B ref 52209); Fri, 25 Feb 2022 02:33:01 +0000
Received: (at 52209) by debbugs.gnu.org; 25 Feb 2022 02:32:30 +0000
Received: from localhost ([127.0.0.1]:50885 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1nNQPG-0005uu-JK
	for submit <at> debbugs.gnu.org; Thu, 24 Feb 2022 21:32:30 -0500
Received: from rgrjr.com ([69.164.211.47]:51214)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rogers-emacs@HIDDEN>) id 1nNQPE-0005um-5h
 for 52209 <at> debbugs.gnu.org; Thu, 24 Feb 2022 21:32:28 -0500
Received: from rgrjr.com (c-73-16-206-7.hsd1.ma.comcast.net [73.16.206.7])
 by rgrjr.com (Postfix on openSUSE) with ESMTP id E145D1D6BB2;
 Fri, 25 Feb 2022 02:32:36 +0000 (UTC)
Received: from orion.rgrjr.com (orion.rgrjr.com [192.168.0.3])
 by scorpio.rgrjr.com (Postfix on openSUSE GNU/Linux) with ESMTP id 4FC8760220; 
 Thu, 24 Feb 2022 21:32:27 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25112.16315.289584.577920@HIDDEN>
Date: Thu, 24 Feb 2022 21:32:27 -0500
From: Bob Rogers <rogers-emacs@HIDDEN>
In-Reply-To: <878rtz1yhz.fsf@HIDDEN>
References: <7c22f300-eedb-da65-db02-e82025ec2f48@HIDDEN>
 <87bl1428x5.fsf@HIDDEN>
 <25031.40994.286546.498819@HIDDEN>
 <87ee5zzjpg.fsf@HIDDEN>
 <25035.12991.328986.987982@HIDDEN>
 <87o84z782g.fsf@HIDDEN>
 <25038.8156.470964.935330@HIDDEN>
 <87lezz5x92.fsf@HIDDEN> <87h7an7bdm.fsf@HIDDEN>
 <25040.62646.635818.692654@HIDDEN>
 <87mtkd3vee.fsf@HIDDEN>
 <25043.53490.928476.622599@HIDDEN>
 <87lezudw3q.fsf@HIDDEN>
 <25046.8337.837242.510788@HIDDEN>
 <25105.33397.961104.269676@HIDDEN>
 <87wnhphepw.fsf@HIDDEN> <87ilt9vicd.fsf@HIDDEN>
 <25106.48460.775490.619228@HIDDEN>
 <25110.49174.412406.711346@HIDDEN>
 <877d9k4o5s.fsf@HIDDEN>
 <25112.10122.651114.221297@HIDDEN>
 <878rtz1yhz.fsf@HIDDEN>
X-Mailer: VM 7.19 under Emacs 29.0.50
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

   From: Lars Ingebrigtsen <larsi@HIDDEN>
   Date: Fri, 25 Feb 2022 03:16:56 +0100

   Bob Rogers <rogers-emacs@HIDDEN> writes:

   > Here it is; there should be no changes from what I last sent other than
   > from the suggestions you and Andreas made.  Thanks,

   I got a test error:

Hmm.  I bet we have a timezone issue . . .

					-- Bob





Last modified: Fri, 25 Feb 2022 02:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.