Curt, Thanks for the quick response. In 0.9.8 will the loggers use the current system timezone by default? I am not trying to do anything special with outputting to different timezones, I just want to print the logs in the current timezone on the system. Currently the only way I can accomplish this is by setting the timezone explicitly in the property file. I am leery to move to 0.9.8 at this time because the product we are using log4cxx in is going GA in 5 weeks, and I don't think there will be a stable 0.9.8 by that time.
Don't put the timezone handling at the top of the priority list on my account, we will need to stick with 0.9.7 for the near future, I will survive by hacking the properties file from the application and letting ConfigureAndWatch refresh the settings. Thanks, Jim Timezone handling in 0.9.7 is seriously broken (see (http://issues.apache.org/jira/browse/LOGCXX-11) and should be avoided at all costs. The CVS HEAD is in transition on this. It currently supports TimeZone and Locale attributes on the pattern layout. However when the capability was added to log4j, it was decided that the timezone should be part of the pattern specification. There is currently an open bug in log4cxx (http://issues.apache.org/jira/browse/LOGCXX-49) to synchronize log4cxx with log4j and it is marked as a requirement for the 0.9.8 release. It hasn't been an urgent issue for anyone, but I can move that to the top of the queue. The current CVS HEAD supports the same format strings as log4j (and the old format strings for compatibility with 0.9.7) and should shortly accept the same TimeZone qualifiers. Basically, what you do is to add a second {} after the format specifier containing the timezone. If not specified it will use the current machine timezone. log4j will recognize all the timezones known to the JVM. log4cxx will only recognized {GMT}, {GMT+n:00} and {GMT-n:00}. Platform specific code or calls to ICU would be necessary to support timezones like {America/Chicago}. I'll try to get that task finished shortly.
