From: Lars Ingebrigtsen <larsi@gnus.org>
   Date: Tue, 21 Dec 2021 12:01:07 +0100

   Bob Rogers <rogers-emacs@rgrjr.homedns.org> writes:

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

   Yup.  That's one good reason to not have a time parsing function guess
   at formats, because the input data will be different.

OK, I have proceeded along those lines; WIP attached for feedback.  I
changed the name to "parse-date" to avoid confusion; I was otherwise
stuck when trying to come up with a sensible name for the test file,
since parse-time-tests.el was already taken (though I suppose I could
have added to the existing file).  The docstring of parse-date describes
the expected functionality as far as I've planned, with comments in
square brackets to note what's missing.

   In my previous job, we had a library to parse date/time strings, and I
   think we were up to about 80 distinct formats to handle the different
   data feeds we were getting.  For instance, "01 02 03" may be three
   different dates depending on where you get the date from.

Which (additional) formats would you like?  I'm assuming we need iso8601
and rfc822 for compatibility (in which case rfc2822 will be easy to
provide in addition), and us-date and euro-date to disambiguate the
month/day order.  Would the third format correspond to ISO 2001-01-03?
Do we want to support that?

   And come to think of it, I've been using DD-Mon-YY for my own
purposes for so long that I'm not even certain whether Americans use
MM-DD-YY or it's the other way around . . .

					-- Bob