JDK-8180591 : Timezone displayname is incorrect for some Timezone ID
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-05-18
  • Updated: 2018-04-26
  • Resolved: 2018-04-26
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
11Fixed
Related Reports
Blocks :  
Description
Steps:
Test Timezone display name consistency between CLDR and Java.
Found some timezone ID's display name are incorrect by Java API.

For example, running below code:
public void TZDisplayName() {
        String tag = "en";
        Locale target = Locale.forLanguageTag(tag);
        Locale.setDefault(target);
        TimeZone testTZ = TimeZone.getTimeZone("Pacific/Bougainville");
        TimeZone.setDefault(testTZ);
        String displayName = testTZ.getDisplayName();
        System.out.println("tz displayname:" + displayName);
    }

The output of Java is "New Zealand Standard Time". But I checked CLDR en.xml, the display name should be "Papua New Guinea Time".

The same issue happens on tzid "Asia/Srednekolymsk"

Comments
Fixed along with JDK-8181157.
26-04-2018

The cause of the issue is that CLDRConverter fails to parse CLDR's metaZones.xml, where <usesMetaZone> only contains "to", i.e., no meta zones defined. Pacific/Bougainville and Asia/Srednekolymsk are the ones that fall into that category. In such cases, CLDR locale provider should fallback according to the LDML spec, and compose appropriate display names, such as SHORT: UTC+11 LONG: Bougainville Standard Time
05-06-2017