On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <na...@openjdk.org> wrote:
>> CLDR provides very few short names for time zones, such as PST/PDT. This >> will typically end up substituting names from the COMPAT provider. Once the >> COMPAT is removed, they will be displayed in the GMT format, i.e., >> GMT+XX:YY. Although some of the short names in the COMPAT provider are >> somewhat questionable (less common ones are simply made up from the long >> names by taking the initials), it would not be desirable for them to fall >> back to the GMT format. >> To mitigate the situation, CLDR can use the abbreviated names from the TZ >> database, which contains legacy (major) short names as FORMAT. The CLDR >> provider can use them instead of the GMT offset style. This enhancement is a >> precursor to the future removal of the COMPAT provider. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Delay populating GMT format at runtime. Reflecting review comments. > CLDR provides very few short names for time zones, such as PST/PDT. This will > typically end up substituting names from the COMPAT provider. Once the COMPAT > is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. > Although some of the short names in the COMPAT provider are somewhat > questionable (less common ones are simply made up from the long names by > taking the initials), it would not be desirable for them to fall back to the > GMT format. To mitigate the situation, CLDR can use the abbreviated names > from the TZ database, which contains legacy (major) short names as FORMAT. > The CLDR provider can use them instead of the GMT offset style. This > enhancement is a precursor to the future removal of the COMPAT provider. This is intentional, because these short names may not be known to users. Do you have data that ja-JP, zh-CN, de-DE users expect and are familiar with `PST/PDT`? This is why CLDR fallback rules would fall back to `Los Angeles Time` for example in the longer name. It's not short, but it's understandable, and the numeric offset can work for short. I'd encourage engaging with CLDR-TC to discuss the short names upstream if you have data on the recognizability of these short names. In fact, CLDR probably has _too many_ short names for zones. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767240212
