JDK-8256837 : SimpleDateFormat can not parse date anymore
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 16
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86_64
  • Submitted: 2020-11-20
  • Updated: 2023-09-13
  • Resolved: 2020-11-23
Related Reports
Duplicate :  
JDK-8293917 - SimpleDateFormat yy-MMM-dd formats September as Sept
Duplicate :  
JDK-8297127 - bug in DateTimeFormatter when using "MMM" (outputs Sept instead of Sep)
Duplicate :  
JDK-8273437 - java.text.SimpleDateFormat fails to parse 3 letter month 'Sep'
Duplicate :  
JDK-8281302 - Fatal parse errors: shortname for September has been changed in Locale.UK.
Relates :  
JDK-8251317 - Update CLDR to version 38.0
Description
A DESCRIPTION OF THE PROBLEM :
JDK16+25 cannot parse a simple date: 

See: https://travis-ci.org/github/graphhopper/graphhopper/jobs/744890249

REGRESSION : Last worked in version 16

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
no error
ACTUAL -
ParseException at java.base/java.text.DateFormat.parse(DateFormat.java:396)

---------- BEGIN SOURCE ----------
DateFormat df = new SimpleDateFormat("yyyy MMM dd", Locale.UK);
df.setTimeZone(TimeZone.getTimeZone("UTC"));
df.parse("2015 Sep 30"); // => java.text.ParseException: Unparseable date: "2015 Sep 30"
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
This does not happen with JDK16+24: https://travis-ci.org/github/graphhopper/graphhopper/jobs/744725038
Comments
Now that the COMPAT provider is deprecated. Here is a workaround to remedy this specific situation by providing an SPI implementation. ``` package spi; import java.text.DateFormatSymbols; import java.text.spi.DateFormatSymbolsProvider; import java.util.Calendar; import java.util.Locale; public class ShortMonthModifier extends DateFormatSymbolsProvider { @Override public DateFormatSymbols getInstance(Locale locale) { assert locale.equals(Locale.UK); return new DateFormatSymbols() { @Override public String[] getShortMonths() { var ret = new DateFormatSymbols(Locale.UK).getShortMonths().clone(); ret[Calendar.SEPTEMBER] = "Sep"; return ret; } }; } @Override public Locale[] getAvailableLocales() { return new Locale[]{Locale.UK}; } } ``` Once this class is placed on the classpath with META-INF/services/java.text.spi.DateFormatSymbolsProvider file containing "spi.ShortMonthModifier", applications (invoked with -Djava.locale.providers=SPI,CLDR) formatting the short month name for September in the UK will get "Sep", instead of "Sept." However, our recommendation is still to migrate the applications' code to CLDR.
13-09-2023
If you can make your code change, I'd suggest specifying Locale.US in the formatter. Still, there is a very slim chance that CLDR could change the abbreviated name to "Sept" in Locale.US though, which turns things into the same situation. Another option is to select the locale data that is compatible with the one in JDK8, by specifying `-Djava.locale.providers=COMPAT` in the system property on the Java runtime invocation. This will make sure the name for September is "Sep" in Locale.UK, but may not benefit from locale related features that are integrated after JDK8.
24-11-2020
[~naoto] Please find the reply and query from the reporter. --------------- Yes, we might be using the tip of the JDK16 repo. The problem is when I use "Sept" it will fail now and when I use "Sep" it will fail in latest JDK16. It seems to work with Locale.US or Locale.ROOT - is this the way to solve this? I understand (now) that this is not what the pattern of three "MMM" means according to the docs, but we need to parse months with 3 letters as the data in OpenStreetMap is like this and won't change. Have created an issue in our repo - https://github.com/graphhopper/graphhopper/issues/2186 --------------
24-11-2020
Correct me if I am wrong, but I believe the test must have been done with the tip of JDK16 repository, not with b25. If that's the case, it is working as expected. With the integration of CLDR 38, the abbreviated month name for September in en-GB locale is now "Sept", thus "Sep" would not be parsed. Here is the diff in the upstream CLDR change: https://unicode-org.github.io/cldr-staging/charts/38/delta/en.html#Months%20-%20abbreviated%20-%20Standalone
23-11-2020
The observations on Windows and Oracle Linux: JDK 16-ea+24: Passed JDK 16-ea+25: Passed This incident is not an issue.
23-11-2020