From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bob Rogers Newsgroups: gmane.emacs.bugs Subject: bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates Date: Mon, 3 Jan 2022 23:45:38 -0500 Message-ID: <25043.53490.928476.622599@orion.rgrjr.com> References: <7c22f300-eedb-da65-db02-e82025ec2f48@cs.ucla.edu> <25023.40959.627321.685762@orion.rgrjr.com> <875yrjpp03.fsf@gnus.org> <25024.42989.718735.680188@orion.rgrjr.com> <871r26i5n0.fsf@gnus.org> <25028.53876.304365.706795@orion.rgrjr.com> <87zgoq2vwm.fsf@gnus.org> <25029.60989.564217.290743@orion.rgrjr.com> <87bl1428x5.fsf@gnus.org> <25031.40994.286546.498819@orion.rgrjr.com> <87ee5zzjpg.fsf@gnus.org> <25035.12991.328986.987982@orion.rgrjr.com> <87o84z782g.fsf@gnus.org> <25038.8156.470964.935330@orion.rgrjr.com> <87lezz5x92.fsf@gnus.org> <87h7an7bdm.fsf@igel.home> <25040.62646.635818.692654@orion.rgrjr.com> <87mtkd3vee.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52209@debbugs.gnu.org, Andreas Schwab , Paul Eggert To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 04 05:46:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4biA-0002Gw-0h for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 04 Jan 2022 05:46:14 +0100 Original-Received: from localhost ([::1]:39410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4bi8-0003w6-Kb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 Jan 2022 23:46:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4bhy-0003vi-II for bug-gnu-emacs@gnu.org; Mon, 03 Jan 2022 23:46:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n4bhy-0003sr-8R for bug-gnu-emacs@gnu.org; Mon, 03 Jan 2022 23:46:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n4bhy-0005rx-62 for bug-gnu-emacs@gnu.org; Mon, 03 Jan 2022 23:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Bob Rogers Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Jan 2022 04:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52209 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 52209-submit@debbugs.gnu.org id=B52209.164127154522537 (code B ref 52209); Tue, 04 Jan 2022 04:46:01 +0000 Original-Received: (at 52209) by debbugs.gnu.org; 4 Jan 2022 04:45:45 +0000 Original-Received: from localhost ([127.0.0.1]:36719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4bhh-0005rR-Cu for submit@debbugs.gnu.org; Mon, 03 Jan 2022 23:45:45 -0500 Original-Received: from rgrjr.com ([69.164.211.47]:40942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4bhe-0005rG-2P for 52209@debbugs.gnu.org; Mon, 03 Jan 2022 23:45:44 -0500 Original-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) Original-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) In-Reply-To: <87mtkd3vee.fsf@gnus.org> X-Mailer: VM 7.19 under Emacs 29.0.50 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:223622 Archived-At: From: Lars Ingebrigtsen Date: Mon, 03 Jan 2022 12:34:33 +0100 Bob Rogers 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