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: Wed, 6 Aug 2008 12:48:14 -0700 Message-ID: <00ff01c8f7fd$5d92d6b0$0200a8c0@us.oracle.com> 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: 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 1218053282 2576 80.91.229.12 (6 Aug 2008 20:08:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2008 20:08:02 +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 22: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 1KQpJK-0005MP-TS for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 22:08:44 +0200 Original-Received: from localhost ([127.0.0.1]:35451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQpIP-0006zt-3p for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2008 16:07:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQpID-0006s8-B1 for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 16:07:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQpIC-0006r6-8x for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 16:07:32 -0400 Original-Received: from [199.232.76.173] (port=44706 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQpIC-0006qr-2d for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 16:07:32 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:56316) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KQpIB-0002Kp-Ef for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 16:07:32 -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 m76K7Nq8023341; Wed, 6 Aug 2008 13:07:23 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m76K037N019873; Wed, 6 Aug 2008 13:00:03 -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 20: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.121805236318244 (code B ref -1); Wed, 06 Aug 2008 20:00:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 6 Aug 2008 19:52:43 +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 m76Jqc2N018238 for ; Wed, 6 Aug 2008 12:52:39 -0700 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KQp3m-0004qZ-7u for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:52:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KQp3j-0004p9-J9 for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:52:37 -0400 Original-Received: from [199.232.76.173] (port=41193 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KQp3j-0004p1-8A for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2008 15:52:35 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]:29107) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KQp3b-0007hZ-Fq; Wed, 06 Aug 2008 15:52:29 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m76Jq4nj016134; Wed, 6 Aug 2008 13:52:04 -0600 Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m76FO603006140; Wed, 6 Aug 2008 13:52:03 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt358.oracle.com with ESMTP id 11278758851218052086; Wed, 06 Aug 2008 14:48:06 -0500 Original-Received: from dradamslap1 (/69.181.100.12) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 06 Aug 2008 12:48:06 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acj39fnLR1UZz1fyQ2GIVQrz07cb0gAAMxNg 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 16:07:32 -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:19073 Archived-At: > > 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.