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

> On 2024-08-13 14:11, Ulrich Mueller wrote:
>> (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".)

> If that's the only reason it's there, we can simply remove the call to
> timezone-make-date-arpa-standard. That would be better to coating the
> pig with even more lipstick.

IIUC timezone-parse-date is the function that is used for parsing a date
in the fallback code. Its function documentation says:

| Understands the following styles:
|  (1) 14 Apr 89 03:20[:12] [GMT]
|  (2) Fri, 17 Mar 89 4:01[:33] [GMT]
|  (3) Mon Jan 16 16:12[:37] [GMT] 1989
|  (4) 6 May 1992 1641-JST (Wednesday)
|  (5) 22-AUG-1993 10:59:12.82
|  (6) Thu, 11 Apr 16:17:12 91 [MET]
|  (7) Mon, 6  Jul 16:47:20 T 1992 [MET]
|  (8) 1996-06-24 21:13:12 [GMT]
|  (9) 1996-06-24 21:13-ZONE
|  (10) 19960624T211312

I've used these to make some test cases for ERT, see the attached file.
The current date-to-time correctly handles styles 1, 2, 3, 6 (without
timezone), 7 (without timezone), 8, and 10. It returns an incorrect
result for styles 4, 5, 6 (with timezone), 7 (with timezone), and 9.

If I redefine date-to-time with the fallback code removed, the test
results are identical (somewhat surprisingly).

So I'd conclude that we don't gain much from the fallback code.