JDK-8225240 : DateFormat.SHORT produces different result after Java 13 build 21
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 13
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2019-06-04
  • Updated: 2019-07-17
  • Resolved: 2019-06-04
Related Reports
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
$����uname -a                                                                                                                                                                                                  
Linux martin-tuxedo 5.0.0-15-generic #16-Ubuntu SMP Mon May 6 17:41:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ /home/martin/devel/jdk-13/bin/java -version                                                                                                                                                               
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+23)
OpenJDK 64-Bit Server VM (build 13-ea+23, mixed mode, sharing)

A DESCRIPTION OF THE PROBLEM :
Testing Java 13 build 23 with Apache Wicket led to a test failure in formatting dates with DateFormat.SHORT with Locale("nl", "NL"). The test was passing with Java 13 build 18 and earlier versions of Java (12, 11, ...).


REGRESSION : Last worked in version 13

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Execute the code below with Java 13 build 23 and any previous build:


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
01-05-11
ACTUAL -
01-05-2011

---------- BEGIN SOURCE ----------

import java.text.DateFormat;
import java.util.Calendar;
import java.util.Locale;

public class Java13Regression3
{

	public static void main(String[] args)
	{
		final Locale DUTCH_LOCALE = new Locale("nl", "NL");
		Calendar cal = Calendar.getInstance(DUTCH_LOCALE);
		cal.clear();
		cal.set(2011, Calendar.MAY, 1);

		final DateFormat dateFormat = DateFormat.getDateInstance(DateFormat.SHORT, DUTCH_LOCALE);
		final String formatted = dateFormat.format(cal.getTime());
		System.err.println(formatted);
		// prints true for Java 13 build 18 and earlier (Java 12, 11, ...)
		// But prints false for Java 13 build 23
		System.out.println("Expected: " + "01-05-11".equals(formatted));
	}
}
---------- END SOURCE ----------

FREQUENCY : always



Comments
Mention included in the relnote of CLDR 35.1 (JDK-8223587)
05-06-2019

The SHORT pattern for Dutch locale has changed in CLDR in v34: https://www.unicode.org/cldr/charts/34/delta/nl.html#Formats%20-%20Standard%20-%20Date%20Formats https://unicode-org.atlassian.net/browse/CLDR-11156 The definition of the CLDR's "year" pattern is: --- Calendar year (numeric). In most cases the length of the y field specifies the minimum number of digits to display, zero-padded as necessary; more digits will be displayed if needed to show the full year. However, ���yy��� requests just the two low-order digits of the year, zero-padded as necessary. --- This is consistent with SimpleDateFormat's year pattern. Since b21, CLDR in the JDK has been upgraded to v35.1 (JDK-8221432), and thus the 4 digit year is displayed.
04-06-2019

The issue started occurring from JDK 13-ea+21. JDK-8221432 may be the probable cause as this went in b21. There is a difference in the short date format between CLDR v33 and CLDR v35 for "nl" language : CLDR v33 - It was dd-MM-yy https://www.unicode.org/cldr/charts/33/by_type/date_&_time.gregorian.html#57dac0d1b36c1261 CLDR v35.1 - It is dd-MM-y https://www.unicode.org/cldr/charts/35/by_type/date_&_time.gregorian.html#57dac0d1b36c1261 Test Results : JDK 13-ea + 19 - Pass JDK 13-ea + 20 - Pass JDK 13-ea + 21 - Fail JDK 13-ea + 22 - Fail Output on failed versions: 01-05-2011 Expected: false
04-06-2019