Re: Patch for time problems

[Curt Arnold]

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.

On Nov 3, 2004, at 3:04 AM, Jeff Apple wrote:
The enclosed patch fixes multiple problems:
1) Restores the TZ environment variable. This was a critical bug for 
us.
2) Sets the TZ environment variable using a static array. In my putenv 
man page, there is an explicit warning against using a local variable 
to set environment variables. There are probably other instances where 
this is done incorrectly in log4cxx.
3) Correctly calculates daylight savings in the southern hemisphere. 
Down here we have DST in January, not June.