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

From: "Drew Adams" <[email-masked]>
Date: Wed, 19 Oct 2011 07:28:51 -0700

> >> 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.