At this moment, I'm too tired to try to fully understand why it fails and how it could be fixed. More tomorrow.
The underlying code did not anticipate the use of only two 'SS' which I assume that milliseconds 0 to 99 are represented with two digits and 100-999 with three. I have attached another patch file to the Bug with the fix and the your test added to the unit test. Basically if it doesn't see "000" and "987", it will just delegate to the inner date format. Previously, it only checked for a "0" and "9". You could probably still mess up the caching by specifying a "SS0" format.
I'm fine with dropping CachedDateFormat. I wrote the original iteration before I realized that the buggy caching code was no longer used.
Specifying the Locale should probably be held off to be done in conjunction with the localizing layout that I had discussed on on the commons-dev mailing list.
Probably should address TimeZone in the near future. Specifying it on the layout is simpler and keeps the content between the curly braces consistent with JDK's SimpleDateFormat. However, it doesn't allow you to use multiple time zones in one log message.
How about:
' uses an optional {tz=} following %d to specify time zone
%d{tz=GMT}{yyyy-MM-dd HH:mm:ss,SSS} Z : %d{yyyy-MM-dd HH:mm:ss,SSS z} - %m
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
