That all sounds good, especially since have no need for logging in
anything but local time and/or UTC. As long as the DST calculations are
good for the southern hemisphere we'll be happy!
Curt Arnold wrote:
I agree it is a critical bug (actually set of bugs). I've been
working on adding test cases to log4j to establish its current
behavior and fixing the bugs that I've found there before revamping
the log4cxx code. When finished, I believe that it will not be
necessary to ever change the value of the TZ since log4j effectively
only supports logging in local time. The class signatures in log4j
appear to support arbitrary timezones, however there does not appear
to be a way to specify an arbitrary timezone in the pattern layout and
there are bugs in the caching that would cause attempts to support
multiple timezones to fail. I'm hoping to add to log4j some mechanism
that you can specify that a particular field should be UTC.
Since log4j only currently effectively supports local time and will,
at most, support local time and UTC in 1.3, the log4cxx TimeZone class
can be simplified to only represent the current timezone and UTC and
just be used as a switch between local and UTC formatting methods.
I'll keep you posted on the progress and would appreciate your
feedback when I get those changes committed.
