bug#641: format-time-string %Z does not work, starting with Emacs 22.2

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <bug-gnu-emacs@gnu.org>
> Date: Tue, 5 Aug 2008 22:40:46 -0700
> 
> Now, however, the result has changed. That's breaking things. No amount of
> insulting word play about pre-broken code can change that. It is only this
> design change that breaks things.

Drew, please cool down.  I'm trying to stay technical and explain the
reasons for this change, but your tone makes it harder and harder for
me to stay technical.  If I somehow infuriated you, I apologize; this
wasn't the intent.

> > > and reduced the utility of the function
> > 
> > Please complain to Microsoft: if they modify `tzname' to be compliant,
> > the previous code can be reinstated.
> 
> Don't blame Microsoft. Microsoft doesn't produce Gnu Emacs. Nothing in the doc
> string or manual description of `format-time-string' says that it follows
> Microsoft's `tzname'. Nor should it.
> 
> And nothing in the doc string or manual description says that it must be Posix
> compliant either - even now. This is not `format-Posix-time-string'. 

I support changing the doc string, so let's leave the documentation
alone.  Let's deal with what the code does.

Let me explain again the issue and add some details.  If that still
doesn't convince you, we will have to agree to disagree.

`format-time-string' is a Lisp interface to the Posix function
`strftime' from the standard C library.  As such, it needs to produce,
under the %Z format specifier, a time-zone name whose form is expected
by programs that accept time-zone names.  It cannot produce just any
string, because that would not be expected by the receiving programs,
such as MUAs.

I'm sure you agree that if `tzname' on Windows (or on any other
platform, for that matter) produced the words of "Yankee Doodle", you
would not be arguing that we should use the result of calling such a
buggy `tzname'.  That might be an intentionally extreme example, but I
hope you agree than in general, not every possible string is
acceptable as a valid time-zone name.

Now, valid time-zone names are strings of the form xST[-]NxDT or
similar (they can also be more complicated to describe the day of the
year when the switch from standard to daylight-saving time happens).
This is what the programs that use these names expect.  Such programs
may try parsing time-zone names, e.g., to deduce the time offset or
whether daylight-saving time is in effect.

Strings we find in the Windows version of `tzname' do not follow the
above form: they are just text describing the time zone, they include
blanks, and they are localized (so instead of, e.g., "Jerusalem
Standard Time" you may well see something in Hebrew).  I submit that
emitting such time-zone names instead of standard compliant form is a
bad idea.  It is IMO better to not emit the name at all than emit the
Windows names.  Fortunately, the Posix standard of `strftime'
explicitly says that %Z could produce an empty string, so programs
that expect what %Z produces should also expect to see an empty
string.  So we decided to use this fire escape because behaving as if
`tzname' was not available on Windows is better than inducing
potential breakage on recipients of such non-standard time-zone names.

(If Windows time-zone names were always in US English, we could
perhaps repair this by translating them to the equivalent RFC-822
compliant identifiers.  But because they can also be localized, this
job is much harder, unless someone comes up with an exhaustive list of
all the possible spellings of each and every one of Windows time-zone
names.)

> This change cannot be just a reflection of an implementation difficulty (e.g.
> bad Microsoft implementation of `tzname'), because you said that it was an
> intentional design change.

It wasn't a design change.  It was a change in the implementation that
eliminated use of broken functionality of the C library.  The design
remains the same: `format-time-string' is the Emacs equivalent of
`strftime'.

> > > So? What requires `format-time-string' to use only Posix- or RFC-822 
> > > specs?
> > 
> > I explained that in my message.
> 
> You most certainly did not. What _requires_ the result to be _only_ Posix or
> RFC-822 compliant? 

The fact that we expect these strings to be consumed by other
programs, not just by humans.

I hope these explanations help.  If not, sorry: that's the best I can
do.