JDK-8134384 : Continuation of JDK-8130845 : A date string created by Date#toString() is not parseable neither with ENGLISH, US nor ROOT locale
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-08-25
  • Updated: 2016-08-24
  • Resolved: 2015-09-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b82Fixed
Related Reports
Relates :  
Relates :  
Description
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"
Comments
FYI. Using SimpleDateFormat(String pattern, Locale locale).parse(String text, ParsePosition pos), the test passes. Using the inherited method parse(String source), as in user's test, it fails.
27-08-2015

Asia/Urumqi (Asia/Kashgar is an alias) changed from PRC to XJT in 2014f. But CLDR doesn't seem to have the data for Asia/Urumqi (and its alias). For formatting the JRE locale data is looked up when a time zone isn't found in CLDR, but for parsing only CLDR data is used. It'd be necessary to fill in display names of any missing time zones from the JRE locale data.
25-08-2015

Testcase from Uwe is attached.
25-08-2015