From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#641: format-time-string %Z does not work, starting with Emacs 22.2 Date: Wed, 06 Aug 2008 21:53:58 +0300 Message-ID: References: <4897737C.90709@gmx.at> <001501c8f67e$7c63b300$0200a8c0@us.oracle.com> <008601c8f756$9bce0f00$0200a8c0@us.oracle.com> <00a001c8f786$fa665d30$0200a8c0@us.oracle.com> Reply-To: Eli Zaretskii , 641@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1218049683 22095 80.91.229.12 (6 Aug 2008 19:08:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2008 19:08:03 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 06 21:08:52 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 1KQoND-0003Yh-It for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 21:08:39 +0200 Original-Received: from localhost ([127.0.0.1]:37236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQoMI-0003Wh-7F for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 15:07:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQoMD-0003V5-CX for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:07:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQoM9-0003Ng-Nj for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:07:36 -0400 Original-Received: from [199.232.76.173] (port=52793 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQoM9-0003NT-Gk for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:07:33 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:60119) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KQoM8-0000lV-RS for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:07:33 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m76J7NlY005215; Wed, 6 Aug 2008 12:07:23 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m76J03cd001757; Wed, 6 Aug 2008 12:00:03 -0700 X-Loop: don@donarmstrong.com Resent-From: Eli Zaretskii Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs , don@donarmstrong.com Resent-Date: Wed, 06 Aug 2008 19:00:03 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 641 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.121804886132658 (code B ref -1); Wed, 06 Aug 2008 19:00:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 6 Aug 2008 18:54:21 +0000 Original-Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m76IsHV6032652 for ; Wed, 6 Aug 2008 11:54:18 -0700 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQo9I-0001kT-VD for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 14:54:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQo9G-0001gF-Ue for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 14:54:16 -0400 Original-Received: from [199.232.76.173] (port=33527 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQo9G-0001g0-PF for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 14:54:14 -0400 Original-Received: from mtaout7.012.net.il ([84.95.2.19]:60211) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KQo9G-0006lg-5p for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 14:54:14 -0400 Original-Received: from HOME-C4E4A596F7 ([77.126.7.152]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K570003Q0ID9Y10@i-mtaout7.012.net.il> for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 21:54:14 +0300 (IDT) In-reply-to: <00a001c8f786$fa665d30$0200a8c0@us.oracle.com> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 10 (1203?) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Wed, 06 Aug 2008 15:07:36 -0400 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:19070 Archived-At: > From: "Drew Adams" > Cc: , > 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.