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

[Eli Zaretskii]

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