From: Paul Eggert <eggert@twinsun.com>
Cc: emacs-devel@gnu.org
Subject: Re: Bug in format-time-string in emacs 21.1?
Date: Tue, 12 Mar 2002 15:37:00 -0800 (PST) [thread overview]
Message-ID: <200203122337.g2CNax910197@shade.twinsun.com> (raw)
In-Reply-To: <m3d6y9cs43.fsf@nyaumo.btinternet.com> (jasonr@gnu.org)
> From: Jason Rumney <jasonr@gnu.org>
> 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
next prev parent reply other threads:[~2002-03-12 23:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.SUN.3.91.1020312075746.24908F-100000@is>
[not found] ` <m3n0xep8u8.fsf@Janik.cz>
2002-03-12 21:35 ` Bug in format-time-string in emacs 21.1? Jason Rumney
2002-03-12 22:21 ` Paul Eggert
2002-03-12 22:56 ` Jason Rumney
2002-03-12 23:37 ` Paul Eggert [this message]
2002-03-13 19:49 ` Jason Rumney
2002-03-14 0:37 ` Paul Eggert
2002-03-13 10:59 ` Richard Stallman
2002-03-13 22:13 ` Jason Rumney
2002-03-14 0:13 ` Paul Eggert
2002-03-14 22:28 ` Jason Rumney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200203122337.g2CNax910197@shade.twinsun.com \
--to=eggert@twinsun.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.