[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: bug#641: format-time-string %Z does not work, starting with Emacs 22.2
Date: Tue, 5 Aug 2008 22:40:46 -0700

> Code that didn't expect "" from %Z was already broken.

Oh really? Did the doc say that the timezone name could be empty? Did it say
that it would _always_ be empty on Windows? 

No, I don't think so - and it still does not say that. There is nothing that
would lead one to believe that the timezone name could be empty. And certainly
nothing that would lead one to believe that it will _always_ be empty (on

The result was always the same previously, and it always agreed with the doc
string and the manual. Why then should user code not expect such a result? It
worked, and it reflected the doc. It did what it said. Nothing broken about

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.

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

Again, think about how Posix compliance was added for regexps - we didn't just
willy nilly redesign `re-search-forward' to suddenly be Posix compliant,
claiming that any existing code expecting the previous behavior was always
"broken" anyway because it didn't expect the Posix behavior. No, we added a new
function, `posix-search-forward'. And that's TRT.

Please don't blame an unfortunate _design_ change on nasty old Microsoft or on
any other implementation detail. The previous implementation did not have this
problem. If the previous implementation had the different problem of not
offering Posix compliance, then add that feature, but don't take away other
functionality in order to add it.

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. You can't have it both ways.

> > Not only does it break my existing code, but I don't see 
> > any way now to get a timezone name (on Windows) even by changing
> > the code. Can you tell me how to do that?
> I'd use %z.

What about timezone _name_ do you not understand? The doc says that %Z produces
a timezone name. %z does not do that, ever. And %Z no longer does that either.
Contrary to the doc, there is now no way to get a timezone name on Windows. And
there used to be - that's a regression. The function used to do what its doc
said and still says, but it no longer does what it says (on Windows, at least).
That's a regression.

> > > "Pacific Daylight Time" is not a Posix- or RFC-822 
> > > compliant timezone specification.
> > 
> > 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? 

This is an Emacs function. It can return anything GNU wants it to return. It can
be made to return Posix _and_ non-Posix. You've given no reason why the result
_must always_ be Posix compliant, and why the best we can ever do is return ""
for the timezone name on Windows. We know we can do better, because we have
always done better before. It wasn't bad old Microsoft that changed things here,
returning "" instead of "Pacific Daylight Time"; it was good old GNU.

Why can't there be two format keys, say (1) %Z for what it's always been and (2)
some new key for Posix-compliant timezone names (including the empty "name" "")?
Why not add functionality instead of subtracting it?

> > If you absolutely need a Posix-compliant spec for some use 
> > (e.g. mail), why don't you add a new one - %P
> %Z is already a Posix format.

* You said that what it produced was _not_ Posix format previously - hence the
"needed" change.

* In any case, the doc string and manual don't say anything about %Z being Posix
compliant. Even now. You've pointed to absolutely nothing that forces a change
in behavior (i.e. in meaning) for %Z here. You've given no reason for not
introducing a different format key for Posix, instead of hijacking
`format-time-string's %Z to give it a new meaning and put it in line with
Posix's %Z.

Be reasonable. There are two bad things happening here:

1. %Z has changed, so code that needs to work with multiple Emacs versions now
has to have multiple implementations. IOW, you've broken backward compatibility.

2. Even if a user decides to recode to adapt to the changed meaning of %Z, there
is no solution. There is now _no_ way to get a (non-empty) timezone name (on

I don't care so much about #1, though I think it is unwise to make such a change
instead of adding a new format key for the new behavior. But sometimes backward
incompatibility is justified.

If it's important to you that %Z be changed to be Posix compliant (e.g. because
"%Z" is also used by Posix), fine. Then please add a new key that does what %Z
used to do (non-compliant timezone string). That works too, even if it requires
code to jump through some version hoops (minor ugliness). One way or the other,
please provide _both_ if you want to add Posix compliance - give us some way to
get a timezone name on Windows.

IOW, it is #2 that is a real problem - you have added functionality, but you
have also taken away functionality unnecessarily. Please reconsider.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]