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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: eggert <at> cs.ucla.edu, 9794 <at> debbugs.gnu.org
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 <schwab <at> linux-m68k.org>
> Cc: eggert <at> cs.ucla.edu,  9794 <at> debbugs.gnu.org
> Date: Thu, 20 Oct 2011 13:22:26 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.