[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#9794: 24.0.90; `format-time-string' no good for %Z
Date: Thu, 20 Oct 2011 14:58:51 +0200

> From: Andreas Schwab <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 20 Oct 2011 13:22:26 +0200
> Eli Zaretskii <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]