On Dec 26, 2004, at 1:52 PM, Ceki G�lc� wrote:
It looks like you are no longer taking advantage of the case where there is no millisecond field to print, in which case millisecond formatting and findMillisecondStart calculations can be skipped.
Definitely not the intention. CachedDateFormatTest.test13 checks that findMillisecondStart returns NO_MILLISECONDS for a date format.
Reviewing the code in CachedDateFormat.format looks like it should do the right thing when millisecondStart == NO_MILLISECONDS, but I haven't single stepped through it.
findMillisecondStart returns NO_MILLISECONDS but that knowledge does not seem to be used in the format() method.
I'll clarify the comments and will try to walk through the code in a debugger, but I think it does. (millisecondStart != UNRECOGNIZED_MILLISECONDS) would be true in this case, so it would enter the second conditional block, check if the time is close enough, skip over the millisecondFormat call and append the previous cached value.
As I wrote in a previous message, instead of invoking findMillisecondStart every second, we could use the knowledge of the pattern to avoid using CachedDateFormat for unsafe methods. Version 15 invokes findMillisecondStart about once a second which not consequential but also also quite unnecessary. I feel that version 15 constitutes a regression wrt to version 1.12. Nevertheless, in reverence for your hard work and initiative, I am happy to defer to your judgement.
findMillisecondStart is not called again after the first time it returns UNRECOGNIZED_MILLISECONDS. I guess you could avoid calling it again if it detected NO_MILLISECONDS. I think a format like "HH:mm:s,SSS" would require you to reevaluate the millisecond position every second. To reduce the evaluations much beyond what we have now, the complexity and potential caching errors goes up with little additional performance gain.
to setting the system time back.
I was not only thinking of the if (slotBegin > time) { slotBegin -= 1000; } check. There are other places that assume slotBegin to only take positive values. For example, set setTimeZone method. As mentioned previously, I am happy to defer to your judgement.
Setting slotBegin to zero in setTimeZone is not sufficient to invalidate the cache. I'm guess this is an artifact of our friendly "duel", but maybe I got it wrong initially. Changing the timezone may also change the location of the millisecond field, so findMillisecondPosition should be called. It should look very similar to the body of the constructor.
p.s. I don't believe RelativeDateFormat is used anywhere in the log4j code base and should likely join AbsoluteDateFormat and the others in the "attic".
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
