logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Not fully researched DateFormat issue that might have an impact on current POLL
Date Sat, 30 Oct 2004 03:21:01 GMT
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.



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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message