JDK-8210490 : TimeZone.getDisplayName given Locale.US doesn't always honor the Locale
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-09-05
  • Updated: 2018-11-21
  • Resolved: 2018-09-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12
11.0.2Fixed 12 b12Fixed
Related Reports
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
(Discovered in Apache Lucene/Solr randomized tests including locale & JVM randomization)

A DESCRIPTION OF THE PROBLEM :
When the default locale is Arabic, the timeZone.getDisplayName method does not honor the Locale.US argument.  This is important as it's used by date.toString()!

REGRESSION : Last worked in version 8u181

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
(see short demonstration program)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
GMT+05:00
ACTUAL -
GMT+����������������:����������������

---------- BEGIN SOURCE ----------
// RUN WITH ASSERTIONS ENABLED:  -ea

import java.util.Locale;
import java.util.TimeZone;

public class TestJdkBug {
  public static void main(String[] args) {
    Locale.setDefault(Locale.forLanguageTag("ar")); // (Arabic)
    TimeZone zi = TimeZone.getTimeZone("Etc/GMT-5");
    final String displayName = zi.getDisplayName(false, TimeZone.SHORT, Locale.US);
    assert "GMT+05:00".equals(displayName) : displayName;
  }
}
---------- END SOURCE ----------

FREQUENCY : always



Comments
Fix Request - Justification: The patch fixes incorrect generation of time zone display names for US locale that results in incorrectly generated date string. - Risk Analysis: Low. Fixes the regression caused by latest CLDR Update - Testing: tier1,tier2,tier3 regression tests (includes the modified one) - The patch from jdk/jdk applies cleanly
23-10-2018

proposed fix : to specify locale for formatting instead of using system default formatting. http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/
14-09-2018

regression introduced by JDK-8202537.
10-09-2018

To reproduce the issue, run the attached test case. This has started failing from JDK 11ea+19 onwards, CLDR was upgraded to v 33 which may be the cause. Here are the results of the attached test case : JDK 10.0.2 - Pass JDK 11-ea + 18 - Pass JDK 11-ea + 19 - Fail JDK 11-ea+28 - Fail Exception in thread "main" java.lang.AssertionError: GMT+����:���� at JI9057084.main(JI9057084.java:11)
07-09-2018