You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Oliver Kopp (Created) (JIRA)" <ji...@apache.org> on 2012/04/12 23:47:22 UTC
[jira] [Created] (LANG-799) DateUtils#parseDate uses default locale
instead of US (or trying both default locale and Locale.English)
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
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
[jira] [Resolved] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb resolved LANG-799.
-----------------------
Resolution: Fixed
Fix Version/s: 3.2
Applied patch with minor tweaks:
- dropped check for valid Locale
- use applyPattern not applyLocalizedPattern
URL: http://svn.apache.org/viewvc?rev=1388806&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/DateUtils.java
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
> 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
[jira] [Updated] (LANG-799) DateUtils#parseDate uses default locale
instead of US (or trying both default locale and Locale.English)
Posted by "Duncan Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Duncan Jones updated LANG-799:
------------------------------
Attachment: commons-lang3-LANG-799.patch
Attached is a patch that adds overloaded versions of parseDate and parseDateStrictly with a Locale parameter (option D), plus unit tests.
If a locale is supplied, the patterns will be interpreted using the date format symbols for that locale.
The original issue would then be addressed by:
{code}
d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", Locale.ENGLISH, new String[] {"EEE, dd MMM yyyy HH:mm:ss zzz"});
{code}
> 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
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461545#comment-13461545 ]
Sebb commented on LANG-799:
---------------------------
Java 7 has many more Locales. It so happens that the first different format string for Java 1.7 use formatting entries that are not in the standard pattern.
Removed the test, as it no longer applies (we don't use localized formats)
URL: http://svn.apache.org/viewvc?rev=1389172&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Remove inappropriate test - we don't use localized formats
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale instead of US (or trying both default locale and Locale.English)
Posted by "Sebb (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461197#comment-13461197 ]
Sebb commented on LANG-799:
---------------------------
URL: http://svn.apache.org/viewvc?rev=1388818&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Remove unnecessary test
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
URL: http://svn.apache.org/viewvc?rev=1388821&view=rev
Log:
LANG-799 - DateUtils#parseDate uses default locale; add Locale support
Parse German date with English Locale, specifying German Locale override
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale instead of US (or trying both default locale and Locale.English)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461137#comment-13461137 ]
Sebb commented on LANG-799:
---------------------------
Added tests to show current behaviour, i.e. ParseException occurs if default Locale does not match date:
URL: http://svn.apache.org/viewvc?rev=1388787&view=rev
Log:
LANG-799 Add tests to show ParseException when default Locale is wrong
Modified:
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/DateUtilsTest.java
Some of these would need to be changed if option D is not used.
> 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
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Duncan Jones (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461198#comment-13461198 ]
Sebb commented on LANG-799:
---------------------------
bq. Please, ensure the tests ruin with Java 5 as well as with newer ones.
The pom specifies Java 1.6 for Lang3
bq. And note, that the JDK switched the behavior between Java 5 and 6. Java 5 always uses English time zone short cuts (e.g. "CET" for Central European Time), while they are localized since Java 6 ("MEZ" for Mitteleuropäische Zeit).
Not sure what that refers to; sounds like a separate bug (if any).
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461196#comment-13461196 ]
Sebb commented on LANG-799:
---------------------------
bq. That last commit now breaks the build, as my test testParseNonSystemLocale() assumed the localized pattern change and now fails.
Does not fail for me, even if I change the default Locale to Locale.GERMAN(Y)
> 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
[jira] [Comment Edited] (LANG-799) DateUtils#parseDate uses default
locale instead of US (or trying both default locale and Locale.English)
Posted by "Duncan Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459015#comment-13459015 ]
Duncan Jones edited comment on LANG-799 at 9/20/12 6:48 AM:
------------------------------------------------------------
Attached is a patch that adds overloaded versions of parseDate and parseDateStrictly with a Locale parameter (option D), plus unit tests.
If a locale is supplied, the patterns will be interpreted using the date format symbols for that locale.
The original issue would then be addressed by:
{code}
d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", Locale.ENGLISH,
new String[] {"EEE, dd MMM yyyy HH:mm:ss zzz"});
{code}
was (Author: dmjones500):
Attached is a patch that adds overloaded versions of parseDate and parseDateStrictly with a Locale parameter (option D), plus unit tests.
If a locale is supplied, the patterns will be interpreted using the date format symbols for that locale.
The original issue would then be addressed by:
{code}
d = DateUtils.parseDate("Wed, 09 Apr 2008 23:55:38 GMT", Locale.ENGLISH, new String[] {"EEE, dd MMM yyyy HH:mm:ss zzz"});
{code}
> 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
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Joerg Schaible (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461159#comment-13461159 ]
Joerg Schaible commented on LANG-799:
-------------------------------------
Please, ensure the tests ruin with Java 5 as well as with newer ones. And note, that the JDK switched the behavior between Java 5 and 6. Java 5 always uses English time zone short cuts (e.g. "CET" for Central European Time), while they are localized since Java 6 ("MEZ" for Mitteleuropäische Zeit).
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Duncan Jones (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated LANG-799:
----------------------
Summary: DateUtils#parseDate uses default locale; add Locale support (was: DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English))
> 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
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale; add Locale support
Posted by "Duncan Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461219#comment-13461219 ]
Duncan Jones commented on LANG-799:
-----------------------------------
bq. Does not fail for me, even if I change the default Locale to Locale.GERMAN(Y)
This appears to be related to Java version. I was inadvertently compiling and executing the tests with JDK 7 not 6. The test passes under 6 and fails under 7.
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale instead of US (or trying both default locale and Locale.English)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461148#comment-13461148 ]
Sebb commented on LANG-799:
---------------------------
The patch breaks the tests I just added for UK and DE parsing.
This is because the patch now uses
parser.applyLocalizedPattern(pattern);
whereas previously it used
parser.applyPattern(pattern);
I think it's wrong to assume that the patterns are localised; it will potentially break existing applications (just as it broke the tests I just added).
> 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
> 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
[jira] [Commented] (LANG-799) DateUtils#parseDate uses default
locale instead of US (or trying both default locale and Locale.English)
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461140#comment-13461140 ]
Sebb commented on LANG-799:
---------------------------
Not sure it's necessary for the code to check that the Locale is supported.
Seems to me such a check should be done by the caller if required.
> 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
> 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