From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.bugs Subject: Re: bug#641: format-time-string %Z does not work, starting with Emacs 22.2 Date: Wed, 06 Aug 2008 14:53:12 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <86skthj4yf.fsf@lifelogs.com> References: <4897737C.90709@gmx.at> <001501c8f67e$7c63b300$0200a8c0@us.oracle.com> <008601c8f756$9bce0f00$0200a8c0@us.oracle.com> <00a001c8f786$fa665d30$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1218055222 9233 80.91.229.12 (6 Aug 2008 20:40:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2008 20:40:22 +0000 (UTC) To: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 06 22:41:12 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KQpol-0001g3-4u for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 22:41:11 +0200 Original-Received: from localhost ([127.0.0.1]:56219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQpnp-0007Ax-7o for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 16:40:13 -0400 Original-Path: news.stanford.edu!headwall.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!xs4all!news2.euro.net!newsfeed.freenet.de!news.albasani.net!not-for-mail Original-Newsgroups: gnu.emacs.bug Original-Lines: 28 Original-X-Trace: news.albasani.net tDsB8orZRvF3fbQYq4B9kmWsAdtxut2DDSzfMPLomGsG1gwMlAmuTdjE65hYKRnMghrwUEYmWnUsMj3omSZdYc97BwoyCktDlvfzo70VF6CUdOTTzF5PgNav1adeCfDG Original-X-Complaints-To: abuse@albasani.net Original-NNTP-Posting-Date: Wed, 6 Aug 2008 19:48:24 +0000 (UTC) X-User-ID: I2gWd2ty9sm6Gpf1Hev5MK+ud9CuGCNYgiPoTHOWaf0= X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Cancel-Lock: sha1:UmxXTmjdSkwiV0NHGjGmEJQ39Xk= sha1:Akjp6yqlicUT0QTf0qBbS19/Bdw= User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux) X-NNTP-Posting-Host: C18QjLtUALCuA1rbNbiEu+hP8hwFsZdUNhUF5LH7XTU= Original-Xref: news.stanford.edu gnu.emacs.bug:46114 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:19074 Archived-At: On Wed, 06 Aug 2008 21:53:58 +0300 Eli Zaretskii 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