From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#641: format-time-string %Z does not work, starting with Emacs 22.2 Date: Tue, 5 Aug 2008 22:40:46 -0700 Message-ID: <00a001c8f786$fa665d30$0200a8c0@us.oracle.com> References: <4897737C.90709@gmx.at> <001501c8f67e$7c63b300$0200a8c0@us.oracle.com> <008601c8f756$9bce0f00$0200a8c0@us.oracle.com> Reply-To: Drew Adams , 641@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1218002887 27090 80.91.229.12 (6 Aug 2008 06:08:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2008 06:08:07 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 06 08:08:54 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 1KQcCS-00084K-T5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 08:08:45 +0200 Original-Received: from localhost ([127.0.0.1]:41037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQcBX-0003k7-HM for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 02:07:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQcBK-0003bK-BB for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 02:07:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQcBJ-0003a0-9i for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 02:07:33 -0400 Original-Received: from [199.232.76.173] (port=58798 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQcBJ-0003Zs-4W for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 02:07:33 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:52357) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KQcBI-0003Nc-LW for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 02: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 m7667MG3029070; Tue, 5 Aug 2008 23:07:23 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m765o485022851; Tue, 5 Aug 2008 22:50:04 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs , don@donarmstrong.com Resent-Date: Wed, 06 Aug 2008 05:50: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.121800127621111 (code B ref -1); Wed, 06 Aug 2008 05:50:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 6 Aug 2008 05:41:16 +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 m765fBaR021105 for ; Tue, 5 Aug 2008 22:41:13 -0700 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQbln-0005YM-9u for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 01:41:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQblm-0005X1-Ay for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 01:41:10 -0400 Original-Received: from [199.232.76.173] (port=44718 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQbll-0005Wn-JS for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 01:41:09 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:49099) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KQble-0007Yj-FQ; Wed, 06 Aug 2008 01:41:02 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m765eso5015155; Wed, 6 Aug 2008 00:40:54 -0500 Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m75JAnGQ011571; Tue, 5 Aug 2008 23:40:54 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt354.oracle.com with ESMTP id 11260383391218001246; Tue, 05 Aug 2008 22:40:46 -0700 Original-Received: from dradamslap1 (/69.181.100.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 05 Aug 2008 22:40:46 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acj3dAtsThBM0bFnSSauJpN5RLQpkQACQwlg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Wed, 06 Aug 2008 02:07:33 -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:19063 Archived-At: > 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.