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

[Lars Ingebrigtsen]

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.

>    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.  😀

>    (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.

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