Hi Mike,
How do you think the locale could influence the output of AbsoluteTimeDateFormat or DateTimeDateFormat ? Could you give an example of what you have in mind? Thanks, At 00:24 17.06.2002 -0400, you wrote: >You're right, the code is very straight-forward. Some items to consider: >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. >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). >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. > >-- >Cheers, >Mike McAngus >[EMAIL PROTECTED] -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
