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

Previous Next

Full log

Message #264 received at 641-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: eggert <at> cs.ucla.edu, 641-done <at> debbugs.gnu.org, 9794-done <at> debbugs.gnu.org,
	jasonr <at> gnu.org
Subject: Re: bug#9794: 24.0.90; `format-time-string' no good for %Z
Date: Sat, 22 Oct 2011 17:24:44 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <eggert <at> cs.ucla.edu>, <9794-done <at> debbugs.gnu.org>,
>         <641-done <at> debbugs.gnu.org>
> Date: Sat, 22 Oct 2011 07:27:44 -0700
> 
> > Thanks.  So, since everybody agrees,
> 
> ?

!

> Just what is the non-empty string that is returned on Windows?

The one provided by Windows.

> Is it the
> informative name that Windows provides (e.g., "(Pacific Daylight Time)")

Yes.  The strings come from the Registry, you can look them up there
(for the exact key, see the discussions wrt bug #641).

> or just the %z numerical offset

No.  If you want the numerical offset, use %z in format-time-string.

> or something else again?

No.

> What about this?
> 
> > 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.

I don't see a need to provide all these features, certainly not as
part of these two bug reports, as we are now back where we were in
Emacs 22.  All the regressions were fixed, some by Paul in revision
106149, and the rest by revision 106162 I committed today.

If you still think you need the other options, please file a wishlist
bug report, because Emacs never had those features.

My take on these options is that #3 is what you have after these last
changes, #4 needs a simple test to decide whether to fall back to %z,
and the rest are impractical, because there's no good way of mapping
an arbitrary (possibly non-ASCII) string returned by Windows to the 1-
or 3-letter zones from the short list allowed by RFC 822.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.