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--
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
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
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
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) --=-=-=--
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
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.
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--
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--
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
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
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
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
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--
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
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
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
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
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
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--
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
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.
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/
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--
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
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
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."
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
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
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
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
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
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
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
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
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
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
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."
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
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--
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
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--
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
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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.