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

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

[martin rudalics]

 > emacs -Q
 > M-: (format-time-string "%Z) ==> ""
 > M-: (format-time-string "%z) ==> "-0700"
 >
 > The %Z string is incorrect. In my case, it should be (as it is in
 > Emacs 20 and Emacs 22.1): "Pacific Daylight Time".
 >
 > This same bug appears in Emacs 23.  This is a regression from Emacs
 > 22.1.

See

2007-06-07  Jason Rumney  <jasonr@gnu.org>

	* s/ms-w32.h: Don't define HAVE_TZNAME.

	* editfns.c (Fcurrent_time_zone): Remove hack for Japanese Windows.

and the preceding discussion starting with

http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00334.html

martin

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

[Drew Adams]

> From: martin rudalics Sent: Monday, August 04, 2008 2:24 PM
>  > emacs -Q
>  > M-: (format-time-string "%Z) ==> ""
>  > M-: (format-time-string "%z) ==> "-0700"
>  >
>  > The %Z string is incorrect. In my case, it should be (as it is in
>  > Emacs 20 and Emacs 22.1): "Pacific Daylight Time".
>  >
>  > This same bug appears in Emacs 23.  This is a regression from Emacs
>  > 22.1.
> 
> See
> 2007-06-07  Jason Rumney  <jasonr@gnu.org>
> 	* s/ms-w32.h: Don't define HAVE_TZNAME.
> 	* editfns.c (Fcurrent_time_zone): Remove hack for 
>       Japanese Windows.
> 
> and the preceding discussion starting with
> http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00334.html

Sorry; I don't know what all of that means.

It is obviously a bug, however, that %Z produces an empty time-zone string. I
use it for a time stamp, for instance, with this form:
 (format-time-string "%a %b %e %T %Y (%Z)")

After the change that introduced the bug, I get this:

Mon Aug  4 15:01:16 2008 ()

instead of this:

Mon Aug  4 15:01:16 2008 (Pacific Daylight Time)

The doc string for `format-time-string' says that "%Z is the time zone name". My
time zone name is "Pacific Daylight Time" (or something similar). It is
certainly not "".

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

[martin rudalics]

 >>	* s/ms-w32.h: Don't define HAVE_TZNAME.
[...]
 > Sorry; I don't know what all of that means.

Jason did undefine HAVE_TZNAME on Windows in order to fix a bug with
`current-time-zone'.  As a consequence, the following code in strftime.c

#if HAVE_TZNAME
	  /* The tzset() call might have changed the value.  */
	  if (!(zone && *zone) && tp->tm_isdst >= 0)
	    zone = tzname[tp->tm_isdst];
#endif
	  if (! zone)
	    zone = "";

will produce an empty zone string on Windows.

I suppose we need different strategies for handling `current-time-zone'
and `format-time-string' on Windows.

martin

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 4 Aug 2008 15:07:28 -0700
> Cc: 
> 
> > From: martin rudalics Sent: Monday, August 04, 2008 2:24 PM
> >  > emacs -Q
> >  > M-: (format-time-string "%Z) ==> ""
> >  > M-: (format-time-string "%z) ==> "-0700"
> >  >
> >  > The %Z string is incorrect. In my case, it should be (as it is in
> >  > Emacs 20 and Emacs 22.1): "Pacific Daylight Time".
> >  >
> >  > This same bug appears in Emacs 23.  This is a regression from Emacs
> >  > 22.1.
> > 
> > See
> > 2007-06-07  Jason Rumney  <jasonr@gnu.org>
> > 	* s/ms-w32.h: Don't define HAVE_TZNAME.
> > 	* editfns.c (Fcurrent_time_zone): Remove hack for 
> >       Japanese Windows.
> > 
> > and the preceding discussion starting with
> > http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00334.html
> 
> Sorry; I don't know what all of that means.

What it means is that we did this on purpose, and therefore the fact
you get an empty string for %Z is not a bug.

> It is obviously a bug, however, that %Z produces an empty time-zone string. I
> use it for a time stamp, for instance, with this form:
>  (format-time-string "%a %b %e %T %Y (%Z)")
> 
> After the change that introduced the bug, I get this:
> 
> Mon Aug  4 15:01:16 2008 ()
> 
> instead of this:
> 
> Mon Aug  4 15:01:16 2008 (Pacific Daylight Time)

"Pacific Daylight Time" is not a Posix- or RFC-822 compliant timezone
specification.  It comes from the MS-Windows version of `tzname',
which produces RFC-compliant TZ strings only for a very small subset
of timezone specifications, and even that only after you call `tzset'
from within an application.  So we disabled the use of `tzname' on
Windows to avoid producing non-compliant timezone strings, which could
break others, e.g. if used in an email message header.

Posix specifies that if `tzname' is not available, %Z should produce
an empty string.  This means that an empty string is a valid result of
format-time-string for %Z, and if you use %Z in your Lisp code, you
should make allowances for the case of an empty string, no matter on
which platform.

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

[Drew Adams]

> > > From: martin rudalics Sent: Monday, August 04, 2008 2:24 PM
> > >  > emacs -Q
> > >  > M-: (format-time-string "%Z) ==> ""
> > >  > M-: (format-time-string "%z) ==> "-0700"
> > >  >
> > >  > The %Z string is incorrect. In my case, it should be 
> > >  > (as it is in
> > >  > Emacs 20 and Emacs 22.1): "Pacific Daylight Time".
> > >  >
> > >  > This same bug appears in Emacs 23.  This is a 
> > >  > regression from Emacs 22.1.
> > > 
> > > See
> > > 2007-06-07  Jason Rumney  <jasonr@gnu.org>
> > > 	* s/ms-w32.h: Don't define HAVE_TZNAME.
> > > 	* editfns.c (Fcurrent_time_zone): Remove hack for 
> > >       Japanese Windows.
> > > 
> > > and the preceding discussion starting with
> > > http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg00334.html
> > 
> > Sorry; I don't know what all of that means.
> 
> What it means is that we did this on purpose, and therefore the fact
> you get an empty string for %Z is not a bug.

OK, call it an incompatible change, if you prefer. You intentionally broke
existing code and reduced the utility of the function and the fidelity of its
doc string and Elisp doc. 

Count me as one user who disagrees with the change, whether bug or by design.
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? If so, please document it.
 
> > It is obviously a bug, however, that %Z produces an empty 
> > time-zone string. I use it for a time stamp, for instance,
> > with this form:
> >  (format-time-string "%a %b %e %T %Y (%Z)")
> > 
> > After the change that introduced the bug, I get this:
> > Mon Aug  4 15:01:16 2008 ()
> > instead of this:
> > Mon Aug  4 15:01:16 2008 (Pacific Daylight Time)
> 
> "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?

* The doc string says nothing about Posix or RFC-822.
  The Elisp manual is just as silent about this.

* The function previously DTRT for %Z, at least on Windows.

* The doc string still refers to %Z as producing the timezone name, and "" is
surely not a timezone name (for humans, even if it is for Posix). I'd call that,
in itself, a bug - at the very least, a doc bug. Or did you also intentionally
make the doc speak against the behavior?

* The Elisp manual says that %Z produces "the time zone abbreviation (e.g.,
`EST')", which is different from what the doc string says ("name" vs
"abbreviation"), and which is apparently also wrong. In Emacs 22, I get "Pacific
Daylight Time", not "PDT" (on Windows).

* %Z producing "" is less useful (not useful at all, in my eyes) for most
purposes, even if it is a Posix- or RFC-822 compliant timezone spec.

> It comes from the MS-Windows version of `tzname',
> which produces RFC-compliant TZ strings only for a very small subset
> of timezone specifications, and even that only after you call `tzset'
> from within an application.  So we disabled the use of `tzname' on
> Windows to avoid producing non-compliant timezone strings, which could
> break others, e.g. if used in an email message header.
>
> Posix specifies that if `tzname' is not available, %Z should produce
> an empty string.  This means that an empty string is a valid result of
> format-time-string for %Z, and if you use %Z in your Lisp code, you
> should make allowances for the case of an empty string, no matter on
> which platform.

The doc string does not mention this. And it does not refer the reader to the
Posix spec (which would be only slightly more help than saying nothing).

AFAICT, the functionality and usefulness has been reduced. At least on Windows,
IIUC, one can no longer use %Z - you just get "", which is useless. This is
strictly a loss, whatever plusses elsewhere might be seen to compensate it.

If you absolutely need a Posix-compliant spec for some use (e.g. mail), why
don't you add a new one - %P, for instance, instead of changing the meaning and
behavior of the existing %Z and thus introducing incompatibility? We didn't
change the Emacs regexp syntax when we introduced Posix regexp support - we
added separate Posix functions (that's TRT).

IIUC, you offer Windows users no way to get a timezone name now. You certainly
don't offer the *same* way to do that, so even if there is a way (is there?), it
means needing different code for different Emacs versions.

Are you really convinced this is TRT?

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 16:54:32 -0700
> 
> You intentionally broke existing code

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

> and reduced the utility of the function

Please complain to Microsoft: if they modify `tzname' to be compliant,
the previous code can be reinstated.

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

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

> AFAICT, the functionality and usefulness has been reduced.

I understood your opinion the first time, no need to repeat it over
and over again.

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

> Are you really convinced this is TRT?

Yes.

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

[Drew Adams]

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

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

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

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.

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.

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.

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

[Juanma Barranquero]

On Wed, Aug 6, 2008 at 21:48, Drew Adams <drew.adams@oracle.com> wrote:

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

At the time the function was introduced, the docstring clearly said:
"The number of options reflects the strftime(3) function."

http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/editfns.c?r1=1.67&r2=1.68&pathrev=HEAD

Two years later Richard rewrote the docstring and that bit disappeared:

http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/editfns.c?r1=1.153&r2=1.154&pathrev=HEAD

It is open to interpretation (or asking him) whether the intent was to
detach strftime from format-time-string or not.

 Juanma

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

[Drew Adams]

> At the time the function was introduced, the docstring clearly said:
> "The number of options reflects the strftime(3) function."
> http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/editfns.c?r
> 1=1.67&r2=1.68&pathrev=HEAD
> 
> Two years later Richard rewrote the docstring and that bit 
> disappeared:
> http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/editfns.c?r
> 1=1.153&r2=1.154&pathrev=HEAD
> 
> It is open to interpretation (or asking him) whether the intent was to
> detach strftime from format-time-string or not.

OK, thanks.

I really don't care which function lets you format a time to produce a timezone
name on Windows. If `format-time-string' continued to do that, that would be
more backward-compatible, but that's not a biggee. It would be fine if it were
some other function  (or some other format key, besides %Z) that provided this
feature. Just so we don't lose all ability to do this.

For the record, I probably will use %z for my application. But I feel
nevertheless that we should continue to provide some way to produce a timezone
name (on Windows), however rudimentary, language-specific, or non-compliant that
name might be.

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

[Juanma Barranquero]

On Thu, Aug 7, 2008 at 01:05, Drew Adams <drew.adams@oracle.com> wrote:

> But I feel
> nevertheless that we should continue to provide some way to produce a timezone
> name (on Windows), however rudimentary, language-specific, or non-compliant that
> name might be.

IMHO, Windows timezone names (because of its non-standard nature,
localization and, often, bad translations) are a waste of time and we
should not invest resources in trying to do anything with them.

   Juanma

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

[Ted Zlatanov]

On Wed, 06 Aug 2008 21:53:58 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

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

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

Does this help?  The Microsoft documentation linked by this article
implies that GetTimeZoneInformation() will DTRT.

http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It%27s%20a%20Hard%20Problem.html

Ted

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Wed, 06 Aug 2008 14:53:12 -0500
> 
> Does this help?  The Microsoft documentation linked by this article
> implies that GetTimeZoneInformation() will DTRT.
> 
> http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It%27s%20a%20Hard%20Problem.html

Thanks, but unfortunately it doesn't help.

That article explains how to know and apply the complicated rules of
the switch to DST.  Windows XP already knows that: the relevant rules,
which on Posix machines are in the /usr/share/zoneinfo directory, are
stored on Windows in the Registry.  And last year, when the US
switched to complex DST rules, Microsoft published an update that
imported the DST rules for most of the world into the Registry, so now
every Windows installation can automatically switch to DST and back.

But this is a different problem.  The problem I wanted to solve is to
get something like JST+2JDT instead of "Jerusalem Daylight Time".  And
that cannot be solved by using Windows API, AFAIK, because the latter
is what Windows stores as the TZ name in its database.  In particular,
a test program that prints the TZ name returned by
GetTimeZoneInformation is the same "Jerusalem Daylight Time" that we
find in `tzname'.  I don't think RFC-822 compliant TZ names such as
EST-5EDT can be found anywhere in the Windows APIs and libraries, but
I'd be glad to be proven wrong.

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

[Juanma Barranquero]

On Wed, Aug 6, 2008 at 21:53, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Does this help?  The Microsoft documentation linked by this article
> implies that GetTimeZoneInformation() will DTRT.
>
> http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It%27s%20a%20Hard%20Problem.html

It does return the "Microsoft timezone name", not Posix. In my system,
it currently returns "Hora de verano romance".

   Juanma

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

[Ted Zlatanov]

On Wed, 6 Aug 2008 23:35:16 +0200 "Juanma Barranquero" <lekktu@gmail.com> wrote: 

JB> On Wed, Aug 6, 2008 at 21:53, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Does this help?  The Microsoft documentation linked by this article
>> implies that GetTimeZoneInformation() will DTRT.
>> 
>> http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It%27s%20a%20Hard%20Problem.html

JB> It does return the "Microsoft timezone name", not Posix. In my system,
JB> it currently returns "Hora de verano romance".

On Thu, 07 Aug 2008 00:20:36 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> But this is a different problem.  The problem I wanted to solve is to
EZ> get something like JST+2JDT instead of "Jerusalem Daylight Time".  And
EZ> that cannot be solved by using Windows API, AFAIK, because the latter
EZ> is what Windows stores as the TZ name in its database.  In particular,
EZ> a test program that prints the TZ name returned by
EZ> GetTimeZoneInformation is the same "Jerusalem Daylight Time" that we
EZ> find in `tzname'.  I don't think RFC-822 compliant TZ names such as
EZ> EST-5EDT can be found anywhere in the Windows APIs and libraries, but
EZ> I'd be glad to be proven wrong.

We could build a database of known Microsoft timezones and map them to
ISO timezones.  It has to be done just once and then updated very
rarely--timezone names don't change often.  The full list of timezones
is in 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones 

according to the article, so it may be possible to build the full list
of keys on a single machine and then fill it in with the mappings.

Ted

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Thu, 07 Aug 2008 08:20:46 -0500
> 
> We could build a database of known Microsoft timezones and map them to
> ISO timezones.  It has to be done just once and then updated very
> rarely--timezone names don't change often.  The full list of timezones
> is in 
> 
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones 

I already mentioned this possibility in an earlier message here.  The
problem is that what you actually see in `tzname' could be a localized
name, not the US English name.  So unless someone finds (or crafts) an
exhaustive list of all TZ names both in English and in any localized
language to which each one could be translated by Windows, this will
work only on some machines.

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

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Thu, 07 Aug 2008 08:20:46 -0500
>>
>> We could build a database of known Microsoft timezones and map them to
>> ISO timezones.  It has to be done just once and then updated very
>> rarely--timezone names don't change often.  The full list of timezones
>> is in 
>>
>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones 
> 
> I already mentioned this possibility in an earlier message here.  The
> problem is that what you actually see in `tzname' could be a localized
> name, not the US English name.  So unless someone finds (or crafts) an
> exhaustive list of all TZ names both in English and in any localized
> language to which each one could be translated by Windows, this will
> work only on some machines.


How many time zones are there?

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

[Eli Zaretskii]

> Date: Thu, 07 Aug 2008 20:51:11 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: Ted Zlatanov <tzz@lifelogs.com>, bug-gnu-emacs@gnu.org
> 
> Eli Zaretskii wrote:
> >> From: Ted Zlatanov <tzz@lifelogs.com>
> >> Date: Thu, 07 Aug 2008 08:20:46 -0500
> >>
> >> We could build a database of known Microsoft timezones and map them to
> >> ISO timezones.  It has to be done just once and then updated very
> >> rarely--timezone names don't change often.  The full list of timezones
> >> is in 
> >>
> >> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones 
> > 
> > I already mentioned this possibility in an earlier message here.  The
> > problem is that what you actually see in `tzname' could be a localized
> > name, not the US English name.  So unless someone finds (or crafts) an
> > exhaustive list of all TZ names both in English and in any localized
> > language to which each one could be translated by Windows, this will
> > work only on some machines.
> 
> 
> How many time zones are there?

I see 87 on my machine.

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

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Thu, 07 Aug 2008 20:51:11 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: Ted Zlatanov <tzz@lifelogs.com>, bug-gnu-emacs@gnu.org
>>
>> Eli Zaretskii wrote:
>>>> From: Ted Zlatanov <tzz@lifelogs.com>
>>>> Date: Thu, 07 Aug 2008 08:20:46 -0500
>>>>
>>>> We could build a database of known Microsoft timezones and map them to
>>>> ISO timezones.  It has to be done just once and then updated very
>>>> rarely--timezone names don't change often.  The full list of timezones
>>>> is in 
>>>>
>>>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones 
>>> I already mentioned this possibility in an earlier message here.  The
>>> problem is that what you actually see in `tzname' could be a localized
>>> name, not the US English name.  So unless someone finds (or crafts) an
>>> exhaustive list of all TZ names both in English and in any localized
>>> language to which each one could be translated by Windows, this will
>>> work only on some machines.
>>
>> How many time zones are there?
> 
> I see 87 on my machine.

Does that mean that there is a mapping one to many from the numeric 
format to the string format? How is that resolved?

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

[Eli Zaretskii]

> Date: Thu, 07 Aug 2008 22:14:10 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: tzz@lifelogs.com, bug-gnu-emacs@gnu.org
> 
> >> How many time zones are there?
> > 
> > I see 87 on my machine.
> 
> Does that mean that there is a mapping one to many from the numeric 
> format to the string format? How is that resolved?

Sorry, I'm not following: what numeric format? how is what resolved?

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

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Thu, 07 Aug 2008 22:14:10 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: tzz@lifelogs.com, bug-gnu-emacs@gnu.org
>>
>>>> How many time zones are there?
>>> I see 87 on my machine.
>> Does that mean that there is a mapping one to many from the numeric 
>> format to the string format? How is that resolved?
> 
> Sorry, I'm not following: what numeric format? how is what resolved?

I guess I am missing something. And I express my self a bit lazy.

I mean that the time zone is known, it can be get with "%z". This gives 
things like "+0200". This is in essence a number.

I would expect there to be just a little bit more than 24 possible 
different return values from "%z". It would be 24 if all zones where 
whole hours different from UTC (or what it is called now). But since 
some zones uses half hours it could be more.

However 87 is a surprisingly high figure for me.

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

[Juanma Barranquero]

On Thu, Aug 7, 2008 at 22:36, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> I would expect there to be just a little bit more than 24 possible different
> return values from "%z". It would be 24 if all zones where whole hours
> different from UTC (or what it is called now). But since some zones uses
> half hours it could be more.
>
> However 87 is a surprisingly high figure for me.

You're assuming too much. Countries in the same apparent time zone do
not have to follow the same DST rules, for example.

   Juanma

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

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Thu, Aug 7, 2008 at 22:36, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>> I would expect there to be just a little bit more than 24 possible different
>> return values from "%z". It would be 24 if all zones where whole hours
>> different from UTC (or what it is called now). But since some zones uses
>> half hours it could be more.
>>
>> However 87 is a surprisingly high figure for me.
> 
> You're assuming too much. Countries in the same apparent time zone do
> not have to follow the same DST rules, for example.

Yes, I surely am assuming something that is wrong ;-)

Is not "+0200" the offset from the UTC standard time zone (or whatever 
it is called)? Is there 87 such values?

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

[Juanma Barranquero]

On Thu, Aug 7, 2008 at 23:04, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> Is not "+0200" the offset from the UTC standard time zone (or whatever it is
> called)? Is there 87 such values?

Who's talking about offsets from UTC? We were talking about
Microsoft's "time zones", i.e., entries in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones. These contain additional info.

   Juanma

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

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Thu, Aug 7, 2008 at 23:04, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>> Is not "+0200" the offset from the UTC standard time zone (or whatever it is
>> called)? Is there 87 such values?
> 
> Who's talking about offsets from UTC? We were talking about
> Microsoft's "time zones", i.e., entries in
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
> Zones. These contain additional info.

Yes, that is what I am asking about. As martin (and someone more) said 
it could be DST.

To make it clear what I am asking for: Isn't there an official list that 
we could map to, using those variables that are needed?

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

[Eli Zaretskii]

> Date: Thu, 07 Aug 2008 23:31:31 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: 641@emacsbugs.donarmstrong.com, Eli Zaretskii <eliz@gnu.org>, 
>  tzz@lifelogs.com, bug-gnu-emacs@gnu.org
> 
> To make it clear what I am asking for: Isn't there an official list that 
> we could map to, using those variables that are needed?

We need a list that shows the time zone names in all languages each
time zone can be translated to by Windows due to locale definitions.
If someone knows where to find such a list, please tell.

I'm not aware of such a list, FWIW.

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

[Ted Zlatanov]

On Fri, 08 Aug 2008 10:10:10 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

>> Date: Thu, 07 Aug 2008 23:31:31 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: 641@emacsbugs.donarmstrong.com, Eli Zaretskii <eliz@gnu.org>, 
>> tzz@lifelogs.com, bug-gnu-emacs@gnu.org
>> 
>> To make it clear what I am asking for: Isn't there an official list that 
>> we could map to, using those variables that are needed?

EZ> We need a list that shows the time zone names in all languages each
EZ> time zone can be translated to by Windows due to locale definitions.
EZ> If someone knows where to find such a list, please tell.

EZ> I'm not aware of such a list, FWIW.

Closest I could find is this chart:

http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html

We could at least provide this, and if the mapping fails we could print
a message that it's an unknown string, and the user can submit a bug.
%Z could show the full Windows-provided name, which IMHO is better than
nothing.

In addition, we can attempt to guess the right value based on the
localized string and offset, e.g. Hebrew is probably Israel's time
zone.  But this is a lot of work.

Ted

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

[Drew Adams]

> We could at least provide this, and if the mapping fails we 
> could print a message that it's an unknown string, and the
> user can submit a bug. %Z could show the full Windows-provided
> name, which IMHO is better than nothing.

Yes, my point from the beginning is that the Windows name can be better than
nothing, depending on your needs.

It depends on what you want/need in any given context. I agree with Eli that we
also need to let users specify, when they need it, a name guaranteed to be
Posix-compliant, which would be "" if no other Posix name is appropriate.

IOW, we should give users _both_ possibilities unambiguously: Posix-only and
possibly-non-Posix, better-than-nothing, YMMV, human-readable name.

We can do that by introducing a new format key, in addition to %Z. Either %Z or
the new key can be for the better-than-nothing, human-readable name. %Z for this
has the advantage of backward compatibility. %Z for the Posix-compliant name has
the advantage that "Z" is itself a Posix convention.

I'm OK with either approach. The important thing is to give users the option of
specifying either name format, depending on their needs.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 8 Aug 2008 08:57:11 -0700
> Cc: 
> 
> IOW, we should give users _both_ possibilities unambiguously: Posix-only and
> possibly-non-Posix, better-than-nothing, YMMV, human-readable name.
> 
> We can do that by introducing a new format key, in addition to %Z.

I'm okay with having a new format, or with adding a function that
would return a time-zone name that is just a string, not the spec
codified by Posix.  (It could return strings like "Asia/Riyadh" on
Posix platforms.)

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

[Drew Adams]

> > IOW, we should give users _both_ possibilities 
> > unambiguously: Posix-only and possibly-non-Posix,
> > better-than-nothing, YMMV, human-readable name.
> > 
> > We can do that by introducing a new format key, in addition to %Z.
> 
> I'm okay with having a new format, or with adding a function that
> would return a time-zone name that is just a string, not the spec
> codified by Posix.  (It could return strings like "Asia/Riyadh" on
> Posix platforms.)

Great. Thanks. Either solution is fine by me.

Probably a new format is better for users (keep everything in one place), if
there are no other considerations.

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

[ＯＦＦＩＣＥ ZERO]

配信不要
----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: <tzz@lifelogs.com>; <bug-gnu-emacs@gnu.org>
Sent: Saturday, August 09, 2008 2:27 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


>> > IOW, we should give users _both_ possibilities
>> > unambiguously: Posix-only and possibly-non-Posix,
>> > better-than-nothing, YMMV, human-readable name.
>> >
>> > We can do that by introducing a new format key, in addition to %Z.
>>
>> I'm okay with having a new format, or with adding a function that
>> would return a time-zone name that is just a string, not the spec
>> codified by Posix.  (It could return strings like "Asia/Riyadh" on
>> Posix platforms.)
>
> Great. Thanks. Either solution is fine by me.
>
> Probably a new format is better for users (keep everything in one place), 
> if
> there are no other considerations.
>
>
>
>
>
> 

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

[ＯＦＦＩＣＥ ZERO]

Do'nt   send  me mail  !!!
no tkank you!!

----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: <tzz@lifelogs.com>; <bug-gnu-emacs@gnu.org>
Sent: Saturday, August 09, 2008 2:27 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


>> > IOW, we should give users _both_ possibilities
>> > unambiguously: Posix-only and possibly-non-Posix,
>> > better-than-nothing, YMMV, human-readable name.
>> >
>> > We can do that by introducing a new format key, in addition to %Z.
>>
>> I'm okay with having a new format, or with adding a function that
>> would return a time-zone name that is just a string, not the spec
>> codified by Posix.  (It could return strings like "Asia/Riyadh" on
>> Posix platforms.)
>
> Great. Thanks. Either solution is fine by me.
>
> Probably a new format is better for users (keep everything in one place), 
> if
> there are no other considerations.
>
>
>
>
>
> 

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

[Stefan Monnier]

>> IOW, we should give users _both_ possibilities unambiguously: Posix-only and
>> possibly-non-Posix, better-than-nothing, YMMV, human-readable name.
>> 
>> We can do that by introducing a new format key, in addition to %Z.

> I'm okay with having a new format, or with adding a function that
> would return a time-zone name that is just a string, not the spec
> codified by Posix.  (It could return strings like "Asia/Riyadh" on
> Posix platforms.)

I could live with it, tho its usefulness is far from obvious.
In any case it would not be for Emacs-23 and I'd recommend potential
hackers to work on something else as that's more likely to be useful.


        Stefan

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

[ＯＦＦＩＣＥ ZERO]

配信不要



----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: <tzz@lifelogs.com>; <bug-gnu-emacs@gnu.org>
Sent: Saturday, August 09, 2008 2:22 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


>> From: "Drew Adams" <drew.adams@oracle.com>
>> Date: Fri, 8 Aug 2008 08:57:11 -0700
>> Cc:
>>
>> IOW, we should give users _both_ possibilities unambiguously: Posix-only 
>> and
>> possibly-non-Posix, better-than-nothing, YMMV, human-readable name.
>>
>> We can do that by introducing a new format key, in addition to %Z.
>
> I'm okay with having a new format, or with adding a function that
> would return a time-zone name that is just a string, not the spec
> codified by Posix.  (It could return strings like "Asia/Riyadh" on
> Posix platforms.)
>
>
>
>
> 

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> We can do that by introducing a new format key, in addition to %Z.

Like %EZ.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[ＯＦＦＩＣＥ ZERO]

配信不要
----- Original Message ----- 
From: "Andreas Schwab" <schwab@suse.de>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: "'Ted Zlatanov'" <tzz@lifelogs.com>; <bug-gnu-emacs@gnu.org>; 
<641@emacsbugs.donarmstrong.com>
Sent: Saturday, August 09, 2008 3:47 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


"Drew Adams" <drew.adams@oracle.com> writes:

> We can do that by introducing a new format key, in addition to %Z.

Like %EZ.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[ＯＦＦＩＣＥ ZERO]

Do'nt   send  me mail  !!!
no tkank you!!

----- Original Message ----- 
From: "Andreas Schwab" <schwab@suse.de>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: "'Ted Zlatanov'" <tzz@lifelogs.com>; <bug-gnu-emacs@gnu.org>; 
<641@emacsbugs.donarmstrong.com>
Sent: Saturday, August 09, 2008 3:47 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


"Drew Adams" <drew.adams@oracle.com> writes:

> We can do that by introducing a new format key, in addition to %Z.

Like %EZ.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[ＯＦＦＩＣＥ ZERO]

配信不要
----- Original Message ----- 
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Ted Zlatanov'" <tzz@lifelogs.com>; <bug-gnu-emacs@gnu.org>
Sent: Saturday, August 09, 2008 12:57 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


>> We could at least provide this, and if the mapping fails we
>> could print a message that it's an unknown string, and the
>> user can submit a bug. %Z could show the full Windows-provided
>> name, which IMHO is better than nothing.
>
> Yes, my point from the beginning is that the Windows name can be better 
> than
> nothing, depending on your needs.
>
> It depends on what you want/need in any given context. I agree with Eli 
> that we
> also need to let users specify, when they need it, a name guaranteed to be
> Posix-compliant, which would be "" if no other Posix name is appropriate.
>
> IOW, we should give users _both_ possibilities unambiguously: Posix-only 
> and
> possibly-non-Posix, better-than-nothing, YMMV, human-readable name.
>
> We can do that by introducing a new format key, in addition to %Z. Either 
> %Z or
> the new key can be for the better-than-nothing, human-readable name. %Z 
> for this
> has the advantage of backward compatibility. %Z for the Posix-compliant 
> name has
> the advantage that "Z" is itself a Posix convention.
>
> I'm OK with either approach. The important thing is to give users the 
> option of
> specifying either name format, depending on their needs.
>
>
>
>
>
> 

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

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Fri, 08 Aug 2008 10:04:24 -0500
> 
> Closest I could find is this chart:
> 
> http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html

Thanks.  I knew about it, it's on my disk for quite some time.

> We could at least provide this, and if the mapping fails we could print
> a message that it's an unknown string, and the user can submit a bug.
> %Z could show the full Windows-provided name, which IMHO is better than
> nothing.

Sorry, but I object to partial solutions like this, since I don't
think providing just English names will satisfy most users.

Perhaps someone could search the Windows files and find the
translations; they must be somewhere inside the Windows installation,
since the name of the time zone changes as soon as you modify a
certain option in the regional settings.

> In addition, we can attempt to guess the right value based on the
> localized string and offset, e.g. Hebrew is probably Israel's time
> zone.

Hebrew is an easy case, because the characters tell you unequivocally
what is the locale.  Latin letters, for example, are much harder.

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

[ＯＦＦＩＣＥ ZERO]

Do'nt   send  me mail  !!!
no tkank you!!

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>
To: "Ted Zlatanov" <tzz@lifelogs.com>
Cc: <bug-gnu-emacs@gnu.org>
Sent: Saturday, August 09, 2008 2:16 AM
Subject: bug#641: format-time-string %Z does not work,starting with Emacs 
22.2


>> From: Ted Zlatanov <tzz@lifelogs.com>
>> Date: Fri, 08 Aug 2008 10:04:24 -0500
>>
>> Closest I could find is this chart:
>>
>> http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html
>
> Thanks.  I knew about it, it's on my disk for quite some time.
>
>> We could at least provide this, and if the mapping fails we could print
>> a message that it's an unknown string, and the user can submit a bug.
>> %Z could show the full Windows-provided name, which IMHO is better than
>> nothing.
>
> Sorry, but I object to partial solutions like this, since I don't
> think providing just English names will satisfy most users.
>
> Perhaps someone could search the Windows files and find the
> translations; they must be somewhere inside the Windows installation,
> since the name of the time zone changes as soon as you modify a
> certain option in the regional settings.
>
>> In addition, we can attempt to guess the right value based on the
>> localized string and offset, e.g. Hebrew is probably Israel's time
>> zone.
>
> Hebrew is an easy case, because the characters tell you unequivocally
> what is the locale.  Latin letters, for example, are much harder.
>
>
>
>
> 

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

[Eli Zaretskii]

> Date: Thu, 07 Aug 2008 23:04:12 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: 641@emacsbugs.donarmstrong.com, Eli Zaretskii <eliz@gnu.org>, 
>  tzz@lifelogs.com, bug-gnu-emacs@gnu.org
> 
> > You're assuming too much. Countries in the same apparent time zone do
> > not have to follow the same DST rules, for example.
> 
> Yes, I surely am assuming something that is wrong ;-)
> 
> Is not "+0200" the offset from the UTC standard time zone (or whatever 
> it is called)?

Yes, it is, but what string would you translate +0200 to?  There are
numerous time-zone names that map to the same offset at any given
time.  It is impossible to use just one random time-zone name for this
translation, because tomorrow some of them will switch to +0300, while
others will not.

In other words, if the offset is all you care about, you could simply
use %z, and be done with it.  This isn't the problem we are
discussing.

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

[Drew Adams]

> > I would expect there to be just a little bit more than 24 
> > possible different return values from "%z". It would be 24
> > if all zones where whole hours different from UTC (or what
> > it is called now). But since some zones uses
> > half hours it could be more.
> >
> > However 87 is a surprisingly high figure for me.
> 
> You're assuming too much. Countries in the same apparent time zone do
> not have to follow the same DST rules, for example.

Not just different DST rules, and not just language differences. Different
countries with regions in the same UTC offset can have different names for the
same zone: Cuba Summer Time and Chile Time are both UTC -04, for example. 

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

[martin rudalics]

 >>How many time zones are there?
 >
 > I see 87 on my machine.

Hmmm ... I suppose these include DSTs.  Anyway, wouldn't we have to
multiply this with the number of languages supported?

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

[Eli Zaretskii]

> Date: Thu, 07 Aug 2008 23:20:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>, 
>  tzz@lifelogs.com,  bug-gnu-emacs@gnu.org
> 
>  >>How many time zones are there?
>  >
>  > I see 87 on my machine.
> 
> Hmmm ... I suppose these include DSTs.

No, they are just _names_.  Under each name there are rules for
switching between standard and daylight-saving time, and also the
specific strings to use as the time-zone name during standard and
daylight-saving periods.

> Anyway, wouldn't we have to multiply this with the number of
> languages supported?

Each name should be multiplied by the number of spellings in different
languages supported by the corresponding locale.  I don't know what is
the multiplication factor, but it's probably at least 2.  And that's
in addition to the 2 values for standard and daylight-saving periods.

However, the sheer number of the possible names is not the issue now.
It's the fact that we simply do not know all the possible spellings
that makes this idea impossible to implement at this time.

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

[Drew Adams]

emacs -Q
M-: (format-time-string "%Z) ==> ""
M-: (format-time-string "%z) ==> "-0700"
 
The %Z string is incorrect. In my case, it should be (as it is in
Emacs 20 and Emacs 22.1): "Pacific Daylight Time".
 
This same bug appears in Emacs 23.  This is a regression from Emacs
22.1.
 

In GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600)
 of 2008-03-26 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t
 
Major mode: Help
 
Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  view-mode: t