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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 20 Oct 2011 14:58:51 +0200

> From: Andreas Schwab <[email-masked]>
> Cc: [email-masked],  [email-masked]
> Date: Thu, 20 Oct 2011 13:22:26 +0200
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > No, I don't, because setting TZ=EST or some such in the environment
> > will produce a compliant string.
> 
> It does not match [+-]NNNN.

But the output of %Z or current-time-zone isn't supposed to.  E.g., on
fencepost.gnu.org, I get "EDT".  It's %z that produces [-+]NNNN.

To step back a notch, the original issue was that 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.  I'm asking how to
do that.

With a previous "work-around" on Windows, the test was easy: the
output was a blank string, which is definitely not RFC822 compliant.
If we remove that work-around, we can get something like "Pacific
Daylight Time" instead, which is invalid according to RFC822.  I'm
asking how to detect such "invalid" zone names.