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

From: Jason Rumney <jasonr@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Bug in format-time-string in emacs 21.1?
Date: 13 Mar 2002 19:49:35 +0000	[thread overview]
Message-ID: <m3eliop7sg.fsf@nyaumo.btinternet.com> (raw)
In-Reply-To: <200203122337.g2CNax910197@shade.twinsun.com>

Paul Eggert <eggert@twinsun.com> writes:

> > 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.

I didn't test all the %O and %E permutations, as the documentation
was vague about which format specifiers they are supposed to work
with. It turns out that they do not work on Windows either, though the
symptoms are different; %h returns "", while %OY returns "%OY".

> > 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.

%C, %G, %g, %V are not supported by the underlying library function
either, but they work. That is why I concluded that some effort has
already been made to accommodate systems that do not support those
format specifiers.

> For example, for the %OY format the system merely invokes the
> underlying strftime; if the underlying strftime mishandles %OY then
> there is no workaround.

Perhaps %OY would be better approximated by %Y on systems that do not
support it.  At least the information gets to the user, even if it is
in a different format.

  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,

I don't propose making this Microsoft-specific. There are likely to
be other systems that do not support %h %O and %E, in which case the
same conditional code should be used.

> and I doubt whether either belongs in the GNU C Library source code
> (which is where strftime.c lives).

Really?  Why does the GNU C Library have all that complicated
conditional code to handle the case where it is not the GNU C
Library.  Surely this code would be better separated into the GNU C
Library version (without that code) and the Emacs version (without
the special code for the GNU C Library). Most of the conditional code
could then disappear.

-- 
Jason Rumney

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel