[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461157#comment-13461157
]
Duncan Jones commented on LANG-799:
-----------------------------------
That last commit now breaks the build, as my test
{{testParseNonSystemLocale()}} assumed the localized pattern change and now
fails.
I suggest you add a couple of tests, based on your new tests. E.g. you have:
{code}
// Parse German date with English Locale
@Test(expected=ParseException.class)
public void testLANG799_EN_FAIL() throws ParseException {
Locale dflt = Locale.getDefault();
Locale.setDefault(Locale.ENGLISH);
try {
DateUtils.parseDate("Mi, 09 Apr 2008 23:55:38 GMT", "EEE, dd MMM
yyyy HH:mm:ss zzz");
} finally {
Locale.setDefault(dflt);
}
}
{code}
And so I would now add, for example:
{code}
// Parse German date with English Locale, specifying German Locale override
@Test
public void testLANG799_EN_WITH_DE_LOCALE() throws ParseException {
Locale dflt = Locale.getDefault();
Locale.setDefault(Locale.ENGLISH);
try {
DateUtils.parseDate("Mi, 09 Apr 2008 23:55:38 GMT", Locale.GERMAN,
"EEE, dd MMM yyyy HH:mm:ss zzz");
} finally {
Locale.setDefault(dflt);
}
}
{code}
You can ditch my test {{testParseNonSystemLocale}} and the associated
{{getLongDateFormatForLocale}}.
> 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
