I was going to research this a bit more before raising the issue, but it might (or might not) have an impact on what would be in a 1.2.9.
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.
Sorry for not replying earlier. Not having looked into the ATDF code for about a million years, I can't really comment on the technical issues you raised with any semblance of accuracy. So I'll pass for the time being but will get back to you later. More below.
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.
That might be more of a log4j inadequacy rather than a feature to follow. Customer with machines spanning multiple timezones have asked for the ability to format time&date for a TZ different than that of the host. But as you said this is rather 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.
Makes sense to me. In any case, if a certain log4j feature is too hard to reproduce in another language, then punting on that specific feature sounds reasonable to me.
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.
Since java makes it rather easy do deal with multiple timezones, I'd go for something like
%d{ABSOLUTE, UTC}, "%d{ISO8601, UTC} or %d{ABSOLUTE, X} where X is any timezone string recognized by Java.
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.
If I remember correctly, the ISO-8601 standard recommends the use of ',' regardless of locale. Anyway, the separator string could be a third parameter, as in %d{ISO8601, UTC, '.'}.
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.
??? Why not? What went wrong?
Also, the org.apache.log4j.rolling.SizeBasedRollingTest was failing when I tried to run the self-tests.
Yeah, the SizeBasedRollingTest is known to be fragile. If you can, please send me the failure report, so I can fix the SizeBasedRollingTest.
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.
You've written test cases for log4j or log4cxx? In any case, thanks for the offer. If it does not takes too much of your time, please do submit your patch.
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
http://www.qos.ch/shop/products/eclm/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
