JDK-8194735 : Exception on parsing with java.text.DateFormat.getDateTimeInstance().parse()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 9.0.1
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2018-01-08
  • Updated: 2018-11-30
  • Resolved: 2018-01-08
Description
FULL PRODUCT VERSION :
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux cs86612 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
When we use java.text.DateFormat.getDateTimeInstance().parse() can produce a bug.

REGRESSION.  Last worked in version 8u144

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Sun Nov 10 18:00:00 CST 2013
ACTUAL -
Produce a bug.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.text.ParseException: Unparseable date: "11 November 2013 00:00:00 GMT"
	at java.base/java.text.DateFormat.parse(DateFormat.java:388)
	at edu.utd.cs.testjdk.TestCalendar001.testPasadate(TestCalendar001.java:15)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at junit.framework.TestCase.runTest(TestCase.java:176)
	at junit.framework.TestCase.runBare(TestCase.java:141)
	at junit.framework.TestResult$1.protect(TestResult.java:122)
	at junit.framework.TestResult.runProtected(TestResult.java:142)
	at junit.framework.TestResult.run(TestResult.java:125)
	at junit.framework.TestCase.run(TestCase.java:129)
	at junit.framework.TestSuite.runTest(TestSuite.java:252)
	at junit.framework.TestSuite.run(TestSuite.java:247)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package edu.utd.cs.testjdk;

import java.text.DateFormat;
import java.text.ParseException;
import java.util.Date;
import java.util.Locale;

import org.junit.Test;

import junit.framework.TestCase;

public class TestParsedata extends TestCase{
	@Test
	public void testPasadate() throws ParseException  {
		Date mtime = DateFormat.getDateTimeInstance(1, 1, Locale.UK).parse("11 November 2013 00:00:00 GMT");
		assertEquals("Sun Nov 10 18:00:00 CST 2013",mtime);
	}
	

}
---------- END SOURCE ----------

SUPPORT :
YES


Comments
Please refer : http://www.oracle.com/technetwork/java/javase/9-relnote-issues-3704069.html#JDK-8008577 In JDK 9, the default locale data uses data derived from the Unicode Consortium's Common Locale Data Repository (CLDR). So there are changes with respect to some locales and hence this difference. For the English locale , the date-time long format pattern has 'at' string after date as per the CLDR whereas it was just a blank space in JRE(COMPAT). Hence the difference in the output in JDK 8 and JDK 9. Refer: http://www.unicode.org/cldr/charts/29/by_type/date_&_time.gregorian.html#1219d5305851a4d To use the JRE locale with JDK 9 set java.locale.providers to a value with COMPAT ahead of CLDR. : -Djava.locale.providers=COMPAT, CLDR
08-01-2018