[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-tabpanelfocusedCommentId=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=1388787view=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 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)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 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)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 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)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 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
