Re: [tools] Adding localization method to DateTool

[Christopher Schultz]

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();
   }

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. 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. 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,
-chris

signature.asc
Description: OpenPGP digital signature