Nathan,
On 10/28/2009 6:32 PM, Nathan Bubna wrote:
> You've not been forgotten. :) You're correct that this is not
> currently supported. This only adds a simple method to a single
> tool's VTL API and thus would not impede any forthcoming long-wished
> for 2.0 release (at least in my book). Go for it.
>
> One question, would it make sense to also add a:
>
> public String toLocalizedPattern(String format) {
> return toLocalizedPattern(format, getLocale());
> }
>
> for completeness? Or is that redundant?After reading everyone's comments, I'm not really sure a second method is necessary. As Antonio mentions, the server Locale is next to useless, although tools.xml can be used to define the default locale for DateTool. For times when you know you want to use the server's Locale (or the DateTool's Locale), you can easily get that Locale object and pass it into the two-argument method. The bottom line is that neither technique (using a custom Locale nor the server/DateTool Locale) is possible at the moment, and adding a single method allows them both if desired. I'm happy to add a second method if there's a lot of support for it, especially because it's nearly as trivial as the first. Thanks, -chris
signature.asc
Description: OpenPGP digital signature
