From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Bug in format-time-string in emacs 21.1? Date: Tue, 12 Mar 2002 15:37:00 -0800 (PST) Sender: emacs-devel-admin@gnu.org Message-ID: <200203122337.g2CNax910197@shade.twinsun.com> References: <200203122221.g2CMLEX10014@shade.twinsun.com> NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1015976363 3261 80.91.224.249 (12 Mar 2002 23:39:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 12 Mar 2002 23:39:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16kvrW-0000qU-00 for ; Wed, 13 Mar 2002 00:39:22 +0100 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16kvtu-0000P8-00 for ; Wed, 13 Mar 2002 00:41:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16kvrH-0000CL-00; Tue, 12 Mar 2002 18:39:07 -0500 Original-Received: from alcor.twinsun.com ([198.147.65.9]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16kvpF-00005B-00; Tue, 12 Mar 2002 18:37:01 -0500 Original-Received: from shade.twinsun.com ([192.54.239.27]) by alcor.twinsun.com (8.12.1/8.12.1) with ESMTP id g2CNb0PB010813; Tue, 12 Mar 2002 15:37:00 -0800 (PST) Original-Received: (eggert@localhost) by shade.twinsun.com (8.11.6+Sun/8.11.6) id g2CNax910197; Tue, 12 Mar 2002 15:37:00 -0800 (PST) Original-To: jasonr@gnu.org In-Reply-To: (jasonr@gnu.org) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:1896 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:1896 > From: Jason Rumney > Date: 12 Mar 2002 22:56:44 +0000 > > after experimenting with all the documented format specifiers, it > seems that "%h" is the only one that does not work with the current code Surely you not have tested this exhaustively. That would be quite a lot of testing. For example, you would need to test for proper support of the Modern Japanese Imperial calendar on various versions of Japanese Windows. (Not my idea of fun. :-) > some effort has obviously already been made to make the other > specifiers that are not supported by the system strftime function > work. I think you may be reading too much into the code here. Here is a typical bit of code: #if defined _NL_CURRENT || !HAVE_STRFTIME cpy (am_len, a_month); break; #else goto underlying_strftime; #endif So yes, there is a workaround if the system lacks strftime entirely (which is quite rare these days). But that workaround assumes the C locale, and such a workaround is not reasonable for localized hosts. If the system has a strftime, the code invokes the system strftime for locale-specific formats (except for the special case of the GNU C library, where it uses a faster backdoor _NL_CURRENT). For example, for the %OY format the system merely invokes the underlying strftime; if the underlying strftime mishandles %OY then there is no workaround. So in this respect, %h is similar to %OY, %Ea, and lots of other formats. > In the case of "%h", it is documented as doing the same as "%b", so > we can fix that easily. But that will introduce either minor runtime overhead, or hard-to-maintain Microsoft-version-specific ifdefs, and I doubt whether either belongs in the GNU C Library source code (which is where strftime.c lives). A simpler fix would be for Emacs to stop documenting %h, as it is redundant. Or we can simply note the issue in PROBLEMS. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel