JDK-8211321 : DateTimeFormatter throws DateTimeParseException on valid input
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 11,12
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2018-10-01
  • Updated: 2018-11-09
  • Resolved: 2018-10-01
Related Reports
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
Microsoft Windows [Version 10.0.17134.320]

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12-ea+13)
OpenJDK 64-Bit Server VM 19.3 (build 12-ea+13, mixed mode)

A DESCRIPTION OF THE PROBLEM :
Running the attached testcase under Java 10.0.2 works. Running the same testcase under Java 11 or Java 12 throws a DateTimeParseException.

REGRESSION : Last worked in version 10.0.2

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run testcase

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Result: 2018-09-29T20:49:02Z
ACTUAL -
Exception in thread "main" java.time.format.DateTimeParseException: Text 'Sat, 29 Sep 2018 20:49:02 GMT' could not be parsed at index 0
        at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2046)
        at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1948)
        at Testcase.main(Testcase.java:14)

---------- BEGIN SOURCE ----------
import java.time.Instant;
import java.time.format.DateTimeFormatter;
import java.time.format.DateTimeFormatterBuilder;
import java.time.format.DateTimeFormatterBuilder;
import java.util.Locale;

class Testcase
{
	public static void main (String[] args) throws java.lang.Exception
	{
		DateTimeFormatter dateFormatter = new DateTimeFormatterBuilder().
		  appendPattern("EEE, dd MMM yyyy HH:mm:ss zzz").
		  toFormatter(Locale.CANADA);
		Instant result = dateFormatter.parse("Sat, 29 Sep 2018 20:49:02 GMT", Instant::from);
		System.out.println("Result: " + result);
	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use Locale.US instead of Locale.CANADA

FREQUENCY : always



Comments
Based on the observation given in the comments, closing it as "Not an Issue"
01-10-2018

In CLDRv33, the locale in question "en_CA", defines the format abbreviated day names as "Sun.", "Mon.", "Tue.", "Wed.", "Thu.", "Fri.", "Sat." and month names as "Jan.", "Feb.", "Mar.", "Apr.", "May", "Jun.", "Jul.", "Aug.", "Sep.", "Oct.", "Nov.", "Dec.". For the given example, the correct input string required for parsing should be "Sat., 29 Sep. 2018 20:49:02 GMT", in which it returns the expected output as "2018-09-29T20:49:02Z"
01-10-2018

It looks like a regression from JDK-8202537
01-10-2018

Issue is reproducible: JDK11 build 18 - PASS JDK11 build 19 - FAIL JDK11 build 28 - FAIL JDK12 build 13 - FAIL
01-10-2018

To add more to the previous comment. In JDK10 the CLDR version used is 29, in which "en_CA" does not specify the abbreviated day and month names, so I think the lookup is falling back to "en", which specify the abbreviated form without '.' e.g. "Sun"
01-10-2018