[ 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