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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ulrich Mueller <ulm@gentoo.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  72570@debbugs.gnu.org
> Date: Tue, 13 Aug 2024 17:09:14 +0200
> 
> >>>>> On Tue, 13 Aug 2024, Eli Zaretskii wrote:
> 
> > 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,
> 
> But what is the old behaviour? The one that is documented, or the actual
> behaviour of the code?

The former, IMO.  It was also the actual behavior until that commit
you found.

>   (format-time-string "%F %T" (date-to-time "2024-08-13 00:00:00"))
>   "2024-08-13 00:00:00"
> 
>   (format-time-string "%F %T" (date-to-time "2024-8-13 00:00:00"))
>   "2024-08-13 02:00:00"
> 
> In the first case, parse-time-string (inside the first condition-case)
> succeeds and it uses local time. In the second case with a slightly
> malformed date, it takes the detour via timezone-make-date-arpa-standard
> and uses UTC.

That's my point (b), I believe:

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

> Also:
> 
>   (format-time-string "%F %T" (date-to-time "2024/08/13 00:00:00"))
>   "2024-01-08 00:00:00"
> 
> The GIGO principle at its finest. :) However, I'd much prefer if the
> function would check validity of the input and error out, rather than
> returning a nonsensical result. But maybe that's another issue and
> outside the scope of this bug report.

I indeed think it's a separate issue.