On Dec 20, 2004, at 8:33 AM, Ceki Gülcü wrote:
CachedDateFormat is pretty interesting. However, I suspect that it may not work properly in case the data format passed by the user causes the length of the returned data to change over time. For example, if the format is 'yyyy-MMMMM-dd HH:mm:ss' and the cache is initialized on 4th of July, it will work properly for the remainder of the month but start returning erroneous results on August. Do you concur with this analysis?
I'm pretty sure that this is your quote, not mine (though I haven't gone through the list to check. I think that the current implementation (in the last patch on the bug report) of CachedDateFormat safely handles length transitions, however it would be good to add unit tests to confirm this.
As for the locale support in PatternLayout, it is probably overkill. It makes the code harder to understand and to maintain. I'd wait for someone using a different numbering system to contact us before adding doing it on our own.
Add TimeZone and locale for PatternLayout, remove obs DateFormat http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=32064
This last one I need to review after the recent discussions on jakarta-commons. It may be more appropriate to specify locale on the appender instead of the layout.
There are a couple of issues bundled into this one bug report and it might be good to separate them and discuss and act on them individually. The issues as I see them are:
The existing AbsoluteTimeDateFormat, ISO8601DateFormat, and DateTimeDateFormat contained buggy caching code and had been effectively abandoned since PatternLayout no longer created these classes, but created java.text.SimpleDateFormat objects. The proposed resolution was to reimplement those classes as wrappers of SimpleDateFormat.
The flawed caching code in the unused DateFormat's, if properly implemented, could result in a noticable performance benefit. A new class, CachedDateFormat, was written that could wrap any DateFormat. If the class is introduced, then PatternLayout should be modified to wrap the DateFormat that it constructs with CachedDateFormat. If CachedDateFormat proved to be unreliable, then it would be trivial to remove by changing a line or so in PatternLayout.
CachedDateFormat attempted to support multiple digit sets. However, I couldn't find any stock Java locales that used a digit set other than 0-9 in its date formats. I had expected that the Thai locale would use Thai digits, but I was wrong.
Date formatting was affected by the current locale and timezone of the thread and there was no mechanism to configure a timezone or locale to be used. The existing patches added configurable timezones and locales to the pattern layout which would modify the behavior of the date formats. Based on some of the previous discussions on the Jakarta Commons Dev list, I'd like to evaluate whether Appender is a better place for the locale to be specified.
What I'd like to do is:
Commit simplifications to the DateFormat's and add CachedDateFormat but simplified to only recognized arabic digit sets.
Review configurable locales and timezones and come back to the list with a specific recommendation. My current take is that appender is probably a more appropriate place to specify locale. However, that should be considered in a bigger scope where locale affects both the layout and rendering non-string messages. TimeZone is likely still appropriate to configure on the layout.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
