Supporting TimeZone names in Intl.DisplayNames API

[FrankYFTang]

This is spin off from #8 . I think it is better to have one request per issue to make the discussion easier.

[FrankYFTang]

per @sffc from #8
"Time zone display names are already available via ICU APIs:

http://icu-project.org/apiref/icu4c/classicu_1_1TimeZone.html "

[FrankYFTang]

@littledan

[littledan]

I'm a big fan of your ideas 3 and 4 in #8 (comment) . Are those to be discussed here?

[FrankYFTang]

I'm a big fan of your ideas 3 and 4 in #8 (comment) . Are those to be discussed here?

I already put "3. Date Field:" and "4. Date Symbol" into the latest spec. If you would like to change that, could you file a different issue instead. I would like to keep #17 for discussion of how we serve (or not) TimeZone only.

[littledan]

Data size wise, time zone names are already accessible in DateTimeFormat, right? Is the reason for excluding them in this version that they are not very useful, or something else?

[FrankYFTang]

The reason I have not yet put timezone name into this proposal is mainly because I have not yet figure out what should be the input domain and what should be the output domain. There are tzID, and mzID as input in icu::TimeZoneNames and there are getMetaZoneDisplayName, getTimeZoneDisplayName , getExemplarLocationName , and getDisplayName as function there. Also the input to . output is not as straight forward as other since some may need to know the current time to figure out to show the daylight saving time or not.
Some of the timezone name data might not needed for DateTimeFormat. For example I do not think ExemplarLocationName is needed for DateTimeFormat but maybe only OS need them.

I talked to Mark Davis two weeks ago to understand more but I am still not sure what input domain (tzID, mzID or both) are useful for the developer. Nor do I have figured out how to deal with daylight saving time. I feel for the case of getting timezone names, it is a much complicated operation comparing to other display name.

[littledan]

Thanks for explaining; the complexity here seems like a great reason to defer this feature.

[FrankYFTang]

I propose we keep timezone name out of the scope of version 1 and leave it for future work.

[jungshik]

See also tc39/ecma402#119 and http://cldr.unicode.org/translation/date-time and
http://unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names as well.

[jungshik]

Putting aside details, I'd say the input should be just an Olson/IANA timezone ID. As seen in references in the previous comment, there can be multiple outputs varying along multiple axes (it's not just short/long but also 'generic/exemplar city/....'. ).

[FrankYFTang]

Putting aside details, I'd say the input should be just an Olson/IANA timezone ID. As seen in references in the previous comment, there can be multiple outputs varying along multiple axes (it's not just short/long but also 'generic/exemplar city/....'. ).

more that, the name usually need to be decided with the knowledge of isDST

[jungshik]

I'd argue about hay this api should only support generic names (DST agnostic names) or add a way to select day name.

[sffc]

@FrankYFTang Should we remove the "Later" label now that Intl Enumeration is progressing?

[FrankYFTang]

@FrankYFTang Should we remove the "Later" label now that Intl Enumeration is progressing?

This is different than Intl Enumeration API. Intl Enumeration API allow developer to know what timezone ID are supported. The request of support of TimeZone ID in Intl.DisplayNames API ask us to provide a way to return the name for those ID per Locale.

[sffc]

The key use case for the Intl Enumeration API is to provide a list to populate pickers. Display names are needed in order to make those pickers intl-friendly. Therefore, it seems that we should prioritize adding time zone display names at least at the same pace as the Intl Enumeration API.

[FrankYFTang]

I put together a v2 repo on https://github.com/FrankYFTang/intl-displaynames-v2/ please move the future discussion there.

[FrankYFTang]

This proposal reach Stage 4 in TC39 Sep 2020 meeting. Move this issue to tc39/proposal-intl-displaynames-v2#14