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

[Ulrich Mueller <ulm@gentoo.org>]

>>>>> On Tue, 13 Aug 2024, Paul Eggert wrote:

> You're quite right that we have a chicken and egg problem, and that no
> solution will be perfect here. My point was that using a heuristic
> would be better than nothing, if the goal is to infer timezone from
> incomplete input. That's why timezone-fix-time uses this heuristic.

> I continue to think that your idea of changing date-to-time to default
> to the local time zone is the best way to move forward. How about this
> idea for doing it?

> * Change the doc to say this. This is a simple change, and it reflects
>   existing behavior better.

> * Change date-to-time so that if it falls back on
>   timezone-make-date-arpa standard, it insists that the string denotes
>   a time zone; if the string lacks a time zone it errors out with
>   "Invalid date", which it already does with invalid dates.

Sounds good.

(Assuming that the fallback code is still needed today.
From commit history in the Gnus repository, it looks like the call to
timezone-make-date-arpa-standard was first added on 2000-01-06 in
https://github.com/dabrahams/gnus/commit/f1c5b21410f6e574913bbcf97ffd5e98d9ab89ac#diff-c8e4386c2f71d2573b4b5e6549e54c51cdf1fa649c6578ebd377f84e27576c93L32 .
The rationale for the change was to make the function "... more robust,
e.g. against the crop of year 100 dates in Jan 2000".)