JDK-8293917 : SimpleDateFormat yy-MMM-dd formats September as Sept
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 18
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2022-09-14
  • Updated: 2024-04-01
  • Resolved: 2022-10-18
Related Reports
Duplicate :  
JDK-8256837 - SimpleDateFormat can not parse date anymore
Duplicate :  
JDK-8329375 - English date format MMM does not always yield 3 letter month
Relates :  
JDK-8297127 - bug in DateTimeFormatter when using "MMM" (outputs Sept instead of Sep)
Description
ADDITIONAL SYSTEM INFORMATION :
Is a problem in 17, works in jdk-10.0.1.jdk, not sure when the problem arose

A DESCRIPTION OF THE PROBLEM :
Working output 

Incorrect output

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See test case

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
14-9-2022
14-09-2022
14-Sep-2022
14-September-2022
14-8-2022
14-08-2022
14-Aug-2022
14-August-2022
14-7-2022
14-07-2022
14-Jul-2022
14-July-2022
14-6-2022
14-06-2022
14-Jun-2022
14-June-2022
14-5-2022
14-05-2022
14-May-2022
14-May-2022
14-4-2022
14-04-2022
14-Apr-2022
14-April-2022
14-3-2022
14-03-2022
14-Mar-2022
14-March-2022
14-2-2022
14-02-2022
14-Feb-2022
14-February-2022
14-1-2022
14-01-2022
14-Jan-2022
14-January-2022
14-12-2021
14-12-2021
14-Dec-2021
14-December-2021
14-11-2021
14-11-2021
14-Nov-2021
14-November-2021
14-10-2021
14-10-2021
14-Oct-2021
14-October-2021

ACTUAL -

14-9-2022
14-09-2022
14-Sept-2022
14-September-2022
14-8-2022
14-08-2022
14-Aug-2022
14-August-2022
14-7-2022
14-07-2022
14-Jul-2022
14-July-2022
14-6-2022
14-06-2022
14-Jun-2022
14-June-2022
14-5-2022
14-05-2022
14-May-2022
14-May-2022
14-4-2022
14-04-2022
14-Apr-2022
14-April-2022
14-3-2022
14-03-2022
14-Mar-2022
14-March-2022
14-2-2022
14-02-2022
14-Feb-2022
14-February-2022
14-1-2022
14-01-2022
14-Jan-2022
14-January-2022
14-12-2021
14-12-2021
14-Dec-2021
14-December-2021
14-11-2021
14-11-2021
14-Nov-2021
14-November-2021
14-10-2021
14-10-2021
14-Oct-2021
14-October-2021


---------- BEGIN SOURCE ----------
Test case

import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;

class SDFTest {

	private static final SimpleDateFormat sdfddMMMyyyy = new SimpleDateFormat("dd-MMM-yyyy");
	private static final SimpleDateFormat sdfddMMMMyyyy = new SimpleDateFormat("dd-MMMM-yyyy");
	private static final SimpleDateFormat sdfddMMyyyy = new SimpleDateFormat("dd-MM-yyyy");
	private static final SimpleDateFormat sdfddMyyyy = new SimpleDateFormat("dd-M-yyyy");

	public static void main(String[] args) {

		GregorianCalendar cal = new GregorianCalendar();
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Non, with recoding zillions of programs to add a check for Sep/Sept grrrrr

FREQUENCY : always
Comments
JDK is a downstream user of CLDR (Common Locale Data Repository, run by Unicode Consortium), and the change was done in the upstream CLDR: https://unicode-org.github.io/cldr-staging/charts/38/delta/en.html#Months%20-%20abbreviated%20-%20Standalone I'd recommend you file a bug report against CLDR with a rationale to revert that "Sept" change.
28-09-2022
Additional Information from submitter: =========================== Why on earth did you change the MMM substitution to "Sept" in locale en.GB. It makes no sense and violates that java principle of write once run anywhere. Not impressed you will not fix this.
28-09-2022
It looks like a duplicate of JDK-8256837. Closed as not an issue. Using Locale.US resolved the problem: private static final SimpleDateFormat sdfddMMMyyyy = new SimpleDateFormat("dd-MMM-yyyy", Locale.US);
16-09-2022
Requested a complete reproducer from the submitter.
15-09-2022