littledan
commented
3 years ago Was the idea to remove timezones, in https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-01-14.md#getting-month-and-weekday-names-is-easier-with-temporal-4 ?
Closed FrankYFTang closed 3 years ago
littledan
commented
3 years ago Was the idea to remove timezones, in https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-01-14.md#getting-month-and-weekday-names-is-easier-with-temporal-4 ?
FrankYFTang
commented
3 years ago ECMA402 Jan meeting decide to only keep "calendar" and "unit" in the v2 spec since all the other would be addressed by Temporal specification.
Moved from https://github.com/tc39/proposal-intl-displaynames/issues/17 of v1 repo @sffc from #8 "Time zone display names are already available via ICU APIs:
http://icu-project.org/apiref/icu4c/classicu_1_1TimeZone.html "
@littledan commented on Feb 4, 2019 I'm a big fan of your ideas 3 and 4 in #8 (comment) . Are those to be discussed here?
@FrankYFTang commented on Feb 4, 2019 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 commented on Mar 19, 2019 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 commented on Mar 19, 2019 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.
@FrankYFTang commented on Mar 20, 2019 I propose we keep timezone name out of the scope of version 1 and leave it for future work.
@jungshik commented on Jun 7, 2019 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 commented on Jun 7, 2019 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 commented on Jun 7, 2019 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 commented on Jun 7, 2019 I'd argue about hay this api should only support generic names (DST agnostic names) or add a way to select day name.
@sffc commented on Jun 5 @FrankYFTang Should we remove the "Later" label now that Intl Enumeration is progressing?
@FrankYFTang commented on Jun 5 @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 commented on Jun 5 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.