Back story:
There are several log4cxx bugs related to date and time formatting. The log4cxx implementation copied the log4j code and implemented a TimeZone class to emulate java.util.TimeZone. However, the implementation of TimeZone intentionally changed the TZ environment variable (and didn't always change it back) which has the serious side-effect of changing the default timezone for the calling application. I've been researching the log4j code over the last few days trying to figure out the behavior that is actually offered by log4j to find out what really needs to be implemented by log4cxx. I've only researched org.apache.log4j.helpers.AbsoluteTimeDateFormat, so they same conclusions may or may not apply to the other DateFormat implementations.
Now to the possible POLL related issue:
AbsoluteTimeDateFormat (ATDF) offers public constructors including one that takes a TimeZone as a parameter. The TimeZone parameter suggests that you could configure log4j so that independent appenders could format dates in different time zone. For example, I could have one appender representing times in America/Chicago and another in UTC.
However, there would be a problem doing this since ATDF uses static variables to cache the previously requested time and the resulting format but does not discriminate on the TimeZone of the ATDF. If you create an ATDF for one timezone and an ATDF for another and request each to format the same time, both formatters will return the same string. The second ATDF will use the cached values from the first request.
I've toyed with ways of trying to improve the caching. The most appealing approach is to change the static variables to instance variables and restrict the construction of ATDF so that there is only one instance of ATDF per timezone. This would involve demoting the public constructors and using factory methods to obtain instances of ATDF. If this was to be done, then it might be nice to mark the ATDF (and likely similar) constructors as deprecated and introducing private constructors with slightly different signatures.
And now for a plea for reassurance:
From a not yet complete review of log4j, it appears that formatting dates and times for a timezone other than the current machine default timezone is not easy and rarely used. I'm also guessing that if you use a locale sensitive formatter, then the current machine default locale is used and specifying an arbitrary locale is difficult and would be extremely rare.
It would make log4cxx a lot simpler if all I have to worry about is the current default machine timezone and UTC and don't have to try to parse /usr/share/zoneinfo or other platform specific approaches. to support arbitrary timezones.
And now for some possible new features:
I don't think it is a useful feature to allow users to configure arbitrary time zones for formatting, but it might be useful to make it easy to choose between the current machine timezone and UTC. This could be accomplished by recognizing "%d{ABSOLUTE-Z}" or "%d{ISO8601-Z}" as a request for use of UTC in formatting including a trailing Z.
The use of a comma [,] to separate seconds from milliseconds is a little surprising for those of us raised to use a period [.] as our decimal separator. I don't see how this could be changed to follow the locale without breaking something, but it might be nice to make it a parameter on the factory methods.
I've written up some log4j test cases to support my efforts. I had thought that just adding the files into the tests/src/java hierarchy might do the trick, but apparently not. Also, the org.apache.log4j.rolling.SizeBasedRollingTest was failing when I tried to run the self-tests.
I'd be willing to work up a patch that addresses these issues with the test cases that I've written in order to support the log4cxx effort.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
