-
Bug
-
Resolution: Fixed
-
P2
-
9
-
b82
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8142045 | emb-9 | Naoto Sato | P2 | Resolved | Fixed | team |
Here is the email from Uwe Schindler:
> 2. The second problem is about the SimpleDateFormat/Locale problems. This was fixed in build 77, but was fixed incomplete. So please reopen the issue (https://bugs.openjdk.java.net/browse/JDK-8130845, same as https://bugs.openjdk.java.net/browse/JDK-8129881), and attach the following information:
>
> Our test framework found a date string which was created by Date#toString(), which is not parseable, neither with ENGLISH, US or ROOT locale! The date that failed was: "Sat Jun 23 02:57:58 XJT 2012" (created by Date#toString() on XJT default timezone). XJT is Xinjiang Time also known as "Asia/Kashgar", used in parts of China (https://en.wikipedia.org/wiki/Asia/Kashgar). I would suggest that there should be some test that asserts the round trip between the above Date format and Date#toString() for all Timezones available.
>
> I set up a quick round trip test (it iterates all available timezones in the JDK, sets them as default, creates a String out of new Date().toString() and tried to parse that afterwards with ENGLISH, US and ROOT locale.
>
> ===================================================
> import java.text.ParseException;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import java.util.Locale;
> import java.util.TimeZone;
>
> public final class Test {
>
> private static void testParse(Locale locale, String date) {
> try {
> new SimpleDateFormat("EEE MMM d hh:mm:ss z yyyy", locale).parse(date);
> System.out.println(String.format(Locale.ENGLISH, "OK parsing '%s' in locale '%s'", date, locale));
> } catch (ParseException pe) {
> System.out.println(String.format(Locale.ENGLISH, "ERROR parsing '%s' in locale '%s': %s", date, locale, pe.toString()));
> }
> }
>
> public static void main(String[] args) {
> for (String id : TimeZone.getAvailableIDs()) {
> System.out.println("Testing time zone: " + id);
> TimeZone.setDefault(TimeZone.getTimeZone(id));
>
> // some date today:
> String date1 = new Date(1440358930504L).toString();
> testParse(Locale.ENGLISH, date1);
> testParse(Locale.US, date1);
> testParse(Locale.ROOT, date1);
> // half a year back to hit DST difference:
> String date2 = new Date(1440358930504L - 86400000L * 180).toString();
> testParse(Locale.ENGLISH, date2);
> testParse(Locale.US, date2);
> testParse(Locale.ROOT, date2);
> }
> }
>
> }
> ========================================================
> With Java 8 this passes, with Java 9 build 78 it fails for several timezones. The funny thing is: SimpleDateFormat is not even able to parse "UTC"
> 2. The second problem is about the SimpleDateFormat/Locale problems. This was fixed in build 77, but was fixed incomplete. So please reopen the issue (https://bugs.openjdk.java.net/browse/JDK-8130845, same as https://bugs.openjdk.java.net/browse/JDK-8129881), and attach the following information:
>
> Our test framework found a date string which was created by Date#toString(), which is not parseable, neither with ENGLISH, US or ROOT locale! The date that failed was: "Sat Jun 23 02:57:58 XJT 2012" (created by Date#toString() on XJT default timezone). XJT is Xinjiang Time also known as "Asia/Kashgar", used in parts of China (https://en.wikipedia.org/wiki/Asia/Kashgar). I would suggest that there should be some test that asserts the round trip between the above Date format and Date#toString() for all Timezones available.
>
> I set up a quick round trip test (it iterates all available timezones in the JDK, sets them as default, creates a String out of new Date().toString() and tried to parse that afterwards with ENGLISH, US and ROOT locale.
>
> ===================================================
> import java.text.ParseException;
> import java.text.SimpleDateFormat;
> import java.util.Date;
> import java.util.Locale;
> import java.util.TimeZone;
>
> public final class Test {
>
> private static void testParse(Locale locale, String date) {
> try {
> new SimpleDateFormat("EEE MMM d hh:mm:ss z yyyy", locale).parse(date);
> System.out.println(String.format(Locale.ENGLISH, "OK parsing '%s' in locale '%s'", date, locale));
> } catch (ParseException pe) {
> System.out.println(String.format(Locale.ENGLISH, "ERROR parsing '%s' in locale '%s': %s", date, locale, pe.toString()));
> }
> }
>
> public static void main(String[] args) {
> for (String id : TimeZone.getAvailableIDs()) {
> System.out.println("Testing time zone: " + id);
> TimeZone.setDefault(TimeZone.getTimeZone(id));
>
> // some date today:
> String date1 = new Date(1440358930504L).toString();
> testParse(Locale.ENGLISH, date1);
> testParse(Locale.US, date1);
> testParse(Locale.ROOT, date1);
> // half a year back to hit DST difference:
> String date2 = new Date(1440358930504L - 86400000L * 180).toString();
> testParse(Locale.ENGLISH, date2);
> testParse(Locale.US, date2);
> testParse(Locale.ROOT, date2);
> }
> }
>
> }
> ========================================================
> With Java 8 this passes, with Java 9 build 78 it fails for several timezones. The funny thing is: SimpleDateFormat is not even able to parse "UTC"
- backported by
-
JDK-8142045 Continuation of JDK-8130845 : A date string created by Date#toString() is not parseable neither with ENGLISH, US nor ROOT locale
- Resolved
- relates to
-
JDK-8130845 Change to CLDR Locale data in JDK 9 b71 causes SimpleDateFormat parsing errors
- Closed
-
JDK-8129881 JDK-8008577 breaks Nashorn test
- Closed