You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sebb (Commented) (JIRA)" <ji...@apache.org> on 2012/04/13 01:19:17 UTC
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale instead of US (or trying both default locale and Locale.English)
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252960#comment-13252960 ]
Sebb commented on LANG-799:
---------------------------
There seems no reason to treat Locale.ENGLISH specially here.
I think option D is the best.
i.e. leave the current behaviour as is (and make sure it's documented), but allow the Locale to be provided.
> DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
> --------------------------------------------------------------------------------------------------------
>
> 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
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira