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

[Bob Rogers]

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

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