Re: Bug in format-time-string in emacs 21.1?

[Paul Eggert]

> From: Jason Rumney <address@hidden>
> 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.