Note: ICU4J TimeZoneNames/TimeZoneFormat were included in ICU4J 4.8 as technology preview.

Background

Requirements

1. Performance
• The current implementation gathers all possible display names (many are generated algorithmically, not fetched from resource) for parsing. The initialization of the name trie is extremely heavy and require huge memory footprint. It is desired to reduce the size of trie and also defer the initialization until it is really required.
• A set of all available names for a single time zone are initialized as whole. Even format method does not use a certain type of names, the current implementation require all of them initialized at the same time (and more than the simple locale data retrieval is required for initializing a certain type of names) .
  
2. Direct access to plain name resources  The ICU resource contains plain time zone names in relatively complex structure. There are a lot of code and logic involved for displaying a time zone name. For now, ICU does not expose the direct access to these plain names, instead, users can only access the names via format object (TimeZone#getDisplayName also internally call a part of format code). However, some ICU users want to access these names without other overhead. For example, Harmony/Android (or ICU's own Java TimeZoneNameProvider implementation) just want to get long/short specific names (such as Eastern Standard Time, PDT). These names are stored in the ICU resources as is and it does not require any complicated logic involved for their usage. Other users want to get names stored in the ICU resource, but not able to get them as is (always used as a part of format). For example, ICU import exemplar city name data from CLDR. Even someone want to compose a zone name using them - for example "GMT-05:00 New York, Detroit, Montreal", there is no way to collect localized exemplar city names with public APIs.
3. Customization
1. Before the LDML "metazone" model was introduced, ICU users can get/set time zone names through DateFormatSymbols object. DateFormatSymbols represents time zone name in a plain 2 dimensional array. After "metazone" was introduced, we can no longer represent time zone names in this form, because the metazone require historic name mappings and some logic required for distinguishing one zone from another mapped to the same metazone. For now, the time zone array in DateFormatSymbols is not used, and not useful at all. We need public APIs matching the LDML time zone display name algorithm and data structure for allowing ICU users to access and customize display names. [MD] This is especially important for CLDR work as well, that we can override any of the ICU data.
2. GMT format (such as "GMT+03:00") is not customizable through public APIs. There is a demand to compose time zone string from different patterns.
   

UTS#35 Time Zone Display Name Basics

UTS#35 LDML defines several style of time zone display names and fallbacks. Certain style of names are not stored in CLDR directly and some algorithms involved for getting the final display name. Also, each name style has its own goal and round trip requirements. To achieve these goals, display name for a certain type may use a variant form. The table below illustrates these styles, algorithm and variations.

Strategies

• Create a new class for representing the CLDR time zone display name data model
• Make the class as an API class, so ICU users can fully customize the time zone display name data used by ICU. This makes CLDR ST to populate time zone names on the fly, allow us to write verification code for detecting name collisions, etc.
• We can deprecate the use of the legacy 2-dimensional zone strings in DateFormatSymbols for customizing the zone display names in DateFormat, which no longer works fully with the current algorithm.
• The new API class allows direct data access to raw time zone display names including "exemplar city" names which can be found only in a part of generic location format currently.
• Software only requiring specific long/short names (such as Android/Harmony, Java LocaleSPI TimeZoneNameProvider) can access the names directly through the API without dragging various overheads with time zone generic name handling.
• In ICU4J, the isolation of time zone display name data allows us to make a time zone display name data provider as a separate component.
  
• Create a new public API - time zone format class interacting with the time zone display name data model class above
• Add setter/getter for the time zone format class in SimpleDateFormat. This allows ICU users to customize time zone display names at the data level as well as allow them to fully customize time zone display name format used by ICU date format.
• All pattern driven time zone name formatter and fallback logic belong to this class implementation.
• Optimized for most common use cases
• The default time patterns used by DateFormat do not contain generic time zone name types (location / non-location). These generic time zone names are not simple data, instead, a lot of fallback/construction logic involved as you can see the table in the previous section. The current ICU implementation load and initialize generic names with other type of names used by the default time patterns. The new implementation defers the initialization for generic names until they are requested.
• The current ICU time zone parse require all names including generic names are collected and stored in a trie. By setting a limitation - do not parse names that are never generated by the date format instance, the new implementation can skip the initialization of all generic names and putting them into the trie.