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#9794: 24.0.90; `format-time-string' no good for %Z Date: Wed, 19 Oct 2011 07:28:51 -0700 Message-ID: References: <68A313A7DDAA4912A255DAFE495606F9@us.oracle.com><24FDB65B0E784E978085D30A7CBF9FAF@us.oracle.com><8362jlv0rq.fsf@gnu.org> <87fwipgltl.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1319034622 22838 80.91.229.12 (19 Oct 2011 14:30:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2011 14:30:22 +0000 (UTC) Cc: 9794@debbugs.gnu.org To: "'Jason Rumney'" , "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 19 16:30:16 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RGX9s-0005wA-CJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Oct 2011 16:30:16 +0200 Original-Received: from localhost ([::1]:46621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGX9r-0001ml-G0 for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Oct 2011 10:30:15 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51571) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGX9k-0001ij-0q for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2011 10:30:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGX9b-00073X-L4 for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2011 10:30:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGX9b-00073T-ID for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2011 10:29:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RGXAc-0002vG-7w for bug-gnu-emacs@gnu.org; Wed, 19 Oct 2011 10:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Oct 2011 14:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9794 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: Original-Received: via spool by 9794-submit@debbugs.gnu.org id=B9794.131903460611153 (code B ref 9794); Wed, 19 Oct 2011 14:31:02 +0000 Original-Received: (at 9794) by debbugs.gnu.org; 19 Oct 2011 14:30:06 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGX9h-0002tq-NU for submit@debbugs.gnu.org; Wed, 19 Oct 2011 10:30:05 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGX9f-0002sb-2M for 9794@debbugs.gnu.org; Wed, 19 Oct 2011 10:30:04 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9JESq8h008908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Oct 2011 14:28:53 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9JESpmx017643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 14:28:52 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9JESk1v032205; Wed, 19 Oct 2011 09:28:46 -0500 Original-Received: from dradamslap1 (/10.159.53.26) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 19 Oct 2011 07:28:46 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <87fwipgltl.fsf@gnu.org> Thread-Index: AcyOYdyLwZ4W7J1XTs6wg8C5sPXCiwAB7oEw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E9EDEA6.003F:SCFMA922111,ss=1,re=-4.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 19 Oct 2011 10:31:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:52853 Archived-At: > >> And just because a non-Windows developer thinks that letting them > >> see "(Pacific Daylight Time)" is not useful to them and "()" is > >> more meaningful. Sheesh. > > > > No, it's because a _Windows_ developer found out that the Windows > > time-zone names violate international standards for what %Z should > > produce, which breaks other Emacs features that use the results. > > The international standards alone aren't a problem - GNU software in > general does not follow standards slavishly. The real problem is that > for many uses of time format strings (which correctly check > for an empty %Z string and use %z as a backup), in mail, news, HTTP > headers, XML documents and similar uses which rely on the strings > being standards compliant, the non-compliant long forms returned by > Windows tzname() cause real problems which are much more severe than > the inconveniences that this change has caused. > > One proposal in that thread was to introduce a new format specifier to > print the long names (on non-Windows platforms it could output the > commonly used "Continent/City" format). Another proposal was that %EZ > could be used, which is especially fitting, for the Windows timezone > names, which are apparently locale sensitive (which was one of the > reported problems that led to them being removed in the first place). Yes - that should be a no-brainer. The only question should be about the details: what format specifiers with what behavior. I suggest format specifiers that let you alternatively do all of the following for the case of time zone names (i.e. "pretty" names, not just %z numbers). 1. Use only POSIX-compliant time-zone pretty names, which can mean "" (empty - no available POSIX name). 2. Use any available nonempty time-zone pretty names, with priority to nonempty POSIX-compliant pretty names. 3. Same as #2, but with priority to system-supplied names, even when a corresponding nonempty POSIX name is available. 4. Use only nonempty POSIX-compliant pretty names, when available, and fall back to what %z does in cases where the POSIX name is empty. #2 and #3 would also fall back to %z when no nonempty name is available. Again, such details should be open for discussion, but it should be clear that _some_ fix should be found so that programmers are able to provide "pretty" time zone info to users whenever such info is available, whether that info is POSIX or not. Forcing the loss of useful time-zone info just because a user-understandable time-zone description is not understandable to POSIX puts POSIX on top and people at the bottom. Users and Emacs programmers deserve better than that.