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

[Bob Rogers]

   From: Lars Ingebrigtsen <larsi@gnus.org>
   Date: Mon, 20 Dec 2021 11:08:44 +0100

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