AbsoluteTimeDateFormat, DateTimeDateFormat, and ISO8601DateFormat all ignore timezone in their cache logic and have problems with pre-1970 dates in case you ever set your clock back that far. The approach that I have taken is to create a CachedDateFormat that wraps an arbitrary DateFormat and have removed the flawed cache logic. It does not attempt to share the same cached value among multiple layouts, but it would be difficult to do safely and I'm guessing that extra optimization would not offer a noticiable performance gain.
CachedDateFormat sounds very good. I fully agree with your safety concerns as well as the insignificance of the performances gains resulting from sharing the cache between instances.
AbsoluteTimeDateFormat and its derivatives were developed because SimpleDateFormat was terribly slow. SimpleDateFormat insisted on parsing the date pattern each and every time it was asked to format a date. This problem has been solved in JDK 1.3, if I am not mistaken.
In the most recent version of the code, checked in just before the weekend, o.a.l.pattern.DatePatternConverter uses SimpleDateFormat and ignores AbsoluteTimeDateFormat and its derivatives.
Of course, the performance gains associated with the (at most) 1 millisecond cache were lost in this latest code. Since you report that using the cache results in a 30% gain in performance, it needs to be put back.
It is also very clear that restricting the cache to be a class-wide variable instance of an instance variable is a rather serious mistake/bug. It really puzzles me how this was not caught earlier.
I'll spend my afternoon studying your message+patches more closely. More later,
-- 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]
