Rainer,

On 12/29/14 10:23 AM, Rainer Jung wrote:
> Am 29.12.2014 um 16:05 schrieb Christopher Schultz:
>> Rainer,
>>
>> On 12/29/14 9:49 AM, rj...@apache.org wrote:
>>> Author: rjung
>>> Date: Mon Dec 29 14:49:41 2014
>>> New Revision: 1648352
>>>
>>> URL: http://svn.apache.org/r1648352
>>> Log:
>>> BZ 54177: Status: Use numeric time stamps instead of
>>> textual ones to avoid non-well-formed XML output.
>>>
>>> Textual timestamps are formatted according to locale
>>> settings and reencoding them to UTF-8 would be cumbersome.
>>>
>>> Modified:
>>>      tomcat/jk/trunk/native/common/jk_status.c
>>>      tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
>>>
>>> Modified: tomcat/jk/trunk/native/common/jk_status.c
>>> URL:
>>> http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_status.c?rev=1648352&r1=1648351&r2=1648352&view=diff
>>>
>>> ==============================================================================
>>>
>>> --- tomcat/jk/trunk/native/common/jk_status.c (original)
>>> +++ tomcat/jk/trunk/native/common/jk_status.c Mon Dec 29 14:49:41 2014
>>> @@ -204,10 +204,10 @@
>>>   #define JK_STATUS_WAIT_AFTER_UPDATE        "3"
>>>   #define JK_STATUS_REFRESH_DEF              "10"
>>>   #define JK_STATUS_ESC_CHARS                ("<>?\"")
>>> -#define JK_STATUS_TIME_FMT_HTML            "%a, %d %b %Y %X %Z"
>>> +#define JK_STATUS_TIME_FMT_HTML            "%Y-%m-%d %H:%M:%S %z"
>>>   #define JK_STATUS_TIME_FMT_TEXT            "%Y%m%d%H%M%S"
>>> -#define JK_STATUS_TIME_FMT_TZ              "%Z"
>>> -#define JK_STATUS_TIME_BUF_SZ              (80)
>>> +#define JK_STATUS_TIME_FMT_TZ              "%z"
>>> +#define JK_STATUS_TIME_BUF_SZ              (30)
>>
>> It's a shame there is no strftime format specifier that allows for using
>> the name of the time zone in e.g. "zoneinfo" format (e.g.
>> America/New_York). By giving only the timezone offset (%z), we lose a
>> bit of information about which time zone is actually being used.
> 
> I know, also the weekday is gone now.

I think we can live without the weekday. :)

> But starting to play the native "which charset did strftime return" and
> then "convert that charset to UTF-8" game without introducing new
> library dependencies is nothing I personally wanted to start.

Oh, I completely agree. Even looking for char values > 127 is dangerous
because you can't reliably determine their "real" value in order to
convert them to &-encoded HTML entities...

> IMHO the XML tools compatibility of the status worker output was
> important enough to drop the additional but potentially not-well-formed
> parts.

Agreed.

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.

-chris

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to