* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-19 13:20 ` Jason Rumney
@ 2011-10-19 14:28 ` Drew Adams
2011-10-19 15:26 ` Eli Zaretskii
2011-10-19 16:08 ` Eli Zaretskii
2 siblings, 0 replies; 26+ messages in thread
From: Drew Adams @ 2011-10-19 14:28 UTC (permalink / raw)
To: 'Jason Rumney', 'Eli Zaretskii'; +Cc: 9794
> >> And just because a non-Windows developer thinks that letting them
> >> see "(Pacific Daylight Time)" is not useful to them and "()" is
> >> more meaningful. Sheesh.
> >
> > No, it's because a _Windows_ developer found out that the Windows
> > time-zone names violate international standards for what %Z should
> > produce, which breaks other Emacs features that use the results.
>
> The international standards alone aren't a problem - GNU software in
> general does not follow standards slavishly. The real problem is that
> for many uses of time format strings (which correctly check
> for an empty %Z string and use %z as a backup), in mail, news, HTTP
> headers, XML documents and similar uses which rely on the strings
> being standards compliant, the non-compliant long forms returned by
> Windows tzname() cause real problems which are much more severe than
> the inconveniences that this change has caused.
>
> One proposal in that thread was to introduce a new format specifier to
> print the long names (on non-Windows platforms it could output the
> commonly used "Continent/City" format). Another proposal was that %EZ
> could be used, which is especially fitting, for the Windows timezone
> names, which are apparently locale sensitive (which was one of the
> reported problems that led to them being removed in the first place).
Yes - that should be a no-brainer. The only question should be about the
details: what format specifiers with what behavior.
I suggest format specifiers that let you alternatively do all of the following
for the case of time zone names (i.e. "pretty" names, not just %z numbers).
1. Use only POSIX-compliant time-zone pretty names, which can mean "" (empty -
no available POSIX name).
2. Use any available nonempty time-zone pretty names, with priority to nonempty
POSIX-compliant pretty names.
3. Same as #2, but with priority to system-supplied names, even when a
corresponding nonempty POSIX name is available.
4. Use only nonempty POSIX-compliant pretty names, when available, and fall back
to what %z does in cases where the POSIX name is empty.
#2 and #3 would also fall back to %z when no nonempty name is available.
Again, such details should be open for discussion, but it should be clear that
_some_ fix should be found so that programmers are able to provide "pretty" time
zone info to users whenever such info is available, whether that info is POSIX
or not.
Forcing the loss of useful time-zone info just because a user-understandable
time-zone description is not understandable to POSIX puts POSIX on top and
people at the bottom. Users and Emacs programmers deserve better than that.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-19 13:20 ` Jason Rumney
2011-10-19 14:28 ` Drew Adams
@ 2011-10-19 15:26 ` Eli Zaretskii
2011-10-19 16:08 ` Eli Zaretskii
2 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-19 15:26 UTC (permalink / raw)
To: Jason Rumney; +Cc: 9794
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Drew Adams <drew.adams@oracle.com>, 9794@debbugs.gnu.org
> Date: Wed, 19 Oct 2011 21:20:06 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > No, it's because a _Windows_ developer found out that the Windows
> > time-zone names violate international standards for what %Z should
> > produce, which breaks other Emacs features that use the results.
>
> The international standards alone aren't a problem - GNU software in
> general does not follow standards slavishly. The real problem is that
> for many uses of time format strings (which correctly check for an empty
> %Z string and use %z as a backup), in mail, news, HTTP headers, XML
> documents and similar uses which rely on the strings being standards
> compliant, the non-compliant long forms returned by Windows tzname()
> cause real problems which are much more severe than the inconveniences
> that this change has caused.
Isn't that what I said: that _using_ the non-standard results of %Z
caused trouble to other Emacs features?
> One proposal in that thread was to introduce a new format specifier to
> print the long names (on non-Windows platforms it could output the
> commonly used "Continent/City" format). Another proposal was that %EZ
> could be used, which is especially fitting, for the Windows timezone
> names, which are apparently locale sensitive (which was one of the
> reported problems that led to them being removed in the first place).
Are there any problems to produce localized (i.e. non-ASCII) timezone
names in strftime? Don't Posix systems do that in some locales?
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-19 13:20 ` Jason Rumney
2011-10-19 14:28 ` Drew Adams
2011-10-19 15:26 ` Eli Zaretskii
@ 2011-10-19 16:08 ` Eli Zaretskii
2011-10-20 7:48 ` Paul Eggert
2 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-19 16:08 UTC (permalink / raw)
To: Jason Rumney, Paul Eggert; +Cc: 9794
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Drew Adams <drew.adams@oracle.com>, 9794@debbugs.gnu.org
> Date: Wed, 19 Oct 2011 21:20:06 +0800
>
> One proposal in that thread was to introduce a new format specifier to
> print the long names (on non-Windows platforms it could output the
> commonly used "Continent/City" format). Another proposal was that %EZ
> could be used, which is especially fitting, for the Windows timezone
> names, which are apparently locale sensitive (which was one of the
> reported problems that led to them being removed in the first place).
I used the %EZ format proposed by Andreas Schwab, and came up with
the Windows-specific patch below.
Paul, would such a change be acceptable by gnulib?
=== modified file 'ChangeLog'
--- ChangeLog 2011-10-18 18:12:53 +0000
+++ ChangeLog 2011-10-19 16:02:14 +0000
@@ -1,3 +1,8 @@
+2011-10-19 Eli Zaretskii <eliz@gnu.org>
+
+ * lib/strftime.c (strftime_case_) [_WIN32 || __WIN32__]: Provide
+ non-empty time-zone string only for the %EZ format specifier.
+
2011-10-18 Jan Djärv <jan.h.d@swipnet.se>
* configure.in (GLIB_REQUIRED, GTK_REQUIRED): Set to 2.10 (Bug#9786).
=== modified file 'lib/strftime.c'
--- lib/strftime.c 2011-03-31 04:24:03 +0000
+++ lib/strftime.c 2011-10-19 15:48:42 +0000
@@ -1302,6 +1302,12 @@ strftime_case_ (bool upcase, STREAM_OR_C
}
#if HAVE_TZNAME
+#if (defined _WIN32 || defined __WIN32__)
+ /* Microsoft runtime produces time-zone names that are not
+ RFC822 compliant, and are also localized. So we only
+ produce them for %EZ. */
+ if (modifier == L_('E'))
+#endif
/* The tzset() call might have changed the value. */
if (!(zone && *zone) && tp->tm_isdst >= 0)
zone = tzname[tp->tm_isdst != 0];
=== modified file 'nt/ChangeLog'
--- nt/ChangeLog 2011-09-04 21:52:59 +0000
+++ nt/ChangeLog 2011-10-19 16:02:25 +0000
@@ -1,3 +1,7 @@
+2011-10-19 Eli Zaretskii <eliz@gnu.org>
+
+ * config.nt (HAVE_TZNAME, HAVE_DECL_TZNAME): Define.
+
2011-09-04 Paul Eggert <eggert@cs.ucla.edu>
* config.nt (HAVE_SNPRINTF): New macro.
=== modified file 'nt/config.nt'
--- nt/config.nt 2011-09-26 03:20:03 +0000
+++ nt/config.nt 2011-10-19 15:57:12 +0000
@@ -187,7 +187,14 @@ along with GNU Emacs. If not, see <http
#undef TM_IN_SYS_TIME
#undef HAVE_TM_ZONE
-#undef HAVE_TZNAME
+
+/* Define to 1 if you don't have `tm_zone' but do have the external array
+ `tzname'. */
+#define HAVE_TZNAME 1
+
+/* Define to 1 if you have the declaration of `tzname', and to 0 if you don't.
+ */
+#define HAVE_DECL_TZNAME 1
#undef const
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-19 16:08 ` Eli Zaretskii
@ 2011-10-20 7:48 ` Paul Eggert
2011-10-20 9:24 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Paul Eggert @ 2011-10-20 7:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9794
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 7:48 ` Paul Eggert
@ 2011-10-20 9:24 ` Eli Zaretskii
2011-10-20 9:46 ` Andreas Schwab
2011-10-21 15:40 ` Jason Rumney
0 siblings, 2 replies; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-20 9:24 UTC (permalink / raw)
To: Paul Eggert; +Cc: 9794
> Date: Thu, 20 Oct 2011 00:48:02 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Jason Rumney <jasonr@gnu.org>, drew.adams@oracle.com,
> 9794@debbugs.gnu.org
>
> 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."
That's not a fair description of what was done. In response to my
question of whether this was too drastic a measure, Jason explained
the real reason for the change he did:
Non-ASCII is a side issue, and treating it as the main issue is what
caused us to install an incorrect fix originally.
The original issue reported a number of years ago, was that the timezone
names for the Japanese locale on Windows are not RFC 822 compliant. So
we suppressed them in certain conditions, but in fact, the timezone
names are not RFC 822 compliant in most locales on Windows. Unless we
use a lookup table to figure out which names are RFC compliant and which
aren't, then I don't see a way we can leave them enabled.
> Any code that assumes that (format-time-string "%Z") must generate
> an RFC822 zone is making an unwarranted assumption and should be
> fixed.
Fixed how? Given some arbitrary string, how can Lisp code check
whether it is or isn't compliant? Non-ASCII characters are easy to
check, but what about time zones that include only ASCII characters?
And anyway, if all bets are off about the strings returned by
current-time-zone, then what exactly is its contract?
If we are going to require Lisp code to check the values and reject
non-compliant ones, we should at the very least provide a utility
function to do that correctly. Can you suggest such a function?
> 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.
Jason, can you point out which package(s) needed an RFC822-compliant
time zone name? In the mail exchange I found, you just say
[...] since the result of current-time-zone is used for mail
headers, where non-ASCII characters are not allowed, and the POSIX
timezone names are expected [...]
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 9:24 ` Eli Zaretskii
@ 2011-10-20 9:46 ` Andreas Schwab
2011-10-20 10:05 ` Eli Zaretskii
2011-10-21 15:40 ` Jason Rumney
1 sibling, 1 reply; 26+ messages in thread
From: Andreas Schwab @ 2011-10-20 9:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Paul Eggert, 9794
Eli Zaretskii <eliz@gnu.org> writes:
> Fixed how? Given some arbitrary string, how can Lisp code check
> whether it is or isn't compliant?
By using %z.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 9:46 ` Andreas Schwab
@ 2011-10-20 10:05 ` Eli Zaretskii
2011-10-20 10:10 ` Andreas Schwab
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-20 10:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: eggert, 9794
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 9794@debbugs.gnu.org
> Date: Thu, 20 Oct 2011 11:46:06 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Fixed how? Given some arbitrary string, how can Lisp code check
> > whether it is or isn't compliant?
>
> By using %z.
That's _after_ you discover that the string returned by %Z is
non-compliant. My question was ho to discover that, sorry for being
unclear.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 10:05 ` Eli Zaretskii
@ 2011-10-20 10:10 ` Andreas Schwab
2011-10-20 10:49 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Andreas Schwab @ 2011-10-20 10:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 9794
Eli Zaretskii <eliz@gnu.org> writes:
> That's _after_ you discover that the string returned by %Z is
> non-compliant.
You know that in advance.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 10:10 ` Andreas Schwab
@ 2011-10-20 10:49 ` Eli Zaretskii
2011-10-20 11:22 ` Andreas Schwab
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-20 10:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: eggert, 9794
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: eggert@cs.ucla.edu, 9794@debbugs.gnu.org
> Date: Thu, 20 Oct 2011 12:10:52 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > That's _after_ you discover that the string returned by %Z is
> > non-compliant.
>
> You know that in advance.
No, I don't, because setting TZ=EST or some such in the environment
will produce a compliant string.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 10:49 ` Eli Zaretskii
@ 2011-10-20 11:22 ` Andreas Schwab
2011-10-20 12:58 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Andreas Schwab @ 2011-10-20 11:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 9794
Eli Zaretskii <eliz@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.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 11:22 ` Andreas Schwab
@ 2011-10-20 12:58 ` Eli Zaretskii
2011-10-20 13:06 ` Andreas Schwab
2011-10-20 15:23 ` Paul Eggert
0 siblings, 2 replies; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-20 12:58 UTC (permalink / raw)
To: Andreas Schwab; +Cc: eggert, 9794
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: eggert@cs.ucla.edu, 9794@debbugs.gnu.org
> Date: Thu, 20 Oct 2011 13:22:26 +0200
>
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 12:58 ` Eli Zaretskii
@ 2011-10-20 13:06 ` Andreas Schwab
2011-10-20 13:18 ` Eli Zaretskii
2011-10-20 15:23 ` Paul Eggert
1 sibling, 1 reply; 26+ messages in thread
From: Andreas Schwab @ 2011-10-20 13:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 9794
Eli Zaretskii <eliz@gnu.org> writes:
> It's %z that produces [-+]NNNN.
Which is exactly what is required.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 13:06 ` Andreas Schwab
@ 2011-10-20 13:18 ` Eli Zaretskii
0 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-20 13:18 UTC (permalink / raw)
To: Andreas Schwab; +Cc: eggert, 9794
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: eggert@cs.ucla.edu, 9794@debbugs.gnu.org
> Date: Thu, 20 Oct 2011 15:06:01 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > It's %z that produces [-+]NNNN.
>
> Which is exactly what is required.
But is only tangential to this bug report.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 12:58 ` Eli Zaretskii
2011-10-20 13:06 ` Andreas Schwab
@ 2011-10-20 15:23 ` Paul Eggert
2011-10-20 16:03 ` Eli Zaretskii
1 sibling, 1 reply; 26+ messages in thread
From: Paul Eggert @ 2011-10-20 15:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andreas Schwab, 9794
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".
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 15:23 ` Paul Eggert
@ 2011-10-20 16:03 ` Eli Zaretskii
0 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-20 16:03 UTC (permalink / raw)
To: Paul Eggert; +Cc: schwab, 9794
> Date: Thu, 20 Oct 2011 08:23:29 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Andreas Schwab <schwab@linux-m68k.org>, 9794@debbugs.gnu.org
>
> 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.
OK, thanks for explaining. I will wait a few days for Jason to agree
or disagree, and if no objections pop up, I will commit the changes to
config.nt.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-20 9:24 ` Eli Zaretskii
2011-10-20 9:46 ` Andreas Schwab
@ 2011-10-21 15:40 ` Jason Rumney
2011-10-21 17:34 ` Paul Eggert
2011-10-22 9:21 ` bug#641: " Eli Zaretskii
1 sibling, 2 replies; 26+ messages in thread
From: Jason Rumney @ 2011-10-21 15:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Paul Eggert, 9794
Eli Zaretskii <eliz@gnu.org> writes:
>> Any code that assumes that (format-time-string "%Z") must generate
>> an RFC822 zone is making an unwarranted assumption and should be
>> fixed.
>
> Fixed how? Given some arbitrary string, how can Lisp code check
> whether it is or isn't compliant? Non-ASCII characters are easy to
> check, but what about time zones that include only ASCII characters?
Lisp code that needs RFC822 compliance should just use %z. Only a small
subset of timezone abbreviations are allowed by RFC822:
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
So Paul is probably correct - we should not worry about RFC / POSIX or
whatever compliance for %Z.
> Jason, can you point out which package(s) needed an RFC822-compliant
> time zone name? In the mail exchange I found, you just say
>
> [...] since the result of current-time-zone is used for mail
> headers, where non-ASCII characters are not allowed, and the POSIX
> timezone names are expected [...]
A translation of the original report is here:
http://www.m17n.org/mlarchive/mule-ja/200102/msg00072.html
The original problem leading to that report seems to have been observed
in a beta version of mew:
http://groups.yahoo.co.jp/group/emacs21-users-ja/message/42
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-21 15:40 ` Jason Rumney
@ 2011-10-21 17:34 ` Paul Eggert
2011-10-22 9:21 ` bug#641: " Eli Zaretskii
1 sibling, 0 replies; 26+ messages in thread
From: Paul Eggert @ 2011-10-21 17:34 UTC (permalink / raw)
To: Jason Rumney; +Cc: Kazu Yamamoto, 9794
On 10/21/11 08:40, Jason Rumney wrote:
> The original problem leading to that report seems to have been
> observed in a beta version of mew:
> http://groups.yahoo.co.jp/group/emacs21-users-ja/message/42
Thanks, that reinforces the suggestion that we should install the
nt/config.nt patch and then mark this as done. The current
version of Mew (6.4) uses %z for the time zone, so it should work
fine. Mew also uses %Z, which it encodes and puts into an RFC822
comment, which should also work. Mew even contains a workaround
for the Emacs 22 and 23 bug where %Z generates the empty string on
Japanese Windows! If we install the nt/config.nt patch, that
should make Mew work better now, and once Mew assumes Emacs 24 or
later it can remove that workaround.
I'll CC: this to the Mew maintainer to give him a heads-up
(the the full thread is at <http://debbugs.gnu.org/9794>).
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#641: bug#9794: 24.0.90; `format-time-string' no good for %Z
2011-10-21 15:40 ` Jason Rumney
2011-10-21 17:34 ` Paul Eggert
@ 2011-10-22 9:21 ` Eli Zaretskii
1 sibling, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2011-10-22 9:21 UTC (permalink / raw)
To: Jason Rumney; +Cc: eggert, 641-done, 9794-done
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, drew.adams@oracle.com, 9794@debbugs.gnu.org
> Date: Fri, 21 Oct 2011 23:40:20 +0800
>
> So Paul is probably correct - we should not worry about RFC / POSIX or
> whatever compliance for %Z.
Thanks. So, since everybody agrees, I committed as revision 106162
the changes to nt/config.nt that make current-time-zone and the
strftime's %Z format return a non-empty string on MS-Windows.
^ permalink raw reply [flat|nested] 26+ messages in thread