Hi Chris,
Am 29.12.2014 um 16:45 schrieb Christopher Schultz:
There is the option of passing-in a static locale_t that ignores the
value of LANG and friends. That might get you a more consistent string
value if you used en_US for instance, which rarely has non-ASCII values
for anything:
#include <time.h>
#include <xlocale.h>
size_t
strftime_l(char *restrict s, size_t maxsize, const char *restrict
format,
const struct tm *restrict timeptr, locale_t loc);
I'm not sure about the availability of "xlocale". For instance, the
above reference came from "man strftime" on my Mac, but there is no
mention of it on my Linux development server's man page (I thought Linux
supported *everything*!).
Oddly enough, though there is no man page for it, I can find a reference
for it in /usr/include/time.h:
# ifdef __USE_XOPEN2K8
/* Similar to the two functions above but take the information from
the provided locale and not the global locale. */
# include <xlocale.h>
extern size_t strftime_l (char *__restrict __s, size_t __maxsize,
__const char *__restrict __format,
__const struct tm *__restrict __tp,
__locale_t __loc) __THROW;
# endif
So it's there, just not documented. Not a great start.
Thanks for the pointer. strftime_l would be helpful. It is documented as
part of the Open Group Unix specification version 4, which is kind of
recent. Unfortunately it is not supported by versions of platforms which
are still in wide use (like Solaris 10, or somewaht older Linux
distros). So we could add code to "configure" to detect strftime_l
presence, and then choose the "nicer" human-friendly format in case we
have found the modern API.
I'll add some pointers to the Bugzilla 54177, but currently do not plan
to act on improving the code further than what I already did.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
