I should have been clearer, but the bug seems to be in the JDK tool which converts CLDR's xml into JDK's resource bundles. I implemented the CLDR's time zone names fallback spec with https://bugs.openjdk.java.net/browse/JDK-8181157, but again there seems to be a bug in the code.

Filed a JDK bug: https://bugs.openjdk.java.net/browse/JDK-8234347

Naoto

On 11/18/19 9:08 AM, Mark Davis ☕️ wrote:
Could you file a ticket at
https://unicode-org.atlassian.net/ ?

{phone}

On Mon, Nov 18, 2019, 16:02 <naoto.s...@oracle.com <mailto:naoto.s...@oracle.com>> wrote:

    Thanks, Mark.

    Apparently there seems to be a bug in CLDR converter code, which cannot
    generate the localized names for "Turkey" metazone. Thus the localized
    names from the legacy COMPAT locale data are being used. I will look
    into it.

    Apart from this, what Letu found out stands by itself as a bug in
    COMPAT
    provider.

    Naoto

    On 11/17/19 11:16 PM, Mark Davis ☕️ wrote:
     > You'd have to look at the spec. For most names a pattern plus the
     > country name is used. That can be overridden with a non-composed
    name
     > where needed.
     >
     > {phone}
     >
     > On Sun, Nov 17, 2019, 21:50 Martin Buchholz <marti...@google.com
    <mailto:marti...@google.com>
     > <mailto:marti...@google.com <mailto:marti...@google.com>>> wrote:
     >
     >     I've always wondered how the timezone-related translations
    are managed.
     >     CLDR seems to be the master repository of such data, and
    projects like
     >     OpenJDK are simply supposed to import that data.
     >     But I looked at the CLDR sources, and there doesn't seem to
    be any
     >     "Turkey
     >     Time" strings defined like there are for e.g. Turkmenistan.
     >     Maybe that work never got done?
     >
     >     On Sat, Nov 16, 2019 at 6:44 AM <naoto.s...@oracle.com
    <mailto:naoto.s...@oracle.com>
     >     <mailto:naoto.s...@oracle.com
    <mailto:naoto.s...@oracle.com>>> wrote:
     >
     >      > Letu,
     >      >
     >      > Please go ahead and fix the issue in English resource. As
    to the
     >      > translation, Oracle l10n will translate it in appropriate
    locales.
     >      >
     >      > Naoto
     >      >
     >      > On 11/15/19 5:56 PM, Yang, Letu wrote:
     >      > > Hi Naoto
     >      > >
     >      > > Thank you for the quick response! We will file a ticket
    later
     >     today.
     >      > >
     >      > > Shall we make an effort on fixing and translating the
    strings,
     >     or you
     >      > > prefer to take care of it at Oracle?
     >      > >
     >      > > Letu
     >      > >
     >      > > On Nov 15, 2019 4:29 PM, naoto.s...@oracle.com
    <mailto:naoto.s...@oracle.com>
     >     <mailto:naoto.s...@oracle.com <mailto:naoto.s...@oracle.com>>
    wrote:
     >      > > Hi Letu,
     >      > >
     >      > > Please file a JBS issue for this (component: core-libs,
     >     subcomponent:
     >      > > java.util:i18n).
     >      > >
     >      > > Naoto
     >      > >
     >      > > On 11/15/19 3:19 PM, Yang, Letu wrote:
     >      > >> Hi,
     >      > >>
     >      > >> We recently found an issue with the Time Zone name for
     >      > “Europe/Istanbul” and "Asian/Istanbul". Since Turkey moved to
     >     their own
     >      > Turkish Time (TRT) zone in 2016, although the tzdata had been
     >     updated, the
     >      > Time Zone name string has not been updated yet:
     >      > >>
     >      > >>
     >      >
     >
    
https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
     >      > >>
     >      > >> It still returns "Eastern European Time" for the
     >      > TimeZone.getDisplayName call, which has a summer time while
     >     Turkish Time
     >      > does not. An entry for TRT need to be added to this file, and
     >     assign to
     >      > both "Europe/Istanbul" and "Asian/Istanbul". This also
    need to
     >     be updated
     >      > for other locales. I can create a JBS issue for this, but I
     >      > > am not sure whether we should fix this bug, or there is
    an existing
     >      > > procedure for this kind of bug which requires language
    translation.
     >      > >>
     >      > >> Letu
     >      > >>
     >      > >>
     >      > >>
     >      >
     >

Reply via email to