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

[Bob Rogers <rogers-emacs@rgrjr.homedns.org>]

   From: Lars Ingebrigtsen <larsi@gnus.org>
   Date: Sat, 25 Dec 2021 12:58:14 +0100

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

   > I'm also looking at defining a date-parse-error condition with a
   > few error symbol "subclasses," but I'm wondering about the tradeoff
   > between having enough error symbols for precision in error
   > reporting vs. cluttering the code with too many.  Thoughts?

   Having a `date-parse-error' would be fine, but I'm unsure about the
   utility of having a bunch of sub-errors, but perhaps you have a use
   case in mind?

My only motivation is that I think it would make the resulting error
message clearer.  For example, passing a malformed ISO 8601 date to
iso8601-parse just signals wrong-type-argument, which is not very
helpful.  Multiple errors would allow me to specify the problem in
detail, while still classifying them as date/time parsing errors.  Here
are four that I have in mind:

	Unknown date/time token: X
	Illegal date/time value for field: <field>, X
	Duplicate date/time value for field: <field>, X
	Date/time value for field out of range: <field>, X, <min>, <max>

This doesn't quite cover the 14 calls to `error' that are in the current
version of the code, in that they wouldn't be as precise, but they
should be adequate.

   On the other hand, this might be overkill for callers of parse-date,
who, being deep in their own logic, might only care that some date they
have to deal with is invalid.  Which is why I wanted an opinion from
someone with the big picture -- I admit I am biased (and a bit annoyed)
from too often having to study the code to figure out why some perfectly
reasonable date I supply is being misinterpreted.

					-- Bob