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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ulrich Mueller <ulm@gentoo.org>
> Date: Sun, 11 Aug 2024 10:57:57 +0200
> 
> Function documentation of 'date-to-time' says:
> "If DATE lacks timezone information, GMT is assumed."
> 
> Also, the Lispref Manual:
> "This function assumes Universal Time if STRING lacks explicit time zone
> information, ..."
> 
>   (format-time-string
>    "%Y-%m-%d %H:%M:%S" (date-to-time "2024-01-01 00:00:00") t)
> 
> returns "2023-12-31 23:00:00" as its result, while I would expect
> "2024-01-01 00:00:00" with both conversions being in the same (UTC)
> timezone. Apparently, date-to-time incorrectly uses the local timezone
> (Europe/Berlin) instead of UTC.
> 
> In Emacs 23.4 the function worked as expected.
> 
> Git bisecting points to this commit:
> 
>   commit b069e5a697f37a06704136a8d5376b4d088658c8 (HEAD)
>   Author: Gnus developers <ding@gnus.org>
>   Date:   Thu Sep 23 00:30:37 2010 +0000
> 
>       Merge Changes made in Gnus trunk.
> 
>       [...]
>       time-date.el (date-to-time): Speed up date-to-time.
>       [...]

That commit made this change in date-to-time:

  -      (apply 'encode-time
  -            (parse-time-string
  -             ;; `parse-time-string' isn't sufficiently general or
  -             ;; robust.  It fails to grok some of the formats that
  -             ;; timezone does (e.g. dodgy post-2000 stuff from some
  -             ;; Elms) and either fails or returns bogus values.  Lars
  -             ;; reverted this change, but that loses non-trivially
  -             ;; often for me.  -- fx
  -             (timezone-make-date-arpa-standard date)))
  -    (error (error "Invalid date: %s" date))))
  +      (apply 'encode-time (parse-time-string date))
  +    (error (condition-case ()
  +              (apply 'encode-time
  +                     (parse-time-string
  +                      (timezone-make-date-arpa-standard date)))
  +            (error (error "Invalid date: %s" date))))))

IOW, it applied parse-time-string to the argument DATE instead of
first running it through timezone-make-date-arpa-standard.

But that is not necessarily incorrect, because several time-conversion
functions, including those involved in this issue, don't document
their assumptions about time-zone when it is omitted.  This includes
parse-time-string and iso8601-parse.  Since these functions don't
document this aspect, and the code involved in the above snippet is
quite convoluted, it is hard for me to decide which part of what
function needs to be fixed.

Paul, any suggestions?  And can we please document the missing
time-zone assumptions?