bug#9794: 24.0.90; `format-time-string' no good for %Z

[Paul Eggert]

On 10/19/11 09:08, Eli Zaretskii wrote:
> Paul, would such a change be acceptable by gnulib?

That's a looooong story.  I went through the cited bug reports
and found three problems:

1.  The original problem dates back to my 1999-10-19 patch to
    editfns.c.  This patch fixed several problems by adding
    conversions between Emacs's string encoding and the underlying
    system's encoding for strings.  The patch added conversions for
    several functions, including format-time-string, but it did not
    alter current-time-zone, because I didn't think of the possibility
    that time zone names might be non-ASCII on some platforms.

    Michael Schierl reported the current-time-zone issue to RMS in 2007; see
    <http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00334.html>.
    But somehow the light bulb didn't go off, and current-time-zone
    wasn't fixed.  Instead a workaround was installed, which basically
    said "On Windows, don't ever generate time zone names, because
    they might contain non-ASCII characters."

    Now that I see this problem, I have changed current-time-zone so
    that it converts non-ASCII characters properly, which is what
    Schierl's bug report was actually about.  I installed the fix in
    the trunk, as bzr 106149.

2.  Because of the 2007 workaround, in the Windows port
    (format-time-string "%Z") always generates an empty string.  This
    is obviously wrong and is not what users expect, and should be
    fixed by reverting the Windows part of the 2007 workaround, which
    we can safely do now that the current-time-zone bug has been
    fixed.  Your patch to nt/config.nt should do this, and I agree
    it should be installed.  (There is no need to change lib/strftime.c.)

3.  There is some talk in the bug reports about time zone names and
    RFC822 compliance.  But time zone names in general do not conform
    to RFC822.  For example, on a POSIX host if you set the TZ
    environment variable as follows:

       TZ="<-8+>0"

    then (format-time-string "%Z") returns "-8+", and that's
    the correct value, even if it's not an RFC822 zone.

    Any code that assumes that (format-time-string "%Z") must generate
    an RFC822 zone is making an unwarranted assumption and should be
    fixed.  I did a quick scan for such code in Emacs and didn't find
    any.  Perhaps there's some out-of-Emacs Lisp code that's making
    the assumption, but if so, that code needs to be fixed because
    in general it does not work and has never worked.