bug#52209: 28.0.60; [PATCH] date-to-time fails on pure dates

[Bob Rogers]

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

   Bob Rogers <rogers-emacs@rgrjr.homedns.org> 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