https://bz.apache.org/bugzilla/show_bug.cgi?id=58286
--- Comment #2 from Rainer Jung <rainer.j...@kippdata.de> --- %z (lower case) was first added (standardized) in "IEEE Std 1003.1, 2004 Edition" aka SUSv3 (after including issue 6). See http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html %Z (upper case) was what we used before. As I wrote, it was changed in order to fix BZ 54177. Concerning the importantce of the tz info, I dont fully agree. This is "just" jk-status output. So it would be nice to have but rating all the stuff that jk-status shows, IMHO the current tz is one of the least important things. Looking at the available APIs on Windows I tend to drop the tz info for that platform. BZ 54177 suggests we should stick to numeric representation (at least to XML safe stuff) and I invite you to look at the apr file "time/win32/time.c" how tm_gmtoff is calculated in apr_time_exp_lt(). That tm_gmtoff is what httpd uses to print the tz offset in its access log. At least for me that's not a road I'd like to go "only" for tz. Any other suggestions are welcome, but short term it seems best to remove and stay on the safe side. About the root cause of the crash: httpd+mod_jk should not crash due to buffer overrun and in a simple standalone test it does not and simply returns without formatting the time stamp. In the debugger, I can see that it crashes in strftime and only if "%z" is used and also not when "%z" is the only thing to format. In addition one can see, that the buffer would not be big enough to accommodate the full formatted timestamp. Why it crashes in the module and not in the standalone example is not known to me. I don't have PDB files for all components, so it is a bit hard to debug further. But the crash definitely happens in strftime() and is definitely related to "%z" in combination with other format chars in the pattern and a too small buffer. And we definitely don't want to %z on Windows because its output (long textual name of time zone) is not what we want. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
