Michael, thanks for the feedback. > 1. The new PatternParser does not use the constructor of > AbsoluteTimeDateFormat and its subclasses which takes a TimeZone. > OTOH, DateFormat only has the zero-parameter constructor, so > maybe the > Log4J subclasses of DateFormat should also have only the > zero-parameter > constructor.
I don't have a strong opinion on this except that it would be better if the code did it the same way for all the date formats instead of having to know which special constructor to use for which class. > 2. When the Javadoc of PatternLayout is updated to describe > "@TZID", it > should also note that if the TimeZone ID specified cannot be > resolved by > TimeZone.getTimeZone(String) then the TimeZone will default to GMT. > This is the behavior of TimeZone.getTimeZone(String). I neglected to mention that in the first message. It was one of the first things I double checked when reviewing the submitted change. It would be noted in the javadoc for PatternLayout, if accepted. > 3. If the modifications which I previously submitted for > AbsoluteTimeDateFormat and its subclasses are accepted, then > do we want > to go even further and allow Locale and/or TimeZone specifications? > Perhaps we could use "@t<TZID>@c<cc>@l<ll>" where: > a. TZID is the TimeZone ID recognized by java.util.TimeZone > b. cc is the two character ISO3166 country code recognized by > java.util.Locale > c. ll is the two character ISO639 language code recognized by > java.util.Locale > d. @c may appear without @l > d. if included, the @l suboption must directly follow @c > e. @t and @c are independent > d. We won't support Locale variants. I am all for exposing this functionality via the configuration settings, and what you propose above seems straightforward enough. I would appreciate some feedback from other developers as to their opinion. This idea of having multiple parameters for a single conversion specifier seems new and different to what currently exists. How do folks think about it? Also, what is the status of your previously submitted modifications? Maybe we should apply all of these at the same time. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
