Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 23 Sep 2012 00:59:07 +1100 (NCT)
From: "Duncan Jones (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <735894577.111778.1348322347721.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <172244178.19501.1334267243017.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (LANG-799) DateUtils#parseDate uses default
 locale; add Locale support
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461160#comment-13461160 ] 

Duncan Jones commented on LANG-799:
-----------------------------------

Also, we should now remove {{testParseBadLocale()}} as we are no longer checking the Locale upon entry to the method.
                
> DateUtils#parseDate uses default locale; add Locale support
> -----------------------------------------------------------
>
>                 Key: LANG-799
>                 URL: https://issues.apache.org/jira/browse/LANG-799
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>    Affects Versions: 3.1
>            Reporter: Oliver Kopp
>            Priority: Minor
>              Labels: features
>             Fix For: 3.2
>
>         Attachments: commons-lang3-LANG-799.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
> Following line throws an ParseException on a German system:
> d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", new String[] {"EEE, dd MMM yyyy HH:mm:ss zzz"});
> Reason: parseDate internally calls SimpleDateFormat without providing a locale. This causes "MMM" to be interpreted using the system locale. If the system is German, the date is trying to be interpreted as German date.
> I see following solutions:
>  A) Always instantiate SimpleDateFormat with Locale.ENGLISH
>  B) Make two instances of SimpleDateFormat. One without providing a locale and one with Locale.ENGLISH. Try two parsings
>  C) Make as many SimpleDateFormat instances as locales are availble iterate over all instances at the parsing attempts.
>  D) provide an additional (optional) parameter to parseDate for providing a Locale
> I would prefer B) as this seems the best trade-off between internationalization and local usage.
> What do you think?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira