On Thu, Oct 29, 2009 at 7:27 AM, Christopher Schultz <[email protected]> wrote: > All, > > On 10/28/2009 5:10 PM, Christopher Schultz wrote: >> public String toLocalizedPattern(String dateFormat, >> Locale targetLocale) >> { >> new SimpleDateFormat(formatPattern, > targetLocale).toLocalizedPattern(); >> } > > After looking at DateTool, I'm thinking that I should probably write > this method as: > > public String toLocalizedPattern(String dateFormat, > Locale targetLocale) > { > DateFormat df = getDateFormat(dateFormat, > targetLocale, > getTimeZone()); > > return df.toLocalizedPattern(); > }
I believe you'll have to cast to (SimpleDateFormat) to get the toLocalizedPattern() method. In practice, such a cast should always work, but i don't trust that. So, perhaps cast, but try/catch any ClassCastException and return null (or attempt your original plan in such cases. > Using the getDateFormat will allow date formats such as "short" and > "short_date" and stuff like that, and will be more consistent with the > rest of the DateTool API. > > Any comments? > > Also, I noticed that some methods explicitly use this.getTimeZone() and > others reference the private member directly. that's probably an error that should be fixed. i can't think of why any methods but the setters and getters should use the member. > Technically, DateUtil does > have a subclass (ComparisonDateTool) so it should always use getTimeZone > in case the subclass wishes to override it. On the other hand, this > class is not /really/ meant for subclassing and so direct member access > seems reasonable. no. it's meant to be subclassable. > Any comments on this while I'm mucking-around in > DateTool? (Of course, any changes to other parts of the code will be > made in a different commit). thanks. :) > > Thanks, > -chris > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
