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

[Paul Eggert <eggert@cs.ucla.edu>]

On 10/20/11 05:58, Eli Zaretskii wrote:
> current-time-zone
> can produce strings that are not RFC822 compliant, even on a Posix
> system, if the luser sets TZ to some arbitrary string.  Paul says that
> any software that uses the output of current-time-zone should be able
> to detect this non-compliance and use %z instead.

Perhaps I wasn't clear enough, as I didn't intend to imply anything
about detecting non-compliance.  Let me try to explain in more detail.

Software cannot simply use %Z and then filter out invalid strings,
because sometimes the %Z output can be a valid RFC822 string and
still be wrong.  For example, in eastern Australia the time zone
name is typically "EST", a valid RFC822 zone, but using "EST" is
wrong because RFC822 says EST is equivalent to 5 hours behind UTC,
whereas Australian EST is equivalent to 10 or 11 hours ahead of UTC.
An inhabitant of Sydney should put "+1000" or "+1100" in outgoing
email, not "EST".  (Australians commonly use the same abbreviation
for both Eastern Standard Time and Eastern Summer Time.)

The simplest way around the problem, which is what Emacs Lisp
code does now, is to follow Andreas's advice use %z.  Any
outside-of-Emacs Lisp code that uses %Z for RFC822 zones should
be fixed to use %z, because %Z does not work and has never worked
in general.

There are more-complicated solutions if you reeeeaaalllly want
the RFC822 symbolic names, but nobody uses them, for good reason.
In the email world, these symbolic names are obsolete, because
of problems like the above.  RFC2822, the successor to RFC822,
describes them in its section 4.3 ("Obsolete Date and Time"),
and says in section 1.3 that obsolete forms such as these
"MUST NOT be generated by creators of conformant messages".
Anybody who uses %Z to generate RFC822 headers is not conforming
to the current email standards, even if they are in the US eastern
time zone and are generating "EDT" and "EST".