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

[Drew Adams]

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

Yes, of course - however this is resolved, the doc and the product it documents
should agree.

> `format-time-string' is a Lisp interface to the Posix function
> `strftime' from the standard C library.

That's what I question. Where does it say that that is the mission of
`format-time-string'? This is a new interpretation, AFAICT. Where does it say
that `format-time-string' must be implemented only as a transparent front end to
`strftime'?

If you _assume_ that `format-time-string' must produce Posix-compliant output,
then obviously any output that is non-compliant is inappropriate. I question
that assumption. I see nothing in the previous (or current) doc  stating that
that is the function's mandate.

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

Only if you assume what you are trying to prove. I don't see any evidence that
`format-time-string' has that restricted meaning.

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

I don't know what "valid" timezone name means, outside of a particular scheme
such as Posix that defines "valid". Outside of that, anything that makes sense
to some people as a timezone name is fair game for a function that formats time
strings. But not, of course, for a function that purports to format
Posix-compliant timezone strings.

That is the crux of the matter. "Pacific Daylight Time" might not be a valid
Posix name, but it is certainly meaningful as a timezone name for many, if not
most, users. "Yankee Doodle" will get much less user mileage. ;-) The question
is whether strings produced by `format-time-string' are _useful_, not whether
they are always Posix-compliant. There is only a proper subset of
`format-time-string' use that calls for Posix compliance.

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

No argument, for a function whose job is to produce Posix-compliant names. Call
it `format-Posix-time-string'. That's not `format-time-string' (hasn't been,
until the new behavior/interpretation).

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

That's no doubt useful for at least some users. I'd guess that any timezone
names produced by Windows are probably useful to some users. "Pacific Daylight
Time" has a lot going for it, Monsieur Posix notwithstanding.

> I submit that emitting such time-zone names instead of
> standard compliant form is a bad idea.

It's a bad idea for `format-Posix-time-string'. It's a good idea for
`format-time-string'. Quite useful.

> It is IMO better to not emit the name at all than emit the
> Windows names.

Only for `format-Posix-time-string'. It is far better to have a function (e.g.
`format-time-string') that outputs "Pacific Daylight Time' than one that can
only output "" for San Francisco's time zone. This should be obvious.

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

Of course it was. 1. It was intentional, not an accident. 2. It changed the
user-observable behavior. That's design, by definition. It's not just invisible
implementation.

If you change the "implementation" of `car' so that it returns the cdr of a
cons, that's not just an implementation change - users can see the difference.

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

That `format-time-string' must be only and always Posix-compliant is a new
interpretation. That was never the documented mission of this function. Show us
something documenting the contrary.

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

"We" do? Always? Only? That's the question. 

I don't expect these strings to always be Posix-compliant, and neither can
anyone else, justifiably, based on the documentation. Lacking a functional spec,
the doc is our guide to the intention and the expected user-visible behavior.
This Posix-only interpretation is a new invention, and represents an unwarranted
change. It's not unwarranted to provide Posix-compliance; it is unwarranted to
provide _only_ Posix compliance.

If you want a function whose output is always Posix-compliant, then create a new
one. If it is enough to have a format key for `format-time-string' that always
produces Posix-compliant output, then just add such a key. I don't (the doc
doesn't) demand that `format-time-string' _never_ produce Posix output. You are
demanding that it _always_ produce Posix output. Don't be so restrictive.

As I see it, there are two options that don't contradict the documented behavior
and yet provide both (1) Posix behavior when you want it and (2) some meaningful
timezone name, even on Windows, when you are willing to forego Posix compliance.
#1 gives you what you want for program input; #2 gives humans something
meaningful on Windows, since nonempty Posix names are currently impossible in
that context.

These are those two options: either different functions or different keys for
the same function.

A. Create a new function, `format-Posix-time-string' for the limited behavior
that you want, and keep `format-time-string' for the less restricted behavior.
(Or vice versa, though that hassles backward compatibility.)

B. Create a new format key for `format-time-string'. Assign either the new key
or %Z to the limited behavior that you want, and assign %Z or the new key to the
less restricted behavior.

IOW, please try to find a way to provide Posix functionality (good) and also
human-meaningful timezone names on Windows (also good). There is room for both.