bug#72570: 31.0.50; Regression in date-to-time

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 12 Aug 2024 15:03:46 -0700
> Cc: 72570@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-08-12 04:42, Eli Zaretskii wrote:
> > Paul, any suggestions?  And can we please document the missing
> > time-zone assumptions?
> 
> Not sure what documentation is missing, but I went through the doc for 
> parse-time-string and iso8601-parse and found some room for improvement 
> and so installed the attached.

Thanks, but that doesn't document what I found missing: the
interpretation of the missing time-zone information.  Maybe you
consider it unnecessary to mention these defaults in the doc strings
of parse-time-string and iso8601-parse, but it is something I kept
asking myself when I tried to understand what does date-to-time do
when called without time-zone argument.  At the very least we should
say that without TZ information, these functions return nil as the
time zone/UTC offset, and that the interpretation of that nil is up to
the APIs that the program will call with these results.  Also, it
would be good to document what will these functions do when the TZ
information _is_ supplied: will they still just parse the string into
numbers, or will they convert the date/time to UTC?

> As for the original issue, I tend to agree with Ulrich that date-to-time 
> should default to local time. This would need changes to both 
> documentation and to code. Ulrich mentioned the following potential 
> issue with this idea:
> 
> > The problem is that
> > timezone-make-date-arpa-standard would need an explicit timezone as its
> > second argument, which we don't know.
> 
> The code could use timezone-time-zone-from-absolute to infer a timezone. 
> timezone-fix-time already does this sort of thing. Admittedly getting 
> the details right could be a bit tricky, and there is no perfect 
> solution in this area (certainly timezone-fix-time is flawed). It might 
> be good enough, though.

The change which affected behavior that triggered this discussion was
done because evidently timezone-time-zone-from-absolute was deemed to
be too slow, and therefore the authors of the change wanted to avoid
it.  I'm okay with making the result of that change the de-facto
default, but then (a) we should document this change in NEWS including
the (trivial) way of getting back old behavior, and (b) make sure that
the new behavior happens even if the body of this condition-case in
date-to-time:

  (condition-case err
      (let ((parsed (parse-time-string date)))
	(when (decoded-time-year parsed)
	  (decoded-time-set-defaults parsed))
	(encode-time parsed))

does not signal an error.