From e47fa411cde8a0bff4b1a0c6a8a60847fa6cfd48 Mon Sep 17 00:00:00 2001 From: ctcpip Date: Fri, 16 Feb 2024 15:17:43 -0600 Subject: [PATCH] =?UTF-8?q?=F0=9F=9A=9A=20replace=20old=20references?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 6 +- meetings/agenda-2018-02-16.md | 2 +- meetings/agenda-2019-01-17.md | 2 +- meetings/notes-2017-12-15.md | 6 +- meetings/notes-2018-01-19.md | 40 +++++------ meetings/notes-2018-02-16.md | 16 ++--- meetings/notes-2018-03-16.md | 22 +++--- meetings/notes-2018-04-20.md | 4 +- meetings/notes-2018-06-15.md | 6 +- meetings/notes-2018-07-19.md | 6 +- meetings/notes-2018-08-16.md | 8 +-- meetings/notes-2019-01-17.md | 10 +-- meetings/notes-2019-05-09.md | 12 ++-- meetings/notes-2019-10-24.md | 22 +++--- meetings/notes-2019-11-14.md | 32 ++++----- meetings/notes-2019-12-12.md | 50 +++++++------- meetings/notes-2020-01-09.md | 36 +++++----- meetings/notes-2020-01-30.md | 14 ++-- meetings/notes-2020-02-27.md | 16 ++--- meetings/notes-2020-03-26.md | 14 ++-- meetings/notes-2020-04-23.md | 12 ++-- meetings/notes-2020-05-21.md | 4 +- meetings/notes-2020-06-11.md | 20 +++--- meetings/notes-2020-07-09.md | 6 +- meetings/notes-2020-08-13.md | 12 ++-- meetings/notes-2020-09-10.md | 2 +- meetings/notes-2020-10-08.md | 2 +- meetings/notes-2020-11-05.md | 6 +- meetings/notes-2020-12-04.md | 2 +- meetings/notes-2021-01-14.md | 4 +- meetings/notes-2021-02-11.md | 4 +- meetings/notes-2021-03-11.md | 6 +- meetings/notes-2021-04-08.md | 30 ++++---- meetings/notes-2021-05-06.md | 12 ++-- meetings/notes-2021-06-03.md | 4 +- meetings/notes-2021-07-01.md | 6 +- meetings/notes-2021-09-09.md | 6 +- meetings/notes-2021-10-07.md | 52 +++++++------- meetings/notes-2021-11-04.md | 48 ++++++------- meetings/notes-2021-12-02.md | 42 ++++++------ meetings/notes-2022-01-13.md | 32 ++++----- meetings/notes-2022-02-10.md | 34 ++++----- meetings/notes-2022-03-17.md | 12 ++-- meetings/notes-2022-04-21.md | 36 +++++----- meetings/notes-2022-05-19.md | 30 ++++---- meetings/notes-2022-06-16.md | 18 ++--- meetings/notes-2022-07-07.md | 70 +++++++++---------- meetings/notes-2022-08-04.md | 44 ++++++------ meetings/notes-2022-09-01.md | 18 ++--- meetings/notes-2022-10-06.md | 124 ++++++++++++++++----------------- meetings/notes-2022-11-03.md | 12 ++-- meetings/notes-2022-12-08.md | 2 +- meetings/notes-2023-01-12.md | 80 ++++++++++----------- meetings/notes-2023-02-09.md | 108 ++++++++++++++--------------- meetings/notes-2023-03-09.md | 64 ++++++++--------- meetings/notes-2023-04-06.md | 124 ++++++++++++++++----------------- meetings/notes-2023-05-04.md | 102 +++++++++++++-------------- meetings/notes-2023-06-01.md | 88 ++++++++++++------------ meetings/notes-2023-06-29.md | 86 +++++++++++------------ meetings/notes-2023-08-03.md | 112 +++++++++++++++--------------- meetings/notes-2023-09-07.md | 126 +++++++++++++++++----------------- meetings/notes-2023-10-12.md | 68 +++++++++--------- meetings/notes-2023-11-16.md | 50 +++++++------- meetings/notes-2023-12-14.md | 4 +- meetings/notes-2024-01-18.md | 68 +++++++++--------- scripts/auto-deploy.sh | 2 +- 66 files changed, 1059 insertions(+), 1059 deletions(-) diff --git a/README.md b/README.md index 4fdb28f1..47555e6e 100644 --- a/README.md +++ b/README.md @@ -11,9 +11,9 @@ This source is processed to obtain a human-readable version, which you can view Proposals follow [the TC39 process](https://tc39.es/process-document/) and are tracked in the [proposals repository](https://github.com/tc39/proposals). -* [Finished Proposals](https://github.com/tc39/proposals/blob/master/ecma402/finished-proposals.md) -* [Active Proposals](https://github.com/tc39/proposals/blob/master/ecma402/README.md) -* [Stage 0 Proposals](https://github.com/tc39/proposals/blob/master/ecma402/stage-0-proposals.md) +* [Finished Proposals](https://github.com/tc39/proposals/blob/HEAD/ecma402/finished-proposals.md) +* [Active Proposals](https://github.com/tc39/proposals/blob/HEAD/ecma402/README.md) +* [Stage 0 Proposals](https://github.com/tc39/proposals/blob/HEAD/ecma402/stage-0-proposals.md) Information about status of tests, documentations and browser implementations of proposals can be found in [this wiki page](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking). diff --git a/meetings/agenda-2018-02-16.md b/meetings/agenda-2018-02-16.md index 3ed410b1..d1eb2d62 100644 --- a/meetings/agenda-2018-02-16.md +++ b/meetings/agenda-2018-02-16.md @@ -17,7 +17,7 @@ Contact Daniel Ehrenberg (littledan@igalia.com) for the link to the Google Hango 1. [Locale](https://github.com/tc39/proposal-intl-locale) 1. [lb option added to Segmenter](https://github.com/tc39/proposal-intl-segmenter/pull/24); [renamed to lineBreakStyle](https://github.com/tc39/proposal-intl-segmenter/pull/25) 1. [Settled on numeric: always/auto](https://github.com/tc39/proposal-intl-relative-time/pull/60) - 1. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/master/es8/2018-01/jan-23.md#4-ecma402-status-updates) + 1. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/HEAD/es8/2018-01/jan-23.md#4-ecma402-status-updates) 1. Non-members who contribute to ECMA 402 (either PRs or in this call): Sign [this form](https://tc39.es/agreements/contributor/) to license contributions to Ecma 1. Questions/issues with existing advanced proposals and APIs 1. [Normative: Add calendar and numberingSystem options](https://github.com/tc39/ecma402/pull/175) diff --git a/meetings/agenda-2019-01-17.md b/meetings/agenda-2019-01-17.md index 38f8910b..2060b827 100644 --- a/meetings/agenda-2019-01-17.md +++ b/meetings/agenda-2019-01-17.md @@ -36,7 +36,7 @@ Contact Daniel Ehrenberg (littledan@igalia.com) for the link to the Google Hango 1. Move under TC39 by creating a new project and following instruction on [Template for Proposals](https://github.com/tc39/template-for-proposals) 2. Frank Tang will Champion 3. Have problem to move Issues from the [old location](https://github.com/brawer/proposal-intl-displaynames). - 4. Now list under [Stage 0 of ECMA402](https://github.com/tc39/proposals/blob/master/ecma402/stage-0-proposals.md) + 4. Now list under [Stage 0 of ECMA402](https://github.com/tc39/proposals/blob/HEAD/ecma402/stage-0-proposals.md) 5. Would like to change the API shape in [README](https://github.com/tc39/proposal-intl-displaynames/pull/2) and [SPEC](https://github.com/tc39/proposal-intl-displaynames/pull/4) 6. And like to move under Stage 1 6. Newer proposals diff --git a/meetings/notes-2017-12-15.md b/meetings/notes-2017-12-15.md index a3eea112..6d55d613 100644 --- a/meetings/notes-2017-12-15.md +++ b/meetings/notes-2017-12-15.md @@ -1,4 +1,4 @@ -Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2017-12-15.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2017-12-15.md) +Agenda: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2017-12-15.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2017-12-15.md) # Attendees @@ -11,7 +11,7 @@ Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2017-12-15. * RX: Rafael Xaviers (Paypal) * MS: Michael Saboff (Apple) * SM: Stas Małolepszy (Mozilla) -* CC: Craig Cornelius (Google) +* CC: Craig Cornelius (Google) * FB: Felipe Balbontín (Google) * CP: Caridy Patiño (Salesforce) * JS: Jungshik Shin (Google) @@ -128,7 +128,7 @@ ZB: these prefs could be made locale-sensitive, as in, dateStyle: short might me DE: navigator.locales could expose OS’s calendar prefs (something navigator.languages doesn’t expose) -DE: Intl.Locale API makes an update that corresponds to lang tag and options You can parse out the script or change the calendar and pass it to other Intl ctors. +DE: Intl.Locale API makes an update that corresponds to lang tag and options You can parse out the script or change the calendar and pass it to other Intl ctors. NC: it feels like it combines two separate things: locales and user preferences. diff --git a/meetings/notes-2018-01-19.md b/meetings/notes-2018-01-19.md index 565dbdcc..c040d706 100644 --- a/meetings/notes-2018-01-19.md +++ b/meetings/notes-2018-01-19.md @@ -1,16 +1,16 @@ -Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-01-19.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-01-19.md) +Agenda: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-01-19.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-01-19.md) Attendees: -* Caridy Patino (CP) - -* Zbignew Braniecki (ZB) - Mozilla - -* Daniel Ehrenberg (DE) - Igalia - github.com/littledan +* Caridy Patino (CP) - +* Zbignew Braniecki (ZB) - Mozilla - +* Daniel Ehrenberg (DE) - Igalia - github.com/littledan * Stas Malolepszy (SM) * Jungshik Shin (JS) - Google - github.com/jungshik * Steven R. Loomis (SL) - IBM - github.com/srl295 * Eemeli Aro (EA) - github.com/eemeli -* Nebojsa Ciric (NC) - Google -* Shane Carr (Shane) - Google +* Nebojsa Ciric (NC) - Google +* Shane Carr (Shane) - Google * JH: Jack Horton (MSFT) github.com/jackhorton * DIV: Doug Ilijev (MSFT) github.com/dilijev * BT: Brian Terlson (MSFT) github.com/bterlson @@ -48,10 +48,10 @@ Attendees: * ZB: Seems like this would be useful in Intl.js * NC: Does PluralRules enable us to do message formatting any way we want until we get actual message formatting * JS: Any plural-related things, lets you select the message. Doesn’t include the message. - * ZB: Everything on top of PluralRules is just an algorithm, so hopefully this reduces the load of any + * ZB: Everything on top of PluralRules is just an algorithm, so hopefully this reduces the load of any * EA: The data is small here - * NC: Seems like this - * DE: Is there a way to get the list of availableLocales for plural rules? + * NC: Seems like this + * DE: Is there a way to get the list of availableLocales for plural rules? * EA: Seen a locale with Cardinal rules but without Ordinal Rules * SL: can assume that if ‘locale’ data (e.g. for formatting) is available for a given locale, PR is also available for the locale. * SM: Firefox ships or is preparing to ship in 19 locales which don't have plural rules defined in the CLDR. These are: ach, an, cak, csb, gn, hto, ia (Interlingua), kok, lij, ltg, mai, oc, pbb, qvi, rw, sat, son, trs, tsz. @@ -94,7 +94,7 @@ Attendees: 10. JS: Yes. Actually we had some historical Mozilla test that we had to disable since it expected the spec semantics. 11. DE: I’m not sure if OS semantics support this, as opposed to using ICU. Many JS implementations currently use OS APIs. 12. JS: I think the Windows API supports this, but we would’ve had to modify the sandbox to support it. For Linux, it probably is possible, but it would probably require a lot of hooks and duplicating a lot of what ICU does. For that reason, I didn’t other to do it. - 13. SL: POSIX APIs assume that + 13. SL: POSIX APIs assume that 14. JS: I have an ICU change request open to change ICU to make this easier to implement. 15. ZB: Do implementers have any concerns? 16. JH: If this will require an ICU API, we definitely need it to not be internal. @@ -109,7 +109,7 @@ Attendees: * CP: None of the formats that are there make forward-compatibility guarantees. * ZB: UTS 35 doesn’t help us too much; none of ECMA 402 depends on this. We’d have to make a lot of changes to the specification, and not make things data-dependent. * SC: If we introduce this, then other specifications could be rephrased in terms of this new data source. - * CP: The problem is the stability of UTS 35--we have to make sure that + * CP: The problem is the stability of UTS 35--we have to make sure that * DE: Seems like there is still a lot more design work. 3. Stage 3 proposals 1. [Intl.Segmenter](https://github.com/tc39/proposal-intl-segmenter/) @@ -127,8 +127,8 @@ Attendees: * SL: There’s a stripped-down data set by default, and then you can install all the data which includes dictionaries. * DE: So, is unspecified breaking right? And, should we continue to leave the connection to CSS unspecified? * JS: ICU has ‘strict’, ‘loose’ and ‘normal’ from CSS3. Does Ecma want to have those options? - * DE: Possible to add them as an option. Currently, there’s no option. - * DE: how about ‘word-break: break-all’? + * DE: Possible to add them as an option. Currently, there’s no option. + * DE: how about ‘word-break: break-all’? * JS: This is for latin text in CJK text * SL: There’s a lot of room for improvement here * NC: Internally in Google, there’s a lot of machine learning work going on for segmenters @@ -144,7 +144,7 @@ Attendees: * DE: Currently strictness is only supported via the options bag * JS: Seems like we should add this to the locale tag. * SL: There are many other things in locales that could be added - * SL: Unicode locale extensions have ‘lb’ (line breaking), ‘wb’ (? word breaking), ss (suppress …), + * SL: Unicode locale extensions have ‘lb’ (line breaking), ‘wb’ (? word breaking), ss (suppress …), * SL: If we have those three in the BCP, we should mention them in the specification here. [https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeLineBreakStyleIdentifier](https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeLineBreakStyleIdentifier) [https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeSentenceBreakSuppressionsIdentifier](https://www.unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#UnicodeSentenceBreakSuppressionsIdentifier) * NC: Currently we support lb. Should we support wb and ss? Are they important enough? Some of these seem a little artificial, like ss, which is based on the technology underneath. * SL: I don’t quite follow. Ss specifies an improvement to line breaks using commonly known exceptions. @@ -162,7 +162,7 @@ Attendees: * DE: compound unit is not supported. Earlier draft supported it, but it was removed due to design issues. * JS: future plan for compound unit? * DE: We could do this in a future version, but there are many policy choices, so it is complicated. List format over RelativeTF is an option. - * NC: Does this work + * NC: Does this work * DE: What should we do about type: numeric/text, which has numeric as the default? * JS: What’s the motivation? * DE: You don’t know which is the right cutoff unless you know what time of day it is, etc. You don’t have the timeline that this is relative to. @@ -175,8 +175,8 @@ Attendees: * DIV: I think numeric should be the default. * CP: I think so too. You have to be aware of this issue if you want to get yesterday/tomorrow. * DIV: Speaking of days, can we have "1 day, 1 hour, and 30 seconds ago"? - * (reply): can do with [ListFormat](?) + RelativeTimeFormat - * This is a low-level API (similar to PluralRules) on top of which a library writer can implement a smarter (higher-level) API. + * (reply): can do with [ListFormat](?) + RelativeTimeFormat + * This is a low-level API (similar to PluralRules) on top of which a library writer can implement a smarter (higher-level) API. * Will present next week (name TBD?) 2. [Intl.Locale](https://github.com/tc39/proposal-intl-locale/) * Stage 2 @@ -187,7 +187,7 @@ Attendees: * JS: Yes, it should be explicit. * Conclusion: Not supported. * [Will not throw an exception on unsupported locales](https://github.com/tc39/proposal-intl-locale/issues/6) - * NC: We were talking about possible additional data packs. This allows working with the locale ID. We don’t have any data, but we have a working BCP 47 ID. If it goes into date formatter, date formatter will + * NC: We were talking about possible additional data packs. This allows working with the locale ID. We don’t have any data, but we have a working BCP 47 ID. If it goes into date formatter, date formatter will * [Should additional tags be passed through?](https://github.com/tc39/proposal-intl-locale/issues/4) * SL: Should be able to round-trip, though it’s OK to sort the tags and normalize the locale. * OK to ship this as a minimal base, with other important complements (likely subtags, display names, more options) in follow-on proposals? @@ -198,7 +198,7 @@ Attendees: * Ready for Stage 3? * DE: Interface to BCP 47. Identify script, region, language, etc from a given locale id. Has toString() to build a locale id in a string * DE: future extension for likelySubtag, etc - * When Locale is passed to Intl.* API, should Locale be treated specially instead of invoking toString() ? + * When Locale is passed to Intl.* API, should Locale be treated specially instead of invoking toString() ? * DE: Yes 3. [Intl.ListFormat](https://github.com/tc39/proposal-intl-list-format) * Stage 2 @@ -210,7 +210,7 @@ Attendees: 22. NS: Should we rename regular to "and" and add negative lists as “or”? 23. DIV: How about we call regular lists "conjunction" and add “disjunction” (linguistic terms rather than english-specific words “and”/”or”) 24. ZB: I like this suggestion, since "and" and “or” seems too specific to English - 25. DIV: There are issues in languages about handling adjectives, etc. + 25. DIV: There are issues in languages about handling adjectives, etc. 26. ZB: I’m not sure if we’ll support adjectives here. 27. NC: Do we need gender information? ListFormat supports this... 1. SL: personList with gender diff --git a/meetings/notes-2018-02-16.md b/meetings/notes-2018-02-16.md index 69af4098..0328f559 100644 --- a/meetings/notes-2018-02-16.md +++ b/meetings/notes-2018-02-16.md @@ -1,4 +1,4 @@ -Agenda: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md) +Agenda: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md) Attendees: Zibi Braniecki, Mozilla (ZB), Caridy Patiño (CP), Brian Terlson (BT), Doug Ilijev (DIV), Jack Horton (JH) Steven R. Loomis (SR), Shane Carr (SC), Jeff Genovy (JG) Felipe (F) @@ -15,7 +15,7 @@ Agenda: * [Locale](https://github.com/tc39/proposal-intl-locale) 3. [lb option added to Segmenter](https://github.com/tc39/proposal-intl-segmenter/pull/24);[ renamed to lineBreakStyle](https://github.com/tc39/proposal-intl-segmenter/pull/25) 4. [Settled on numeric: always/auto](https://github.com/tc39/proposal-intl-relative-time/pull/60) - 5. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/master/es8/2018-01/jan-23.md#4-ecma402-status-updates) + 5. [Explained the existence of this call; well-received](https://github.com/tc39/tc39-notes/blob/HEAD/es8/2018-01/jan-23.md#4-ecma402-status-updates) 6. Non-members who contribute to ECMA 402 (either PRs or in this call): Sign[ this form](https://tc39.es/agreements/contributor/) to license contributions to Ecma 2. Questions/issues with existing advanced proposals and APIs 1. [Normative: Add calendar and numberingSystem options](https://github.com/tc39/ecma402/pull/175) @@ -155,15 +155,15 @@ SR: und is root. JS: better for users to explicitly specify a locale, rather than mysterious default locale showing up automatically -??: +??: Conclusion: Throw when a locale isn’t provided. **Item 2.iii.c** -ZB: +ZB: -SR: +SR: **Item 3 (ICU tickets)** @@ -211,7 +211,7 @@ SC: yes, this includes unit format on it. JH: I want to point two things. This relies heavily on ICU design, which MS usually push back. Point two is the the C implementation of these ICU apis is very far away it seems. This might put a serious burden on us. -SC: Yes, there are ICU Apis that maps directly to this new APIs. But this is a 402 spec, we don’t have to model the spec after ICU. +SC: Yes, there are ICU Apis that maps directly to this new APIs. But this is a 402 spec, we don’t have to model the spec after ICU. DIV: We (Chakra) must have non-experimental ICU C (not C++) APIs to implement any of these features. Until experimental tag is removed from those C APIs, we should not allow these proposals to get to stage 4. @@ -247,13 +247,13 @@ Conclusion: Felipe will prepare the material to present it on the next tc39 meet NC: the last one worked better. -• looking at overflow: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md#overflow](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-02-16.md#overflow) +• looking at overflow: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md#overflow](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-02-16.md#overflow) ZB: ovf 1.iv.b - likelySubtags NC: maximize? Yes. (and minimize) -ZB: ovf 1.vi.a: datetime style? +ZB: ovf 1.vi.a: datetime style? CP: Organizational…  Will be out 2H2018, need help on editorial role. diff --git a/meetings/notes-2018-03-16.md b/meetings/notes-2018-03-16.md index 7680bf6b..f93bab0a 100644 --- a/meetings/notes-2018-03-16.md +++ b/meetings/notes-2018-03-16.md @@ -1,4 +1,4 @@ -Agenda link: [https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-03-16.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-03-16.md) +Agenda link: [https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-03-16.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-03-16.md) Attendees: @@ -36,7 +36,7 @@ Agenda and minutes (take notes inline) * Notes: * Jungshik: Supporting lw supports a lot of things, and ICU doesn’t actually support it. It doesn’t make sense. You need the part of speech marker, etc, not so it’s not so useful for Chinese and Japanese. * Dan: And ss? - * Jungshik: Maybe, not sure, but I’m against lw. There are only some exceptions there. There are only 30 entries per language. So it should be pretty small. + * Jungshik: Maybe, not sure, but I’m against lw. There are only some exceptions there. There are only 30 entries per language. So it should be pretty small. * Steven Loomis: This would be useful * Steven: For counting sentences for translation or split up for other purposes, we make use of sentence suppressions to make sure the sentences aren’t split incorrectly. * Jungshik: Examples are ‘Dr.’, ‘Mr.’, ‘Mrs.’, ‘i.e.’, and so forth. @@ -60,7 +60,7 @@ Agenda and minutes (take notes inline) * [Return DefaultLocale() when calling Intl.Locale() with an absent/undefined tag argument?](https://github.com/tc39/proposal-intl-locale/issues/15) * Conclusion was to not make this change and require an argument? * Ciric: The discussion is between making undefined lead to the root locale, or throw an exception. We agreed that we don’t want to expose the default locale here. - * Zibi: Intl.Locale is a way of processing locales, not + * Zibi: Intl.Locale is a way of processing locales, not * Steven: It’d be a convenience, but it might not add much value and blur the distinction between a class responsible for processing data. The Locale should be an identifier, not a service * Dan: Does anyone have a problem with throwing an exception here? * (everyone is OK with it) @@ -74,7 +74,7 @@ Agenda and minutes (take notes inline) 2. Some impl. may not full set of data and will fall back to ‘en’ for everything. This should (?) still be fully spec compliant. 3. Steven asks if Segmenter’s `ss` is an example of something that could be optional 1. Dan says that we shouldn’t increase the surface of optionality if possible - 4. Dan points out that optionality of hourCycle vs caseFirst uses different mechanisms. + 4. Dan points out that optionality of hourCycle vs caseFirst uses different mechanisms. 5. We’re going to continue the conversation offline * How are we handling regular and irregular grandfathered tags? (also for the [main specification](https://github.com/tc39/ecma402/issues/177)) 6. Ciric: Are these just for historical reasons? @@ -113,8 +113,8 @@ Agenda and minutes (take notes inline) * Steven: Will add an ECMA bug label/keyword for JS-related things 3. [TimeZone::getOffset() : add two params to control repeated/skipped wall time](https://unicode-org.atlassian.net/browse/ICU-13268) * Jungshik wrote a patch, anyone want to review? - * Was a proposal sent to icu-design? - * No. Jungshik will propose. + * Was a proposal sent to icu-design? + * No. Jungshik will propose. * Jungshik: Not blocked by this issue, (v8 implementation is pending review) 4. [Get locales with PluralRules support](https://unicode-org.atlassian.net/browse/ICU-12756) * Should we close as will-not-fix because all locales will always be considered supported? @@ -128,10 +128,10 @@ Agenda and minutes (take notes inline) * [items that were promoted](https://ssl.icu-project.org/repos/icu/tags/release-61-rc/icu4c/APIChangeReport.html#promoted) * Jeff: there are some APIs (identified by Jack) slated to be promoted to stable in ICU 61 release. * PSA [please test the release candidate](http://site.icu-project.org/download/61) - * Jeff: the majority of timezone APIs are currently C++ only. (getOffset-related) ⇒ **TODO(jungshik)**: file a ticket + * Jeff: the majority of timezone APIs are currently C++ only. (getOffset-related) ⇒ **TODO(jungshik)**: file a ticket * Apple/Microsoft: Can only use ICU C APIs, no C++ API usage at all. * Mozilla also prefers C APIs where possible. - * **TODO(Apple/Microsoft/Mozilla)**: Add comments to Shane’s NumberFormat [C API](https://unicode-org.atlassian.net/browse/ICU-13597) ticket + * **TODO(Apple/Microsoft/Mozilla)**: Add comments to Shane’s NumberFormat [C API](https://unicode-org.atlassian.net/browse/ICU-13597) ticket 6. Any other support needed from ICU for Intl proposals? * [Implementers feedback on issues when trying to merge ICU 61 into SpiderMonkey](https://bugzilla.mozilla.org/show_bug.cgi?id=1445465) * proposed to be [fixed in ICU61](https://unicode-org.atlassian.net/browse/ICU-13648) @@ -162,7 +162,7 @@ Agenda and minutes (take notes inline) * Caridy: I definitely know of several cases that would break * Shane: If we have to keep style: currency, I’d want to do style: measure * Jack: Also, for percent, it’s only indicated by style. - * Jungshik: Now we don’t have to worry about any sort of priority + * Jungshik: Now we don’t have to worry about any sort of priority * **Conclusion: Keep style** * **A 2** * Follow up on details about naming once we have a specific draft of the spec @@ -185,7 +185,7 @@ Agenda and minutes (take notes inline) * **Conclusion: folded to be a part of new "unified" Number format** * ** "list number format" (e.g. 10 meters and 35 centimeters): Introduce a list format** 4. [BigInt.prototype.toLocaleString](https://github.com/tc39/ecma402/issues/218#issuecomment-370789166) - * Dan: overload ‘format’ method with NumberFormat? ‘String’ is coerced to Number instead of BigInt. + * Dan: overload ‘format’ method with NumberFormat? ‘String’ is coerced to Number instead of BigInt. 5. Future meetings 1. Does the two-hour, once a month format still work well? 2. Feedback about prioritization, running meeting, etc @@ -193,7 +193,7 @@ Agenda and minutes (take notes inline) * Are we missing out on participation from Asia with these meeting times? * Standing request: Find a time which is not Friday evening in some time zones 6. Other - 1. Steven: FYI: Node.js considering including full data by default (not English-only). [https://github.com/nodejs/node/issues/19214](https://github.com/nodejs/node/issues/19214) Feedback wanted, but relevant to discussion here about data size impact implementations. + 1. Steven: FYI: Node.js considering including full data by default (not English-only). [https://github.com/nodejs/node/issues/19214](https://github.com/nodejs/node/issues/19214) Feedback wanted, but relevant to discussion here about data size impact implementations. 2. Steven: Q: seprate C++/C library for common implementation of ecma402 related operations (on top of ICU or ported)? (locale/option bag handling might be interesting) Pro: common code FTW, don't need to wait for Ecma402-focussed API improvements in ICU. Con: many implementations are already a thin wrapper on ICU. Jeff: What would be the Licensing of such a library? What language(s) for implementation? * Rust? (serious proposal: C/C++ FFI, compiles to WASM and JS) diff --git a/meetings/notes-2018-04-20.md b/meetings/notes-2018-04-20.md index fa5e997b..0d0598db 100644 --- a/meetings/notes-2018-04-20.md +++ b/meetings/notes-2018-04-20.md @@ -6,7 +6,7 @@ Attendees: Agenda and notes -[https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-04-20.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-04-20.md) +[https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-04-20.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-04-20.md) 1. Administrative issues 1. Anyone want to help out with cleaning up and publishing notes for this meeting and past meetings? @@ -112,5 +112,5 @@ Agenda and notes * Are we missing out on participation from Asia with these meeting times? * Standing request: Find a time which is not Friday evening in Europe 8. Ad-hoc questions from a v8 engineer (Sathya Gunasekaran -I have a spec question: what should be behavior if the options argument to the Intl.Locale constructor is a proxy? Looking at the other intl methods, we explicitly convert the options argument to an ordinary object: [https://tc39.es/ecma402/#sec-todatetimeoptions](https://tc39.es/ecma402/#sec-todatetimeoptions) (see the unconditional call to ObjectCreate(options)) Should this be done for Intl.Locale too? +I have a spec question: what should be behavior if the options argument to the Intl.Locale constructor is a proxy? Looking at the other intl methods, we explicitly convert the options argument to an ordinary object: [https://tc39.es/ecma402/#sec-todatetimeoptions](https://tc39.es/ecma402/#sec-todatetimeoptions) (see the unconditional call to ObjectCreate(options)) Should this be done for Intl.Locale too? NumberFormat doesn't seem to do this https://tc39.es/ecma402/#sec-initializenumberformat though .. diff --git a/meetings/notes-2018-06-15.md b/meetings/notes-2018-06-15.md index a3146842..03495afd 100644 --- a/meetings/notes-2018-06-15.md +++ b/meetings/notes-2018-06-15.md @@ -6,7 +6,7 @@ Attendees Agenda and notes -[https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-06-15.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-06-15.md) +[https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-06-15.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-06-15.md) 1. Questions/issues with existing advanced proposals and APIs 1. [Improve handling of non-Gregorian calendars](https://github.com/tc39/ecma402/pull/227) @@ -76,7 +76,7 @@ Agenda and notes 1. Is there a ticket for fixing/changing ICU? 33. DE: Could we permit implementation-defined mappings to eliminate all grandfathered tags (in practice, ICU mappings) 34. JS: ICU has several bugs in this mapping area - 35. SL: [https://unicode-org.atlassian.net/browse/ICU-13650](https://unicode-org.atlassian.net/browse/ICU-13650) is one filed to update ICU's behavior. (probably just a bug/outdated instead of a policy difference); + 35. SL: [https://unicode-org.atlassian.net/browse/ICU-13650](https://unicode-org.atlassian.net/browse/ICU-13650) is one filed to update ICU's behavior. (probably just a bug/outdated instead of a policy difference); 36. JS: there are also a series of bugs filed on this issue. I have a fix for Chrome and will plan to upstream the fix to ICU. e.g. [https://unicode-org.atlassian.net/browse/ICU-13720](https://unicode-org.atlassian.net/browse/ICU-13720) (13721, 13723, 13726 , 13719, 9562) 37. JW: full list of grandfathered, no Prefix is ["i-default", "i-enochian", "i-mingo", "cel-gaulish", "zh-min"] 38. DE: Conclusion: Keep IANA grandfathered tags translation, and when there is no official mapping, throw/replace as described earlier/ @@ -162,7 +162,7 @@ Agenda and notes * NC: Requires options, and if we do the constructor, we shift things around. * DE: What do people think about the two options? * NC: If we need resolvedOptions, we need a constructor. - * JS: ZB’s 3-yr old issue for[ Intl.DisplayName](https://github.com/tc39/ecma402/issues/31) (3rd option in DE’s bug) + * JS: ZB’s 3-yr old issue for[ Intl.DisplayName](https://github.com/tc39/ecma402/issues/31) (3rd option in DE’s bug) * SL: Is there already a locale name formatter? * DE: I don’t think that exists yet. * DE: Does anyone have concerns with the Intl.DisplayName constructor-based approach/ diff --git a/meetings/notes-2018-07-19.md b/meetings/notes-2018-07-19.md index 720a2d58..f700fcd0 100644 --- a/meetings/notes-2018-07-19.md +++ b/meetings/notes-2018-07-19.md @@ -20,7 +20,7 @@ Shane Carr Agenda and minutes -[https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-07-19.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-07-19.md) +[https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-07-19.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-07-19.md) 1. PRs against ECMA-402 1. [Normative: Improve handling of non-Gregorian calendars](https://github.com/tc39/ecma402/pull/227) @@ -34,7 +34,7 @@ Agenda and minutes 7. JH: That's feasible, but it won't land for a while. We're also stabilizing. 8. DE: That's fine; I think a PR out for review will give us good evidence about this patch. 9. SL: ICU moved to GitHub, so you can make a PR to make this public. - 10. JG: link: [https://github.com/unicode-org/icu](https://github.com/unicode-org/icu) + 10. JG: link: [https://github.com/unicode-org/icu](https://github.com/unicode-org/icu) 11. JG: Jack if you can point me to the ICU enum, I can try to help get it public (file tickets/PR/etc.) if you are busy. 2. Tests? 1. JH: I think this will depend on the locale tag @@ -124,7 +124,7 @@ Agenda and minutes 14. EA: You know whether it's narrow from the constructor object 15. SC: OK, so we like the name "compact". 3. Measurement unit fallback behavior: [sffc/proposal-unified-intl-numberformat#11](https://github.com/sffc/proposal-unified-intl-numberformat/issues/11) - 1. SC: My preference is 3. + 1. SC: My preference is 3. 2. SL: What is ICU's behavior here? 3. SC: ICU links against the units--their behavior is, throw a compiler error. 4. SL: Can't you specify a type by name? Or not relevant? diff --git a/meetings/notes-2018-08-16.md b/meetings/notes-2018-08-16.md index 963cd640..e6bec8da 100644 --- a/meetings/notes-2018-08-16.md +++ b/meetings/notes-2018-08-16.md @@ -4,7 +4,7 @@ Attendees Agenda and minutes -[https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-08-16.md](https://github.com/tc39/ecma402/blob/master/meetings/agenda-2018-08-16.md) +[https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-08-16.md](https://github.com/tc39/ecma402/blob/HEAD/meetings/agenda-2018-08-16.md) 1. PRs against ECMA-402 1. Any? @@ -15,7 +15,7 @@ Agenda and minutes * Any issues with testing? (Should be pretty complete) * Does ICU work well for backing an Intl.Locale implementation? * Other Intl.Locale issues? - 2. [https://github.com/tc39/proposal-intl-locale/pulls](https://github.com/tc39/proposal-intl-locale/pulls) + 2. [https://github.com/tc39/proposal-intl-locale/pulls](https://github.com/tc39/proposal-intl-locale/pulls) 3. DE: Does [https://github.com/tc39/proposal-intl-locale/pull/57](https://github.com/tc39/proposal-intl-locale/pull/57) look good? OK, I'll land it 4. DE: Any concerns about [https://github.com/tc39/proposal-intl-locale/pull/58](https://github.com/tc39/proposal-intl-locale/pull/58) ? OK, will land it 5. DE: Any concerns about [https://github.com/tc39/proposal-intl-locale/pull/59](https://github.com/tc39/proposal-intl-locale/pull/59) , which treats kn better? @@ -68,7 +68,7 @@ Agenda and minutes 30. SL: Yeah, let's do that and also document to developers that they should use short in this sort of case. 31. DE: This could also be in the string for the RangeError. 32. SL: We could add a sentence in the CLDR spec to call this out, if it's helpful. - 33. Conclusion: Throw a RangeError on narrow + conjunction/disjunction + 33. Conclusion: Throw a RangeError on narrow + conjunction/disjunction * How are implementations coming? 34. V8 is done, we just have the ICU bug that need to be fixed 1. The FieldPositionIterator implementation ([ICU-13754](https://unicode-org.atlassian.net/browse/ICU-13754)) @@ -142,7 +142,7 @@ Agenda and minutes 1. Real-time communication: Should we restart the ECMA-402 Slack channel? Or use IRC? Or stick to monthly meetings? * SL: We have a Slack at [https://team-ecmascript.slack.com](https://team-ecmascript.slack.com) / [https://team-ecmascript.slack.com/messages/C040MA3AD](https://team-ecmascript.slack.com/messages/C040MA3AD) - low activity here 46. Let's discuss it on #tc39 - * ZB: IRC would be fine, since we have TC39 IRC ( #tc39 on freenode ) + * ZB: IRC would be fine, since we have TC39 IRC ( #tc39 on freenode ) * SG: When I had * DE: We should make a posting on the TC39 repository (telling people how to get to the channel) * DE: I don’t mind issues being filed on repositories; it’s good for history diff --git a/meetings/notes-2019-01-17.md b/meetings/notes-2019-01-17.md index 94cccf7b..34d848e6 100644 --- a/meetings/notes-2019-01-17.md +++ b/meetings/notes-2019-01-17.md @@ -34,7 +34,7 @@ Attendees: Nebojsa Ciric (NC), Frank Tang (FT), Daniel Ehrenberg (DE), Shane Ca 9. DE: No; Norbert was opposed to full parity between options and locale. So we want to make sure there is consistency between locale and the options object. For example, collator phonebook order is in locale but not the options object. So if you make resolvedOptions.locale just the locale and not the unicode extension keys, then you lose information. 10. FT: I thought the Unicode extension would be morphed or removed. 11. DE: If you make a Collator with phonebook, the only place you find it in resolvedOptions is in the locale string. - 12. FT: If it's not what we resolved to… + 12. FT: If it's not what we resolved to… 13. DE: Right now, it's removed from the locale tag only if there's another setting that overrides it. 14. NC: There are two things in Collator specifically. There are some flags for collator that are not present as key/value in the options object. So the question is, should we make this symmetrical, and then cut things off from the locale? 15. DE: I think we should review Norbert Lindenberg's rationalle about why we don't have full parity. I will pull up that discussion and send it out. @@ -142,23 +142,23 @@ Attendees: Nebojsa Ciric (NC), Frank Tang (FT), Daniel Ehrenberg (DE), Shane Ca 2. [dateStyle/timeStyle](https://github.com/tc39/proposal-ecma402-datetime-style) (Stage 1) 1. ('full', 'long', 'medium', 'short') or ('full', 'long', 'short', 'narrow')? see [issue/14](https://github.com/tc39/proposal-intl-datetime-style/issues/14) 1. DE will follow up offline. - 2. (after meeting) FT- [https://github.com/tc39/proposal-intl-datetime-style/pull/16](https://github.com/tc39/proposal-intl-datetime-style/pull/16) + 2. (after meeting) FT- [https://github.com/tc39/proposal-intl-datetime-style/pull/16](https://github.com/tc39/proposal-intl-datetime-style/pull/16) 4. Stage 1 proposals 5. Stage 0 proposals 1. [Intl.DisplayNames](https://github.com/tc39/proposal-intl-displaynames) 1. Move under TC39 by creating a new project and following instruction on [Template for Proposals](https://github.com/tc39/template-for-proposals) 2. Frank Tang will Champion 3. Have problem to move Issues from the [old location](https://github.com/brawer/proposal-intl-displaynames). - 4. Now list under [Stage 0 of ECMA402](https://github.com/tc39/proposals/blob/master/ecma402/stage-0-proposals.md) + 4. Now list under [Stage 0 of ECMA402](https://github.com/tc39/proposals/blob/HEAD/ecma402/stage-0-proposals.md) 5. Would like to change the API shape in [README](https://github.com/tc39/proposal-intl-displaynames/pull/2) and [SPEC](https://github.com/tc39/proposal-intl-displaynames/pull/4) 6. And like to move under Stage 1 1. NC: I discussed this with FT yesterday and there are simple ofScript() and ofRegion() but for ofLanguage() it should include the basename of the locale. 2. FT: yea, "language code" is too small but “locale” is too big for that because “locale” could have unicode extensions and I don’t think we should support the name for something like “en-u-nu-Thai” so the current proposal only take language [“-” script] [“-” region] (“-” variant) without the extension. Just the base name of the locale. 3. DE- but why not? I think those key are still useful. 4. NC: There are request to open it up for other name, such as currency name, weekday names, etc - 5. FT: I think we should have a small set as good foundation for stage 1 and I will make a list of possible thing to add and prioritize it. For example, later we can add ofCurrency() or ofCalendar(). And we can discuss that in the stage 1 about where to make the cut. + 5. FT: I think we should have a small set as good foundation for stage 1 and I will make a list of possible thing to add and prioritize it. For example, later we can add ofCurrency() or ofCalendar(). And we can discuss that in the stage 1 about where to make the cut. 6. DE: Someone ask for Emoji name since there are a lot of data. - 7. FT: We probably could consider that for V2, I will have hard time to convince Chrome team to bundle a long list name with all the locale into chrome. That will increase the browser download size a lot. + 7. FT: We probably could consider that for V2, I will have hard time to convince Chrome team to bundle a long list name with all the locale into chrome. That will increase the browser download size a lot. 8. DE: Doesn’t Android already have those name? I see Spanish emoji name on my phone already. 9. FT: Ok, I will dig into that. We can discuss such during Stage 1. But I am not going to GoDaddy next week. Could someone present that in TC39 for me? 10. DE: Just make sure you put that into their agenda and you can just dial in. diff --git a/meetings/notes-2019-05-09.md b/meetings/notes-2019-05-09.md index 85f49e00..a4a5093c 100644 --- a/meetings/notes-2019-05-09.md +++ b/meetings/notes-2019-05-09.md @@ -38,7 +38,7 @@ Last month: FT filed a bug to implement in Chromium. https://bugs.chromium.org/p/v8/issues/detail?id=9155 -FT: Has issue with r and U (cycle year name). No “skeleton” for requesting relativeYear only relativeYear in “pattern”. +FT: Has issue with r and U (cycle year name). No “skeleton” for requesting relativeYear only relativeYear in “pattern”. FT: My understanding from the PR is that you should allow in the options and resolvedOptions to have relativeYear. In CLDR and ICU, for non-grego calendars, there is a formatted result that has a relative year. The tricky part is, there is no way to request this. You can request for a year in the skeleton, and that particular calendar or locale should have a year, plus a cycle year name. So therefore the PR would have to be changed. First, you can't request it. Second, in formatToParts, you have to have a separate field to report the name of the relative year. So, in addition to relative year in the output type, you need another one, maybe called yearName, to denote that. @@ -138,7 +138,7 @@ SL: I'll send an email to the internal CLDR mailing list. [Proposal](https://github.com/zbraniecki/proposal-intl-locale) Last month: André Bargull (@anba) also has an implementation that is on the review queue for mozilla. -https://bugzilla.mozilla.org/show_bug.cgi?id=1433303 +https://bugzilla.mozilla.org/show_bug.cgi?id=1433303 SC: Is there someone we should ping for the bug? @@ -150,8 +150,8 @@ DE: It looks like there is a reasonable amount of activity. I'll post this on I Last month: Firefox needs to upgrade to ICU 64. -FT: Also need https://github.com/tc39/proposal-intl-relative-time/pull/108 -(v8 bug https://bugs.chromium.org/p/v8/issues/detail?id=9190 / cl https://chromium-review.googlesource.com/c/v8/v8/+/1590442) +FT: Also need https://github.com/tc39/proposal-intl-relative-time/pull/108 +(v8 bug https://bugs.chromium.org/p/v8/issues/detail?id=9190 / cl https://chromium-review.googlesource.com/c/v8/v8/+/1590442) FT: This is similar for the date and number format in ECMA 402. So it should also go here. We should enable the numbering system to be allowed in the options. @@ -324,7 +324,7 @@ DE: yes DE: We could also add more categories now in the first pass, if we know what those categories would be. -SL: A very common use case is, None vs number vs letter as to whether numerical words are counted as part of the word count. So in some cases, a run of numbers is considered a non-word. Versus idiographic characters, which may or may not be in numbers. (example: http://icu-project.org/apiref/icu4c/ubrk_8h.html#af9836cc79482f82ac12eefb1f70b14b9 ) - ICU rules: https://github.com/unicode-org/icu/blob/master/icu4c/source/data/brkitr/rules/word.txt#L159 +SL: A very common use case is, None vs number vs letter as to whether numerical words are counted as part of the word count. So in some cases, a run of numbers is considered a non-word. Versus idiographic characters, which may or may not be in numbers. (example: http://icu-project.org/apiref/icu4c/ubrk_8h.html#af9836cc79482f82ac12eefb1f70b14b9 ) - ICU rules: https://github.com/unicode-org/icu/blob/HEAD/icu4c/source/data/brkitr/rules/word.txt#L159 RG: How do current software implementations deal with this? Where you have different types on the same segment? @@ -370,7 +370,7 @@ Can we come up with semantics that are reasonable for all cases, including empty RG: A use case would be helpful to make decisions here. -SL: A diagram of state transitions would be helpful. There is an ICU data-driven test family. https://github.com/unicode-org/icu/blob/master/icu4c/source/test/testdata/rbbitst.txt +SL: A diagram of state transitions would be helpful. There is an ICU data-driven test family. https://github.com/unicode-org/icu/blob/HEAD/icu4c/source/test/testdata/rbbitst.txt SC: For readability, I would like an explicit approach as suggested by point 2. It would make the most sense for `following`/`preceding` to return either the receiver or undefined. diff --git a/meetings/notes-2019-10-24.md b/meetings/notes-2019-10-24.md index fc22bafd..1c775c81 100644 --- a/meetings/notes-2019-10-24.md +++ b/meetings/notes-2019-10-24.md @@ -10,7 +10,7 @@ October 24 Attendees: - Myles C. Maxfield - Apple (MCM) - Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison - Shu-yu Guo - Google (SYG) -- Steven Loomis - IBM (SLS → SRL) +- Steven Loomis - IBM (SLS → SRL) - Zibi Braniecki - Mozilla (ZB) @@ -18,7 +18,7 @@ October 24 Attendees: [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -[Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +[Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) ## Next Meeting @@ -74,8 +74,8 @@ RCA: We've had about 1 meeting each week. We are at 14 meetings now! I want yo ### Normative: Add calendar and numberingSystem options (#175) - [PR](https://github.com/tc39/ecma402/pull/175) -- Anba found problems; FYT is fixing them in V8. -- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) +- Anba found problems; FYT is fixing them in V8. +- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) JSW: I started looking at how to implement this in SpiderMonkey but need to look deeper into exactly how to direct ICU to apply these options.. @@ -84,7 +84,7 @@ JSW: I started looking at how to implement this in SpiderMonkey but need to look - [PR](https://github.com/tc39/ecma402/pull/351) - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e - LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table." -- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) +- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) LEO: I tried to resolve the conflict, but I would like to get that from Daniel, the author. @@ -147,7 +147,7 @@ Do we have MDN for these? - https://github.com/tc39/ecma402/pull/341 - RCA: It's documented recently and has an MDN page. - https://github.com/tc39/ecma402/pull/333 - - RCA no Documentation related with this issue + - RCA no Documentation related with this issue - Last month: - LEO: Tests are covered. @@ -163,7 +163,7 @@ Do we have MDN for these? - [Firefox Bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1433306): likely to be reviewed/landed later this week - [Test262 Tests](https://test262.report/features/Intl.ListFormat?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ListFormat): Good. -- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed - Main blocker: bug with `type: 'disjunction'` in Spanish, [#45](https://github.com/tc39/proposal-intl-list-format/issues/45) - Last month: JSW: Blocked by https://unicode-org.atlassian.net/browse/ICU-12863 @@ -178,7 +178,7 @@ Action: Shane to review JSW's patch. - [Firefox Bug 2](https://bugzilla.mozilla.org/show_bug.cgi?id=1522070) - [Test262 Tests](https://test262.report/features/Intl.Locale?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Locale) Live Examples - OK -- [MDN Bug]: https://github.com/tc39/proposal-intl-locale/issues/70 Closed +- [MDN Bug]: https://github.com/tc39/proposal-intl-locale/issues/70 Closed - Previously: André Bargull (@anba) also has an implementation that is on the review queue for mozilla. - Last month: Intl.Locale landed in SpiderMonkey! The feature is enabled, but only if you flip a preference. @@ -195,7 +195,7 @@ JSW: I don't want to ship with the way it currently is. FYT: The PR is already merged. It says the canonicalization is based on UTS 35. That has the alias mapping. But current ICU doesn't implement that. https://tc39.es/ecma402/#sec-canonicalizelanguagetag -“A conforming implementation shall take the steps specified in the “BCP 47 Language Tag to Unicode BCP 47 Locale Identifier” algorithm, from Unicode Technical Standard #35 LDML § 3.3.1 BCP 47 Language Tag Conversion.” +“A conforming implementation shall take the steps specified in the “BCP 47 Language Tag to Unicode BCP 47 Locale Identifier” algorithm, from Unicode Technical Standard #35 LDML § 3.3.1 BCP 47 Language Tag Conversion.” The published one - https://ecma-international.org/ecma-402/#sec-canonicalizelanguagetag FYT: To be clear, this issue is in 402 already. This issue should not affect the status of Intl.Locale. @@ -309,7 +309,7 @@ ZB: Could we say, some data is pre-loaded by default, and then in an option bag, SFC: It would be good to load all data in the constructor, because we want the terminal format method to not be async. -RCA: I was thinking something like : +RCA: I was thinking something like : ```js const fmt = new Intl.DateTimeFormat( … , { @@ -320,7 +320,7 @@ fmt.formatRange(start, end); LEO: `await Intl.load();` then classical API follows up -ZB: (proposal): +ZB: (proposal): ``` let dtf = new Intl.DateTimeFormat(undefined, { data: [“range”] }); dtf.formatRange(); // works diff --git a/meetings/notes-2019-11-14.md b/meetings/notes-2019-11-14.md index 37326dda..ab97bb85 100644 --- a/meetings/notes-2019-11-14.md +++ b/meetings/notes-2019-11-14.md @@ -20,7 +20,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) ## Next Meeting @@ -41,8 +41,8 @@ RCA: Sent an invite for the first meeting on 25th of November. I plan to share ### Normative: Add calendar and numberingSystem options (#175) - [PR](https://github.com/tc39/ecma402/pull/175) -- Anba found problems; FYT is fixing fixed them in V8. -- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) +- Anba found problems; FYT is fixing fixed them in V8. +- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) - Last month: JSW is looking into SpiderMonkey. JSW: Anba finished the patch I had sent out. Only in nightly. @@ -58,7 +58,7 @@ SFC: DE will delegate MDN and tests. - [PR](https://github.com/tc39/ecma402/pull/351) - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e - LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table." -- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) +- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) - Last month: LEO: I tried to resolve the conflict, but I would like to get that from Daniel, the author. LEO: Yeah, resolving the conflict requires editing the table/paragraph. @@ -111,7 +111,7 @@ SRL: It seems that v8/Chrome calendar support is buggy, making it hard to reprod - FYT addressed Anba's feedback - SpiderMonkey shipped (in nightly builds) - https://bugzilla.mozilla.org/show_bug.cgi?id=1568134 - Last month: FYT: I need to double-check with Anba if there are any other issues he has. -- Last month: there is an ICU bug we need to fix. Both ICU-20738 and ICU-20739 are fixed +- Last month: there is an ICU bug we need to fix. Both ICU-20738 and ICU-20739 are fixed SFC: Mihai has written a bug fix that forces seconds to be included when fractional seconds are requested. It fixes two issues. @@ -166,7 +166,7 @@ DE: Agreed. - [Firefox Bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1433306): likely to be reviewed/landed later this week - [Test262 Tests](https://test262.report/features/Intl.ListFormat?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ListFormat): Good. -- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed - Main blocker: bug with `type: 'disjunction'` in Spanish, [#45](https://github.com/tc39/proposal-intl-list-format/issues/45) - Last month: JSW: Blocked by https://unicode-org.atlassian.net/browse/ICU-12863 @@ -208,7 +208,7 @@ SFC: TO clarify, several Googlers have been working with our LPM to get informat FYT: Should this be a blocker if other languages have the same problem? -SFC: We should have good support for top-tier languages such as Spanish. +SFC: We should have good support for top-tier languages such as Spanish. FYT: Can we support this linguistically if we turn everything to “narrow”? @@ -249,7 +249,7 @@ Resolution: We will eventually come back to this issue. - [Firefox Bug 2](https://bugzilla.mozilla.org/show_bug.cgi?id=1522070) - [Test262 Tests](https://test262.report/features/Intl.Locale?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Locale) Live Examples - OK -- [MDN Bug](https://github.com/tc39/proposal-intl-locale/issues/70) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-locale/issues/70) Closed - Previously: André Bargull (@anba) also has an implementation that is on the review queue for mozilla. - Last month: Intl.Locale landed in SpiderMonkey! The feature is enabled, but only if you flip a preference. - Last month: RCA: JVA Merged live examples for MDN @@ -261,7 +261,7 @@ ZB: The updates are just editorial. DE: I’m a little confused. It seems that there are some concerns about the implementation from JSW. -JSW: Concerned that in these patches, the behavior is different from +JSW: Concerned that in these patches, the behavior is different from Canonicalized LangTag would not do the same as … THere may (or may not) be an issue, but now JSW cannot find the problem that Andre Bargull had pointed out, and which he had earlier thought was . DE: There may be a simple solution, but Andre is usually right. @@ -343,7 +343,7 @@ SFC: This is exciting that it’s ready to move forward. Thanks! - [SpiderMonkey](https://bugzilla.mozilla.org/show_bug.cgi?id=1566410) - Last month: RCA: We only have static examples , and missing documentation for Sign Display [MDN] -RCA: No updates related about the Sign Display Documentation on MDN +RCA: No updates related about the Sign Display Documentation on MDN SFC: I have a PR to fix several of the open issues. Still a few more. @@ -376,7 +376,7 @@ SFC: Wait to February vs. earlier? DE: It's good enough that if this is on a path to stable, we can move to Stage 4. -CLA: Slide deck - who/when to update? +CLA: Slide deck - who/when to update? SFC: will follow up with CLA offline, but is OK with CLA presenting, Exciting that this second proposal will also go to Stage 4. December meeting will be week after TC39 (SF meeting) @@ -399,7 +399,7 @@ RCA: There is no PR started the PR for Compat-data SFC: Are the blockers big problems or smaller concerns? There are also items on the Issues list. Ready for Stage 4? -ZB: Not in favor of December - action item is to consider for Stage 4 in Feb, but cannot commit. +ZB: Not in favor of December - action item is to consider for Stage 4 in Feb, but cannot commit. SFC: We should propose to stage 4 when we are comfortable. @@ -435,7 +435,7 @@ FBN: There are a few ICU issues open. FYT took over some of them. One of them DE: What types of issues are they? -FBN: Most of them are either for instance ICU not respecting taking interval formats or the formats don’t have proper support for date style or time style. +FBN: Most of them are either for instance ICU not respecting taking interval formats or the formats don’t have proper support for date style or time style. There is now an inconsistency in output. SFC: We hope that this is just an ICU change. @@ -500,7 +500,7 @@ RGN: It will be in the PR tomorrow, and will be merged soon thereafter. SFC: It will be good to present S3 proposal to TC39 if possible rather than just discussing it. -RGN: At last meeting there was a discussion, so the group has been briefed. +RGN: At last meeting there was a discussion, so the group has been briefed. ### Temporal (Stage 2) @@ -596,7 +596,7 @@ SFC: let’s take this discussion offline. LEO: Don’t need to shift the whole API to accommodate. SFC: There are people here who know a lot about Unicode properties. - + ### Should accounting format have a special field? - [Issue](https://github.com/tc39/proposal-unified-intl-numberformat/issues/68) @@ -622,7 +622,7 @@ ZB: Where does this fit? SFC: We need a champion to work on these issues. -ZB: this is important for video/audio/media players. +ZB: this is important for video/audio/media players. DE: What would be needed in the API? diff --git a/meetings/notes-2019-12-12.md b/meetings/notes-2019-12-12.md index 4a23221c..73ba2d82 100644 --- a/meetings/notes-2019-12-12.md +++ b/meetings/notes-2019-12-12.md @@ -15,7 +15,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -61,10 +61,10 @@ FBN: The only data we need is three or for patterns for one skeleton. We already SFC: Code size, the estimate is from codesize for ICU. 48KiB of code. The rest of datetime is (explains numbers are in the issue). The size is not so bad. But we need to consider memory consumption. We need to set up these data structures ahead of time. This might be a stage 3 concern. FBN: How will implementers deal with memory consumption? Based on your numbers, it seems fine not to optimize the data by doing something fancy in the constructor. I think it’s best to keep things as they are -- load data at the beginning. -Many of the options involve things like using a parameter/option, which feels pretty confusing. Maybe it would be better to have two different formatters for fprmatRange and formatDateTime. +Many of the options involve things like using a parameter/option, which feels pretty confusing. Maybe it would be better to have two different formatters for fprmatRange and formatDateTime. I would like to hear others opinions on that. -JSW: Those size increases don’t look bad to me. DisplayNames was starting to get border-line. These numbers are also pre-compression. +JSW: Those size increases don’t look bad to me. DisplayNames was starting to get border-line. These numbers are also pre-compression. SFC: What about memory consumption? Should we create the formatRange data structures even when programmer probably won’t want to use it? @@ -78,7 +78,7 @@ SFC: Shu (SYG) gave a presentation at TC39 advocating optimization and implement SFC: When chrome parses the file, if they really wanted to optimize, they could do their own static analysis. They can get that from the javascript ifile. -FYT: No… +FYT: No… SFC: In principle you could. @@ -86,7 +86,7 @@ JSW: the payoff for doing that analysis is not worth is almost always. SFC: Understood. -RCA: Can we do a static analysis or benchmark to see the solutions between lazy loading/loading on construction? +RCA: Can we do a static analysis or benchmark to see the solutions between lazy loading/loading on construction? SFC: Yeah we should avoid premature optimization. Does anyone thing we should leave the issue open? Or expect not to solve this in spec? @@ -118,13 +118,13 @@ FYT: Date and time styles are a kind of shortcut to specific a number of things ZB: We should consider that it should be shown the same way in all cases. -FYT: Pattern vs. skeleton is not of interest to the user. 3 levels of abstraction: +FYT: Pattern vs. skeleton is not of interest to the user. 3 levels of abstraction: ZB: Format, the localization specifies how a value looks for formatted values. We should have the same ability for date ranges. SFC: Overwhelming sense from others is that skeletons are enough. (SFC does not necessarily agree with this sentiment.) -FYT: It needs to be consistent. +FYT: It needs to be consistent. SFC: There’s no well defined algorithm for going from a pattern to the skeleton and back.. @@ -144,7 +144,7 @@ FYT: Type error is thrown when the format is requested, not at constructor time. FYT: It’s not really a type error. -SFC: Is it really confusing? Type error shows a problem somewhere in the +SFC: Is it really confusing? Type error shows a problem somewhere in the CLA: Example of throwing type error in math functions, e.g., for some specific values that are not really type problems. It’s a type error because it’s an argument sent to the function. @@ -181,8 +181,8 @@ Conclusion: Do not throw an exception. FBN to work with FYT to determine whethe ### Normative: Add calendar and numberingSystem options (#175) - [PR](https://github.com/tc39/ecma402/pull/175) -- Anba found problems; FYT fixed them in V8. -- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) +- Anba found problems; FYT fixed them in V8. +- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) - Last month: JSW: Anba finished the patch I had sent out. Only in nightly. - Last month: DE will delegate MDN and tests. @@ -195,7 +195,7 @@ CLA: MDN is updated (https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScrip - [PR](https://github.com/tc39/ecma402/pull/351) - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e - LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table." -- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) +- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) - Last month: LEO: I tried to resolve the conflict in #351, but I would like to get that from Daniel, the author. - Last month: I'll follow up offline. @@ -239,7 +239,7 @@ SFC: The issue with this PR is that spidermonkey is waiting for ICU patches: 740 - [PR](https://github.com/tc39/ecma402/pull/392) -CLA: This PR is merged ? do we need to update this PR , I can do it. +CLA: This PR is merged ? do we need to update this PR , I can do it. SFC: We need to have one of the editors to review it and we can merge it @@ -247,11 +247,11 @@ LHO: There is a Normative PR that needs to be merged before we merge this to ECM SFC: What is the web reality? Are browsers are doing it correctly? Deep inside partition number pattern, so they must be doing it correctly. This is part of theoretical spec text because everyone just uses ICU which already implements this correctly. This is essentially a “web reality” PR. Do we need tests? -CLA : We have tests for that ? if we have tests and they don’t break we can consider as A “web reality” ? +CLA : We have tests for that ? if we have tests and they don’t break we can consider as A “web reality” ? SFC: I don't think we need a test then. -LHO: What do I do then? I’m finding a lot of small bugs in the text when making a poly fill. +LHO: What do I do then? I’m finding a lot of small bugs in the text when making a poly fill. SFC: We need consensus to approve this PR , do we have “consensus” ? Normally we need TC39 approval for PRs but this seems like it’s so uncontroversial we can approve it for merge. @@ -278,7 +278,7 @@ CLA: We need to rebase the PR https://github.com/tc39/ecma402/pull/391 and wait - [Firefox Bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1433306): likely to be reviewed/landed later this week - [Test262 Tests](https://test262.report/features/Intl.ListFormat?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ListFormat): Good. -- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed - Main blocker: bug with `type: 'disjunction'` in Spanish, [#45](https://github.com/tc39/proposal-intl-list-format/issues/45) - Last month: JSW: Blocked by https://unicode-org.atlassian.net/browse/ICU-12863 @@ -297,7 +297,7 @@ LHO: no it’s uncontroversial. Ms2ger took a look. The polyfill implementation - [Firefox Bug 2](https://bugzilla.mozilla.org/show_bug.cgi?id=1522070) - [Test262 Tests](https://test262.report/features/Intl.Locale?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Locale) Live Examples - OK -- [MDN Bug](https://github.com/tc39/proposal-intl-locale/issues/70) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-locale/issues/70) Closed - Previously: André Bargull (@anba) also has an implementation that is on the review queue for mozilla. - Last month: Intl.Locale landed in SpiderMonkey! The feature is enabled, but only if you flip a preference. - Last month: RCA: JVA Merged live examples for MDN @@ -311,14 +311,14 @@ JSW: the last remaining issues: I submitted a PR for the issue of getting rid of SFC: Is this an issue that we need to fix in ECMA402 side, Unicode side or where? Could you remind me? JSW: We can fix the problem with canonicalized language tag in the proposal. V8 doesn’t support duplicate attributes, which is an implementation issue for them. (See https://github.com/tc39/proposal-intl-locale/pull/83 for that.) - -CLA: If this needs to be solve on SM side ? + +CLA: If this needs to be solve on SM side ? JSW: I won’t say right now that what we have implemented right now is what spec should be. -SFC: You are proposing to update the CanonicalizedLanguageTag function ? +SFC: You are proposing to update the CanonicalizedLanguageTag function ? -JSW: The proposal is an update to the spec +JSW: The proposal is an update to the spec SFC: After this get reviewed and Valerie reviews, Zibi needs to “merge it ”. If we can get connect with zibbi to merge the frist PR, we then link to second PR, then anba reviews it and Zibi merge, we are able to ask for Stage 4 on February? Jeff needs to write the new one and Zibi merge the second one. @@ -358,7 +358,7 @@ JSW: I’ll wait until the ICU issue is resolved, but I don’t think that there SFC: Waiting on ICU issues or spec issues.. According to the wiki, v8 has shipped. -JSW: Let me look up the details on that. +JSW: Let me look up the details on that. ### Intl.DateFormat.prototype.formatRange (Stage 3) @@ -372,7 +372,7 @@ JSW: Let me look up the details on that. - Previously: FBN: Currently this is blocked by 4 issues that were filed against ICU. My intent is to start working on the issues in the next 1-2 months. It means though that it is released in the Spring release of ICU. - Last month: RCA - Interactive examples for formatRange already landed, waiting for formatRangeToParts to be merged[MDN] -SFC: Need FBN in order to discuss this. +SFC: Need FBN in order to discuss this. SFC: Out of time, so made quick mention on dateStyle/TimeSTyle #2 and #15. @@ -388,7 +388,7 @@ SFC: Proposes that browsers ship display names but don’t ship type Month becau FYT: Doesn’t agree. Currently DisplayName proposal has 9 different types that have nothing to do with date/time. Five other types are Date/time related. Suggests to scale back the proposal to address the 5 date/time later in 2020. -SFC: would be OK. There are some “thumbs up”, and no opposition. +SFC: would be OK. There are some “thumbs up”, and no opposition. ZB: Align with Temporal. @@ -409,7 +409,7 @@ Pending on RGN. - [Proposal](https://github.com/tc39/proposal-temporal) - Preliminary spec text checked in; waiting for additional updates from Ms2ger -SFC: Exciting updates! The significant update is that we are making progress on first class calendar support. We met Phillip and other people involved and spent 10 hours to discuss about calendar support on Temporal. String display and map need to be in sync, without it they would not be in sync. +SFC: Exciting updates! The significant update is that we are making progress on first class calendar support. We met Phillip and other people involved and spent 10 hours to discuss about calendar support on Temporal. String display and map need to be in sync, without it they would not be in sync. ### Default Calendar @@ -423,7 +423,7 @@ CLA: On the front end, I think the problem with 4 is that browser side will prod SFC: I like 2 and 3 the best. -RCA: I agree with CLA on the 4th issue. I have been experiencing issues related to timezones and how we run things on client side. The 4th is essentially no-go. I will review more closely the draft and provide feedback on it. +RCA: I agree with CLA on the 4th issue. I have been experiencing issues related to timezones and how we run things on client side. The 4th is essentially no-go. I will review more closely the draft and provide feedback on it. LHO: I would say number 2 is the best. For headless like node, every request has different intl preference, being self contained in the API helps a lot. diff --git a/meetings/notes-2020-01-09.md b/meetings/notes-2020-01-09.md index 42e599fa..d8ff67fd 100644 --- a/meetings/notes-2020-01-09.md +++ b/meetings/notes-2020-01-09.md @@ -18,7 +18,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -54,7 +54,7 @@ SRL: I could see having a recommended list for a guide for implementations, but DE: We have required numbering systems. It does seem like a fatal error if someone counts on a particular locale to be present but it is not. -SRL: It seems similar, I think ECMA-402 shouldn’t have their own repository of Locale Data +SRL: It seems similar, I think ECMA-402 shouldn’t have their own repository of Locale Data SFC: If we had a minimum supported list, like we do for numbering systems, then a programmer can reasonable expected to be able to do math in the hewbrew calendar and have an expectation that this will work in all ECMA-402 implementations. We shouldn’t have a situation where calendar is supported for formatting but not temporal math. I think this makes it the most clear for programmers and that is a goal. We should consider if we want a minimum list or no list at all. @@ -74,7 +74,7 @@ DE: Part of the Temporal project is to provide an experimental polyfill. Are you LHO: It is a combination of both. The data size that the polyfill would have to ship with and the logic. -SFC: What if we just did “any calendar that is supported for formating must be supported for math”? We could add a preferred list later. The web reality is that all the browsers will probably support the same core calendars without us having to require it. Places where gregorian is not the preferred calendar are 4 regions. +SFC: What if we just did “any calendar that is supported for formating must be supported for math”? We could add a preferred list later. The web reality is that all the browsers will probably support the same core calendars without us having to require it. Places where gregorian is not the preferred calendar are 4 regions. SRL: Should an implementation have to support a set to be conformant? @@ -88,7 +88,7 @@ SRL: Should this a CLDR question to get a linguistic input on these strange comb SFC: Is there a way to get data for theses is a fourth option. Other options are: 1. garbage in garbage out, 2. throw an exception for things that don’t make sense (programmatically, when you have two units of time that are not continuous, like missing month), 3. Implicitly fill in the gaps. So if year and day, then add month. Give you the month for free, which is a 402 change. -SRL: This is trying to figure out a skeleton resolution. +SRL: This is trying to figure out a skeleton resolution. SFC: Going from options bag to the skeleton, so pre skeleton. @@ -116,7 +116,7 @@ RCA: Having this normalization will mean that developers will rely on it. In som LH: Within the build tooling pipeline, we have a linter to prevent weird options. And we have not request to provide options for these weird combinations to be filled in automatically (#3)/ -LEO: Number 1 doesn’t give us any extra work. +LEO: Number 1 doesn’t give us any extra work. SFC: The basic format matcher does allow #3. Implementations can fill in the month. I think it would be helpful to develop a bit more clarify about these cases in the spec, and make them not implementation dependent. If this should be implementation depenedent, then lets closet his issue. @@ -143,7 +143,7 @@ SFC: The case where we have datestyle/timestyle AND other options. What should t DE: I would be cool with having an exception here, because I am concerned about this misuse. -ZB: I think it’s fine to throw here, but, I think we are always trying to make the best case out of the input we are provided. We can change the output over time as we improve our ability to read the bits. I think it’s fine that we are improving. +ZB: I think it’s fine to throw here, but, I think we are always trying to make the best case out of the input we are provided. We can change the output over time as we improve our ability to read the bits. I think it’s fine that we are improving. SFC: I agree. Even if we didn’t throw, it would still be web compatible if we changed the output. @@ -158,7 +158,7 @@ SFC: We can’t throw an error on previous case because it is an old API and it ZB: There are 2 ways to display your date. The old way is you give the fields, and we attempt to find the best skeleton. If you have a combo that doesn't make sense, like year+hour, the job of the engine is to find the best skeleton that makes sense - the method of selecting the best skeleton is specified. The The new method is, I just want to tell you the style that I want, and just select the best style. The style is per-locale, and the spec define the expectation that the implementation provide skeletons for the styles. The new challenge is what to do when you combine old and new, and this is unspecified. That’s why suggest an exception. -SFC: There are other cases where we throw exceptions for weird inputs. There are cases were I was pushing back on exceptions, but we added some. I think this is a case where an exception is reasonable to have, but also changing the output over time seems javascripty. Maybe since this is stage 3 we should continue with the status quo. +SFC: There are other cases where we throw exceptions for weird inputs. There are cases were I was pushing back on exceptions, but we added some. I think this is a case where an exception is reasonable to have, but also changing the output over time seems javascripty. Maybe since this is stage 3 we should continue with the status quo. ZB: I would advocate for RangeError. It helps us clarify that this is an undefined behavior. @@ -178,20 +178,20 @@ SFC: Which should we overload? DE: I assume datetimeformat. What are the implications? -SFC: It might make sense to do number format because they are units.. DurationFormat adds a “numeric form” (from ICU) like hour:minute:second. ICU is in the MeasureFormat class, which is like numberformat. +SFC: It might make sense to do number format because they are units.. DurationFormat adds a “numeric form” (from ICU) like hour:minute:second. ICU is in the MeasureFormat class, which is like numberformat. -YMD: The people are going to give the time in days or seconds only. What about RelativeTimeFormat. I think it should be added to it’s on class or datetimeformat. +YMD: The people are going to give the time in days or seconds only. What about RelativeTimeFormat. I think it should be added to it’s on class or datetimeformat. -RCA: I think it is more in datetime format than number format, as a developer, I would look there first. +RCA: I think it is more in datetime format than number format, as a developer, I would look there first. LB: It connects more to datetime format to me. I prefer the new class to be more clear about the feature. -SFC: For overlap of options. FormatRange with DateTime Format and unit formatting in number format because of overlap in options. There are a lot of option sto datetimeformat that are not relevant to the durationformat. On the numberformat side, there are lot of options that are not revelent to durations. -LB: From what you just said, I think from the perspective of learnability, having a different DurationFormat will help with learnability and explorability. +SFC: For overlap of options. FormatRange with DateTime Format and unit formatting in number format because of overlap in options. There are a lot of option sto datetimeformat that are not relevant to the durationformat. On the numberformat side, there are lot of options that are not revelent to durations. +LB: From what you just said, I think from the perspective of learnability, having a different DurationFormat will help with learnability and explorability. -RCA: I don’t think we should position durationformat based on intrinsic reasons. +RCA: I don’t think we should position durationformat based on intrinsic reasons. -SFC: I don’t think there will be a lot of code overlap between DurationFormat and DateTimeFormat or NumberFormat. +SFC: I don’t think there will be a lot of code overlap between DurationFormat and DateTimeFormat or NumberFormat. ZB: From my perspective, DurationFormat is closest to RelativeTimeFormat. It is a compounded NumberFormat which we don’t have yet. I would say DurationFormat as it’s own class, easier to deprecate once we incorporate into NumberFormat. @@ -214,8 +214,8 @@ Decision: Stage 1 consensus. YMD will compile pros and cons of options and bring ### Normative: Add calendar and numberingSystem options (#175) - [PR](https://github.com/tc39/ecma402/pull/175) -- Anba found problems; FYT fixed them in V8. -- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) +- Anba found problems; FYT fixed them in V8. +- FYT flip the bit to ship it in Chrome m80. (with #351 and #349) - Last month: JSW: Anba finished the patch I had sent out. Only in nightly. - Last month: CLA: MDN is updated. We need to update the status wiki. Test262 required. @@ -229,7 +229,7 @@ RCA: I will add a MDN bug and link. - [PR](https://github.com/tc39/ecma402/pull/351) - FYT wrote tests in https://github.com/tc39/test262/commit/79591ae6c8f13f5c558576ad58846d80f33d0f0e - LEO wrote: "I'd like to defer this to @littledan so you can pick the best description for relatedYear and yearName in their respective table." -- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) +- FYT flip the bit to ship it in Chrome m80 (w/ #175 and #349) - Previously: LEO: I tried to resolve the conflict in #351, but I would like to get that from Daniel, the author. RCA: I will add a MDN bug and link. @@ -295,7 +295,7 @@ CLA: I’ll rebase and update the PR - [Firefox Bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1433306): likely to be reviewed/landed later this week - [Test262 Tests](https://test262.report/features/Intl.ListFormat?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ListFormat): Good. -- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed - Main blocker: bug with `type: 'disjunction'` in Spanish, [#45](https://github.com/tc39/proposal-intl-list-format/issues/45) - Last month: YMD is working on the fix in ICU 67. diff --git a/meetings/notes-2020-01-30.md b/meetings/notes-2020-01-30.md index 954b4b01..24f8a26d 100644 --- a/meetings/notes-2020-01-30.md +++ b/meetings/notes-2020-01-30.md @@ -18,7 +18,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -101,7 +101,7 @@ SFC: Merged last month. Done. Is there anything else that needs to be done on ### Normative: Permit relatedYear and yearName in output (#351) -SFC: This was merged but there was outstanding editorial issues, and tests, and MDN. +SFC: This was merged but there was outstanding editorial issues, and tests, and MDN. DE: For MDN we're making good progress - Brian did a bunch of stuff, we have been tweaking. @@ -184,7 +184,7 @@ DE: Last time I looked it seemed complicated. It wasn't clear how much spec alg - [Firefox Bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1433306): likely to be reviewed/landed later this week - [Test262 Tests](https://test262.report/features/Intl.ListFormat?date=2019-07-10): Good. - [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ListFormat): Good. -- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed +- [MDN Bug](https://github.com/tc39/proposal-intl-list-format/issues/37) Closed - Main blocker: bug with `type: 'disjunction'` in Spanish, [#45](https://github.com/tc39/proposal-intl-list-format/issues/45) - Last month: YMD is working on the fix in ICU 67. @@ -231,7 +231,7 @@ ZB: JSW says: seems likely we can. SFC: Agreement from CLDR to make datestyle/timestyle map to skeletons. Most locals would use the skeleton unless a locale wanted to override it. Ticket: https://unicode-org.atlassian.net/browse/CLDR-13425 -JSW: We probably need to update ICU. +JSW: We probably need to update ICU. ABL: There's a patch but it's not checked in yet. There were some ICU issues that we are blocked by. @@ -279,7 +279,7 @@ ZB: We did an initial look at the API today. I don't feel very comfortable abou DE: About the size. This is something that's been under discussion for years. How are you going to evaluate it from here? -ZB: We raised this a couple years ago. We don't want to block on this indefinitely. We want to evaluate how it works in a low-data environment and see potential size increase with our products team. I just feel that landing an API (missed). +ZB: We raised this a couple years ago. We don't want to block on this indefinitely. We want to evaluate how it works in a low-data environment and see potential size increase with our products team. I just feel that landing an API (missed). DE: Where should we go from here -- specification allows for support for fewer locales. I wonder whether you can implement this based on whatever other segmentation libraries you have in Firefox today. @@ -288,7 +288,7 @@ ZB: That's a question we asked, but we need more time to evaluate that. RGN: The changes that are landing are independent of the data. The algorithms are the same. Any concerns about the data backing the algorithm would land in the Stage 3 category. DE: I would like to give them time to evaluate this before Stage 3. It is a stage 3 (implementation concern) but identified for a while. - + MGR: It sounds like an implementation concern, but it's also a spec concern. The issue is that if people start relying on the behavior to be a certain way, we essentially de-facto mandate that this thing use ICU. So we should be very careful. That's why I consider this a spec concern. RGN: That seems to be an indefinite concern. @@ -309,7 +309,7 @@ SFC: Intl.Segmenter is an old proposal. At one point it was at Stage 3. At Goo RGN: I agree, though I think it's reasonable to wait a month for Stage 3 advancement since we're otherwise in good shape. -DE: The random access part is a Stage 2 concern. I added some links to the previous discussions. https://github.com/tc39/proposal-intl-segmenter/issues/9 +DE: The random access part is a Stage 2 concern. I added some links to the previous discussions. https://github.com/tc39/proposal-intl-segmenter/issues/9 ### Temporal (Stage 2) diff --git a/meetings/notes-2020-02-27.md b/meetings/notes-2020-02-27.md index 90d41b09..ee19503a 100644 --- a/meetings/notes-2020-02-27.md +++ b/meetings/notes-2020-02-27.md @@ -16,7 +16,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -60,7 +60,7 @@ RCA: We had our fifth meeting on Monday. We're starting creating docs for Messa SFC: message format sometimes are even bigger than ECMA402 meetings. -RCA: You can follow our meeting notes [here](https://github.com/unicode-org/message-format-wg/tree/master/meetings) +RCA: You can follow our meeting notes [here](https://github.com/unicode-org/message-format-wg/tree/master/meetings) ## Discussions @@ -86,7 +86,7 @@ SFC: Can we have extra info by adding navigator.locales? ZB: If we got to it, we could use Intl.Locale to be able to parse those strings. This would then deprecate “navigator.languages”. JSW: It feels that getting some of this info by constructing a locale and calling resolvedOptions on it seems convoluted. CalendarInfo seems like a simpler and more straightforward approach for people to apply in their own code. That said, exposing things like first day of week in resolvedOptions makes sense in its own right. - + SFC: Do you mean getters on Intl.Locale? JSW: Yes. @@ -109,7 +109,7 @@ KP: About lying about user options, I think that's an option in Edgium. ZB: We are integrating a lot of Tor browser features, and we have fingerprint prevention (mask Accepted Languages, mask JS Default Locale etc.). -JSW: Browsers can decide to put nothing in Accept-Languages(?) or navigator.locales, then -- and then no one’s actually any better off, even if the spec purports to allow it. +JSW: Browsers can decide to put nothing in Accept-Languages(?) or navigator.locales, then -- and then no one’s actually any better off, even if the spec purports to allow it. FYT: Are we mixing two levels of issues? For example, first day of week for a particular locale. Second, the user preference. @@ -179,7 +179,7 @@ SFC: We could Accept-Locales: as a new HTTP header KP: Unicode only controls the `-u-` extension. So how do we want to encode user preferences? SFC: I don’t have a great sense if adding unicode extensions to navigator.languages would break the web. Who else have opinions on it. -Raise to W3C, other decision makers? If not possible to get consensus on syncing server/client info, then we should consider inventing our own preferences object available only on the client side. +Raise to W3C, other decision makers? If not possible to get consensus on syncing server/client info, then we should consider inventing our own preferences object available only on the client side. ZB: Would you want to have a separate user preference defined for every JS Intl object? @@ -225,7 +225,7 @@ FYT: This ability is in POSIX for more than 30 years. So it may have a good rea MIH: Personally I wouldn't use POSIX as a good i18n or l10n model. It's ancient history, bad models, ignore it. -SFC: It’s different between date formatting vs. collation - if there’s some knob that an extension doesn’t allow, then we could ask the Unicode people to add/change that setting option. It may be that having more information on the client side than the server has may be undesirable. +SFC: It’s different between date formatting vs. collation - if there’s some knob that an extension doesn’t allow, then we could ask the Unicode people to add/change that setting option. It may be that having more information on the client side than the server has may be undesirable. MIH: The one piece missing in the standard is the specific format of the dates. @@ -291,7 +291,7 @@ LEO: As an editor, I tend to agree with Allen Wirfs-Brock who asks if this is an SFC: Can we agree that Annex A is fingerprintable, add that information, and show an icon? -SFC: Is the audience for this tag developers who will use it for, e.g., GDPR? +SFC: Is the audience for this tag developers who will use it for, e.g., GDPR? #### Conclusion @@ -319,6 +319,6 @@ JSW: We can wait on for browsers, even if the TC39 version is out of date. ## PR Status Updates -SFC: Congrats to ZB for Locale and to SFC for NumberFormat Unified API +SFC: Congrats to ZB for Locale and to SFC for NumberFormat Unified API MCM: Is the public status page up to date? diff --git a/meetings/notes-2020-03-26.md b/meetings/notes-2020-03-26.md index 8d6f5b8e..a4a71004 100644 --- a/meetings/notes-2020-03-26.md +++ b/meetings/notes-2020-03-26.md @@ -17,7 +17,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -28,7 +28,7 @@ April 23, 10am PDT (5pm GMT) ## ECMA-402 2020 -LEO: I'm still looking for an editor for 2021. I'll announce it next week at TC39. I can't confirm if I'm able to continue the editorship. I have updates for the 2020 release cut, but I’m not sure if that’s the moment. Should I’ve +LEO: I'm still looking for an editor for 2021. I'll announce it next week at TC39. I can't confirm if I'm able to continue the editorship. I have updates for the 2020 release cut, but I’m not sure if that’s the moment. Should I’ve LEO: Should I go about it? @@ -138,7 +138,7 @@ https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange SFC: This is showing that Sathya is the champion, but I think FBN is championing this now. -SFC: I had a question, I just hope these issues get resolved. I’ll follow up with Felipe to make sure they have enough time to work on this. If they cannot any longer work on this, we’d choose someone else to champion this instead to finish this up and merge it. +SFC: I had a question, I just hope these issues get resolved. I’ll follow up with Felipe to make sure they have enough time to work on this. If they cannot any longer work on this, we’d choose someone else to champion this instead to finish this up and merge it. ### Intl.DisplayNames https://github.com/tc39/proposal-intl-displaynames @@ -227,11 +227,11 @@ FYT: let’s address this asynchronously. SFC: We need to add this into the wiki page. -https://github.com/younies/proposal-intl-duration-format +https://github.com/younies/proposal-intl-duration-format SFC: We need to do some update in the repo since it get updated from last TC39 meeting. -USA: There is some work to do that and this is important because it would help with Temporal proposal. +USA: There is some work to do that and this is important because it would help with Temporal proposal. SFC: the inference from last TC39 meeting is duplication of functionality and why is Duration special, which is definitely a fair point, but I think Duration as a top-level object mandates this. @@ -240,7 +240,7 @@ USA: Also, noting the fact that Temporal.Duration as a top level class is someth SFC: I’ll follow up with Younies privately. ## Discussions - + ### Issue Triaging https://github.com/tc39/ecma402/wiki/Issue-Triaging @@ -292,7 +292,7 @@ MG: I agree with Frank since that’s close to what happens in W3C. It’s okay SFC: I agree with everything that was said here, my POV is that I did all those things already, The only problem is that I didn’t have others weigh in, but apart from that, appropriate work has been put into it. That said, I’m not against further discussion on the issue tracker. Is this a more proactive approach than what we’re used to? Yes and no. A lot of features we released in V1 were useful for a limited set of users, but this moves us to a better place. The question isn’t that it is proactive or reactive, it is just that if it deserves to exist in the spec, and we can individually contest that. -MCM: Since it is not possible to have a model to say if the cost of maintaining an API based on its demand, I think we can have an alternative. (missed) +MCM: Since it is not possible to have a model to say if the cost of maintaining an API based on its demand, I think we can have an alternative. (missed) SFC: Are there any more meta-concerns about this? diff --git a/meetings/notes-2020-04-23.md b/meetings/notes-2020-04-23.md index 8b01bcb9..52e90860 100644 --- a/meetings/notes-2020-04-23.md +++ b/meetings/notes-2020-04-23.md @@ -18,7 +18,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -125,7 +125,7 @@ FYT: we should default to single value. Date range is also using single value cu JSW: it’s different about dates. Something is on or not on a date. It’s not the same with numbers. -FYT: there’s still rounding involved. It’s just that it is clearer. +FYT: there’s still rounding involved. It’s just that it is clearer. SFC: what jeff said was one of the reasons that I had advocated for approximately in ICU. That said, if users will want this feature, they would opt-in to it later, but single value is a good default. @@ -136,7 +136,7 @@ FYT: approximately isn’t a format option, it’s a different kind of format. T SFC: we could expose it separately, true. We can think of approximately as a new feature that could be exposed API-wide instead of isolating it here. -FYT: I agree. We should either deal with it separately or not deal with it at all. But it shouldn’t be stashed away here, it should be a higher level construct. +FYT: I agree. We should either deal with it separately or not deal with it at all. But it shouldn’t be stashed away here, it should be a higher level construct. SFC: default “auto on collapse” and exposing these options gradually when needed. @@ -157,7 +157,7 @@ ZB: I am concerned about that, because that makes ICU the standard. So that mean ZB: we have a few places in ICU where we have very complicated behavior and we haven’t specified it. -FYT: we should look at two camps: spec and no spec. +FYT: we should look at two camps: spec and no spec. DE: we have discussed this in detail in the past. @@ -237,7 +237,7 @@ FYT: I am concerned about it. If the user doesn't want 'auto', then they can spe SFC: OK, we can move true to mean 'auto', and the default is still true. -FYT: talking of resolved options, once we implement this proposal, it will never output true or false, it will just return this string. +FYT: talking of resolved options, once we implement this proposal, it will never output true or false, it will just return this string. SFC: If we don't want to make any observable changes to existing code, then it could still return true or false. But that's weird if you specify 'never'. @@ -386,7 +386,7 @@ FYT: my point is that we’re not adding a feature here, we’re just adding an SFC: Even if we add more APIs, it's still an education problem. -FYT: this isn’t a unique issue, it will increase the API surface and still not address the actual issue. +FYT: this isn’t a unique issue, it will increase the API surface and still not address the actual issue. ## Status Updates diff --git a/meetings/notes-2020-05-21.md b/meetings/notes-2020-05-21.md index ad729605..0656f73c 100644 --- a/meetings/notes-2020-05-21.md +++ b/meetings/notes-2020-05-21.md @@ -18,7 +18,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -84,7 +84,7 @@ FYT: How I read it is that “it shouldn’t have any variants”. SFC: Do we want to record consensus before Mark’s review? There’s important changes that we should get feedback about, and once that’s done, we can get a RSLGTM from this body. Sounds good? JSW: SGTM -### Update Table 4: Numbering systems with simple digit mappings #437 +### Update Table 4: Numbering systems with simple digit mappings #437 FYT: Basically, ECMA 402 has a section about numbering systems and the language in 402 says “these are the things in the standard but browsers are allowed to use extra systems”. This comes from CLDR, but some number systems are harder to use. I wrote a hacky script to try this out in browsers. Mozilla doesn't support everything I proposed, but I wonder why, because ICU makes it easy to support these. There are two numbering systems that were newly added in ICU, which Safari and V8 support. JSW: is it necessarily a good idea to mention all of these systems explicitly in the spec? Is it a big maintenance burden? diff --git a/meetings/notes-2020-06-11.md b/meetings/notes-2020-06-11.md index 79d84bf1..fb1a840e 100644 --- a/meetings/notes-2020-06-11.md +++ b/meetings/notes-2020-06-11.md @@ -23,7 +23,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -77,7 +77,7 @@ ZB: ??? SFC: This is a discussion I think we should have and I’m glad we are having now. This idea of smart unit is ?? and the shape of API is to be determined. There are benefits for both approaches (from ZB and YMD). An API needs to be aware of what’s the threshold for a given unit and this requires a lot of locale data and it is a large API surface. -ZB: ??? Impossible to provide complete functionality here. The API I’m suggesting is a building block, and someone would request for it +ZB: ??? Impossible to provide complete functionality here. The API I’m suggesting is a building block, and someone would request for it MCM: Can you give background on what the objection to doing calculations is? @@ -93,7 +93,7 @@ MCM: I agree with the principle that in order to know whether to make a high-lev RCA: I have a comment as an end user: It looks handy and useful, but I see a lot of customizations here that make sense for a 3rd party library. There are two steps here: conversion and formatting. I don’t know any libraries that do both of these things together. -SFC: I’ve got a couple of comments. The issue 210 about ??? in my mind covers a lot of feature requests about the ability to customize the data that empower this feature. Customizing the rounding behavior from YMD researchs is pretty straightforward (?). The other point I had was, we don’t currently do calculations that involve multiplicative operations, but we do scaling and scientific notation. +SFC: I’ve got a couple of comments. The issue 210 about ??? in my mind covers a lot of feature requests about the ability to customize the data that empower this feature. Customizing the rounding behavior from YMD researchs is pretty straightforward (?). The other point I had was, we don’t currently do calculations that involve multiplicative operations, but we do scaling and scientific notation. ZB: I think you’re right. There are two pieces that could be building blocks when considering such an API. I’m a little concerned about shipping such a high-level end-to-end feature. I trust your experience with ICU, but I’m concerned that this isn’t the only thing people want to do. Maybe it’s true that we know everything, but we need to do some more research here. @@ -109,7 +109,7 @@ MCM: I admit that such liberal algorithms help browsers, but they also leave non SFC: I haven’t formed an opinion, but this doesn’t seem to be a kind of algorithm that can cause browser inconsistency. The Date constructor is an example of that, due to the way we parse Strings there. Can we say we want some more research about how this problem is being solved into JS space before we move too much forward with this proposal? I’d hope that this committee agrees with the idea of smart units are important for ECMA402? -ZB: I understand. I agree with the proposal in the principle of Internationalization, but I think “smart” things tend to age poorly in Computer Science. One valuable thing we can bring is that when this is part of ECMA402, we avoid shipping such locale data to every user that fetches a site. +ZB: I understand. I agree with the proposal in the principle of Internationalization, but I think “smart” things tend to age poorly in Computer Science. One valuable thing we can bring is that when this is part of ECMA402, we avoid shipping such locale data to every user that fetches a site. SFC: Is not only the data, but also the code to do the conversions and selecting user preferences. @@ -166,7 +166,7 @@ That's really not the way styles work. In some locales, the option bag may chang SFC: The other example is that style: "currency" causes fraction digits to be recalculated. -ZB: If the user sets a different ??? do we show the max of it. +ZB: If the user sets a different ??? do we show the max of it. The only use case I can imagine for that is people using it to expect to have fields in a given way. We don’t want to users having this expectation, because we can change this from CLDR data. SFC: (show example in screen for the problem) @@ -241,7 +241,7 @@ Difference between Windows and Mac: one of those platforms assume if you overrod SFC: User preference comes from navigator. If the extension keyword is not present, then resolve it from locale data. If you strip the extension keywords, then it will always come from locale data. These issues will need to be resolved as this moves forward into stage 1. -SFC: This is not the only issue re: user preferences, actually there are 9 of them. I hope we can resolve all of these issues with the same framework. One specific framework was proposed in issue #409, related to #416 discussed at the onsite in February - in the HTTP header. +SFC: This is not the only issue re: user preferences, actually there are 9 of them. I hope we can resolve all of these issues with the same framework. One specific framework was proposed in issue #409, related to #416 discussed at the onsite in February - in the HTTP header. SFC: I've made contact with client-hints people, hoping to make progress with them. @@ -300,7 +300,7 @@ ZB: Why is it not supported, perhaps was it added late? FYT: what does RG mean? -SFC: en-US: English as spoken in the US. But if you grew up in Romania, and speak en-US and write it, might +SFC: en-US: English as spoken in the US. But if you grew up in Romania, and speak en-US and write it, might prefers other preferences from Romania, then the locale would be en-US-u-rg-RO. @@ -330,7 +330,7 @@ SFC: I think we have general agreement on this. https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -SFC: There are a few pull requests that have not yet been merged. Added a table +SFC: There are a few pull requests that have not yet been merged. Added a table This includes things that don’t have 402 consensus, and maybe should not have been merged. In particular, relative time format does not have length properly, so should length be added to relative time format. Why do we really need this, and should we either add for consistency and explore if it’s needed in others. @@ -357,13 +357,13 @@ RGN: … reviewers have been activated. ZB: something noted in Nodes - not certain if break iterator can be removed even if segmenter is available. Breaking is increasing in use. We don’t want to have to maintain the two in parallel. Is it clear that break iterator will be removed? -FYT: Deprecations need time. [V8 break iterator, line]. Now, 0.65 % of web pages use a break iterator. 0.4% use the iterator on words. +FYT: Deprecations need time. [V8 break iterator, line]. Now, 0.65 % of web pages use a break iterator. 0.4% use the iterator on words. FYT: 0.07% are using it for line break. That gives me a little more confidence that when we ship the segmenter without the line break, we can more easily move forward to deprecating that. SFC: we can discuss this some more first thing next meeting. -FYT: The only blocking issues are +FYT: The only blocking issues are RGN: the current spec as-is does not have any of these issues, it just has a weird collection of properties. There is a pull request to correct that. diff --git a/meetings/notes-2020-07-09.md b/meetings/notes-2020-07-09.md index 92aaef9b..1fd0f3d6 100644 --- a/meetings/notes-2020-07-09.md +++ b/meetings/notes-2020-07-09.md @@ -19,7 +19,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/rwaldron/tc39-notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) ## Next Meeting @@ -87,7 +87,7 @@ FBN: Going with the easy approach, throwing an exception is simple. For anything SFC: one model we could consider is that by default fields that are greater than the specified options would be shown if required to differentiate between the two date times. So far, that’s basically what we have. It breaks down when you get to minutes, at least for Chrome, which seems odd. Perhaps one way to solve this is to say “in order to differentiate, you always add fields that are greater in size”. Idk what Chrome’s impl is doing, but we can make it compliant to that. -EAO: +EAO: ??? @@ -261,7 +261,7 @@ FYT: I think what you plan to do is much better. https://github.com/tc39/ecma402/pull/459 -USA: This is a normative PR from FYT. This allows you to pass in collation as an option as well as a Unicode extension key. (???) +USA: This is a normative PR from FYT. This allows you to pass in collation as an option as well as a Unicode extension key. (???) FYT: (???) This isn't defined in all locales, but it will make it more consistent. diff --git a/meetings/notes-2020-08-13.md b/meetings/notes-2020-08-13.md index fbd022ac..a917c6be 100644 --- a/meetings/notes-2020-08-13.md +++ b/meetings/notes-2020-08-13.md @@ -19,7 +19,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -49,7 +49,7 @@ SFC : Will create an issue, to follow up later if we should give admin access or ### Airtable as alternative to the status wiki -SFC: *show an alternate status listing on airtable.com* +SFC: *show an alternate status listing on airtable.com* SFC: The wiki page of showing the status are good to view but hard to change @@ -75,7 +75,7 @@ SFC: perfect. In that case, we did get consensus during the July meeting. LEO: no pressure, but we can merge this in if we get consensus right now. -SFC: Ok, I'm gonna record consensus. +SFC: Ok, I'm gonna record consensus. #### Conclusion @@ -87,7 +87,7 @@ https://github.com/tc39/ecma402/pull/471 USA: I think I've resolved all the comments. But I need people to give an approving review. I'd like everyone to go back and hit the review button if everything looks okay. -SFC : Sounds good to me, we should provide links to Issues(Jeff and Frank) and MDN +SFC : Sounds good to me, we should provide links to Issues(Jeff and Frank) and MDN USA: I'll follow up with FYT and JSW. @@ -165,7 +165,7 @@ One is the weekday data. Zibi already has mozIntl.getCalendarInfo. And there are Another is language direction. Given a language, is it RTL or LTR? It should really be "is it bi-di", since no language, not even Arabic, is strictly right-to-left. There are third-party libraries that do a similar thing. -Then, there’s something called a “measurement system”. Currently, I don’t think ICU exposes everything we need for this, there’s a different set of functions in both Java and C, but data is in CLDR. I don’t know how exactly we need to expose that information. One solution is that we can just add getters to Intl.Locale and we keep adding more getters as we go. The second approach is to add a function to Intl, and you can pass the info you need in a string, this is closer to how Mozilla does it currently. This is still up for discussion. I want to discuss if this is meaningful to move to Stage 1. +Then, there’s something called a “measurement system”. Currently, I don’t think ICU exposes everything we need for this, there’s a different set of functions in both Java and C, but data is in CLDR. I don’t know how exactly we need to expose that information. One solution is that we can just add getters to Intl.Locale and we keep adding more getters as we go. The second approach is to add a function to Intl, and you can pass the info you need in a string, this is closer to how Mozilla does it currently. This is still up for discussion. I want to discuss if this is meaningful to move to Stage 1. JSW: This is perfectly reasonable information. @@ -321,7 +321,7 @@ SFC: right now when you call an Intl constructor with an options arg which isn JSW: the only case we can be worried about would be accidental cases in which case this was done but somehow worked because the caller was expecting the default behaviour. -FYT: so do you mean +FYT: so do you mean SFC: I want to separate the semantic issue and the spec issue. The important question here is, are we okay with the normative change here. diff --git a/meetings/notes-2020-09-10.md b/meetings/notes-2020-09-10.md index e7efdab5..76da76ad 100644 --- a/meetings/notes-2020-09-10.md +++ b/meetings/notes-2020-09-10.md @@ -15,7 +15,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) diff --git a/meetings/notes-2020-10-08.md b/meetings/notes-2020-10-08.md index f157adef..e520ba27 100644 --- a/meetings/notes-2020-10-08.md +++ b/meetings/notes-2020-10-08.md @@ -15,7 +15,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) diff --git a/meetings/notes-2020-11-05.md b/meetings/notes-2020-11-05.md index e85bcf3d..f297e57f 100644 --- a/meetings/notes-2020-11-05.md +++ b/meetings/notes-2020-11-05.md @@ -21,7 +21,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -39,7 +39,7 @@ SFC: Do you have any questions or requests from this group? RCA: Use cases are a great help, to determine whether our proposal aligns with the expectations of everybody. -RCA : Message Format Unicode Conference (Slides) and open issues that may need some help #119 +RCA : Message Format Unicode Conference (Slides) and open issues that may need some help #119 ## Discussion Topics @@ -51,7 +51,7 @@ ZB: If you add features as soon as you have any use case, you'll eventually add SFC: I feel like this should still be on a case-by-case basis. It is a Stage 2 requirement. -LEO: Where do we draw the line? One thing about this group is that we have a diversity of opinions here. We have practitioners and implementers. I've been on both sides. We get lots of perspectives. We need to recognize that bias is a thing for everyone. I think case-by-case is the easiest solution, but there are a lot of things we can add. We can add things to mitigate the burn of having this case-by-case. +LEO: Where do we draw the line? One thing about this group is that we have a diversity of opinions here. We have practitioners and implementers. I've been on both sides. We get lots of perspectives. We need to recognize that bias is a thing for everyone. I think case-by-case is the easiest solution, but there are a lot of things we can add. We can add things to mitigate the burn of having this case-by-case. LHO: How does 262 operate? diff --git a/meetings/notes-2020-12-04.md b/meetings/notes-2020-12-04.md index 74cb0501..b9840612 100644 --- a/meetings/notes-2020-12-04.md +++ b/meetings/notes-2020-12-04.md @@ -20,7 +20,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) diff --git a/meetings/notes-2021-01-14.md b/meetings/notes-2021-01-14.md index 0b6cf637..b7ed1031 100644 --- a/meetings/notes-2021-01-14.md +++ b/meetings/notes-2021-01-14.md @@ -24,7 +24,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -228,7 +228,7 @@ FYT: What is the SpiderMonkey position? JSW: I'm not too worried about it. It's more simplicity, better hygiene. So basically, why not? -SFC: I think the simplicity, better hygiene, and perf improvement on +SFC: I think the simplicity, better hygiene, and perf improvement on Consensus. diff --git a/meetings/notes-2021-02-11.md b/meetings/notes-2021-02-11.md index 77023f0d..888bde11 100644 --- a/meetings/notes-2021-02-11.md +++ b/meetings/notes-2021-02-11.md @@ -20,7 +20,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -178,7 +178,7 @@ USA: Yes JGT: Yes -https://twitter.com/Litherum/status/1289405657716645888 +https://twitter.com/Litherum/status/1289405657716645888 SFC: Okay, so we can default smallestUnit/largestUnit differently depending on if the input is a Duration or an object. diff --git a/meetings/notes-2021-03-11.md b/meetings/notes-2021-03-11.md index 2791bbf1..80ebf735 100644 --- a/meetings/notes-2021-03-11.md +++ b/meetings/notes-2021-03-11.md @@ -18,7 +18,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -150,9 +150,9 @@ SFC: I see two fundamental questions. (1), are time zone and calendar pickers us MCM: If we focus on pickers, we should collaborate with Open UI, whose purpose of existence is to (partly to) work on pickers. -RCA: I believe one of the main drivers to have this proposal are picker’s , but also the web performance in general. Most popular libraries like moment-timezone(8 Million weekly downloads), have an extra cost depending on how many locales you support, those must be optimized by bundlers, in case you want to reduce the typical 1mb that momentjs has with all extra data. +RCA: I believe one of the main drivers to have this proposal are picker’s , but also the web performance in general. Most popular libraries like moment-timezone(8 Million weekly downloads), have an extra cost depending on how many locales you support, those must be optimized by bundlers, in case you want to reduce the typical 1mb that momentjs has with all extra data. -Projects like OpenUI can bring us several opportunities to improve pickers that need this kind of data, but actual UI’s implemented in browsers lack those features and aren’t perfect dealing with timezones or other “special” localization features. +Projects like OpenUI can bring us several opportunities to improve pickers that need this kind of data, but actual UI’s implemented in browsers lack those features and aren’t perfect dealing with timezones or other “special” localization features. FYT: So, going back to the original question, do we satisfy the three points for Stage 2? diff --git a/meetings/notes-2021-04-08.md b/meetings/notes-2021-04-08.md index 257b5ee4..179ce8a4 100644 --- a/meetings/notes-2021-04-08.md +++ b/meetings/notes-2021-04-08.md @@ -14,7 +14,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -67,7 +67,7 @@ SFC: both approaches are valid, prefer Approach 2 because of semantics and usabi FYT: ??? -ZB: only consideration when considering those proposals was +ZB: only consideration when considering those proposals was FYT: ??? @@ -85,13 +85,13 @@ RGN: my preference is the restriction. If the preference is provided explicitly, ZB: I have the opposite preference. We do not have a rejection list format. There is no way for the user to say that they DON’T want a calendar, just that they do a specific one. -If the user says use Serbian, it doesn’t mean that the user is rejecting other options. Fallacy of selecdting the first best option. We are always working on incomplete information. What happens if user specifies a calendar that we can’t return *and* we are using restrictive model,, then return something that may work but it may not be valid and may even crash the system. +If the user says use Serbian, it doesn’t mean that the user is rejecting other options. Fallacy of selecdting the first best option. We are always working on incomplete information. What happens if user specifies a calendar that we can’t return *and* we are using restrictive model,, then return something that may work but it may not be valid and may even crash the system. RGN: You are questioning the intended operation of the system - this is not the right discussion to have at this level. FYT: I’m more aligned with RGN’s note, but I can see ZB’s point. It’s hard to say what’s the right behavior. -ZB: Culturally, I’m making a strong opinion, but it’s weakly held. +ZB: Culturally, I’m making a strong opinion, but it’s weakly held. RGN: A reasonable answer cannot be discussed without discussing use-cases and semantics? @@ -111,7 +111,7 @@ ZB: Same in Firefox. FYT: A developer on the server side could store a locale string with preferences. They can call this API and get preferred calendar from the API. -But we are talking about what is provided to process the preferences, not what it returns +But we are talking about what is provided to process the preferences, not what it returns ZB: I understand that right now, this is how it works. And I understand that after we ship this API, we will get requests to make this API respect operating system preferences. @@ -121,9 +121,9 @@ ZB: The way I would imagine this request coming is that someone passes en-US, an SFC: There should not be a way to get OS data through ECMA-402. This can be done on the web platform from language settings. (Encourages listeners to think about gathering user preferences from a variety of places.) -Cannot get this from Locale, however! Could get from navigators, headers, or other source. +Cannot get this from Locale, however! Could get from navigators, headers, or other source. -FYT: Two approaches - but neither seems strongly held. +FYT: Two approaches - but neither seems strongly held. Suggests brining to Stage 3 at next meeting.l SFC: For now, I would prefer choosing shorter return of just one element. @@ -191,7 +191,7 @@ USA: I can be a Stage 3 reviewer. FYT: Any suggestions on names? Also showing examples in Spanish & Chinese of dateTimeField -SFC: Are we happy with this to progress to Stage 3? (uncomfortable silence). SFC supports Stage 3, which is already scaled back and is now a fairly thin proposal. +SFC: Are we happy with this to progress to Stage 3? (uncomfortable silence). SFC supports Stage 3, which is already scaled back and is now a fairly thin proposal. Planning to fill in calendar names? @@ -215,7 +215,7 @@ BREAK TIME SFC: Next on agenda: --Time Zone for S2 +-Time Zone for S2 - Rounding options - Intl Duration format @@ -251,7 +251,7 @@ Also added spec tag detail. Changes are highlighted in green background. Section Proposes to move to Stage 2. -SFC: Frank has done his homework and the arguments are quite compelling. I agree with the TimeZone comments re: ISO-8601. I support Stage 2 and would even support Stage 3. +SFC: Frank has done his homework and the arguments are quite compelling. I agree with the TimeZone comments re: ISO-8601. I support Stage 2 and would even support Stage 3. RGN: I support the proposal, but I don't know about the names "shortGMT" and "longGMT". @@ -265,7 +265,7 @@ RGN: that’s the same direction I was going to take that. FYT: Is the offset a number or a string in Temporal? -USA: It's a string. Do you +USA: It's a string. Do you FYT: Not very picky about names - no preferences @@ -322,7 +322,7 @@ https://github.com/tc39/proposal-intl-numberformat-v3/issues/7 SFC: now proposing9 rounding modes (ceil, floor, … halfEven). FYT: What’s the current default? -SFC: current is halfExpand +SFC: current is halfExpand USA: also would be useful. HalfOdd was dropped because no use cases were found. @@ -334,7 +334,7 @@ E.g., with duration formatting (in process), currently does not allow formatting SFC: These options set precedent for other proposals. Other use one or more of the proposed options. FYT: Plural rules affected? -SFC: SHort option may be added wherever needed. They will have to pass the options down to NumberFormatting when they use +SFC: SHort option may be added wherever needed. They will have to pass the options down to NumberFormatting when they use FYT: Relative Time Format - does it accept anything other than integers? SFC: good questions for S3 review. Asking for comment on 9 modes proposed. @@ -376,7 +376,7 @@ FYT: I strongly opposes putting into format based on his formatting prototypes. USA: Does smallestUnit/largestUnit affect the number format? -FYT: No. I may need to waste resources. This may force getting new data / new construction. +FYT: No. I may need to waste resources. This may force getting new data / new construction. RGN: From the perspective of an author using this API, the overwhelming pattern is that the only argos to formatter are the data themselves to be formatted. I don’t see a compelling reason to change this now. Better to put in constructor. @@ -402,7 +402,7 @@ For Stage 3, we can still influence, but RelativeDateTimeFormatter has been publ SFC: I agree with Frank on this. -USA: if Temporal does switch to singular, does this resolve? +USA: if Temporal does switch to singular, does this resolve? SFC: I don’t agree that we need to do come up with a Plan B. We can make a recommendation in our capacity of TG2 that TG1 should make this change. Only if TG1 declines our request, then we can define Plan B. diff --git a/meetings/notes-2021-05-06.md b/meetings/notes-2021-05-06.md index 371e419a..5354c793 100644 --- a/meetings/notes-2021-05-06.md +++ b/meetings/notes-2021-05-06.md @@ -23,7 +23,7 @@ Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) @@ -39,7 +39,7 @@ LEO: The ECMA bylaws require a quick vote, let’s do a quick roll-call. FYT: Just to confirm, are we just talking about adding USA and not removing any existing editors? -LEO: to be fair, I have less time to work on things lately, but let’s keep this discussion separate. +LEO: to be fair, I have less time to work on things lately, but let’s keep this discussion separate. SFC: Let’s take the votes: @@ -403,7 +403,7 @@ Votes: - DLM: 1 > 3 > 4 = 5 >> 2 - FYT: 1 > 3 = 5 > 4 >> 2 - JGT: 4 > 5 = 3 = 2 >> 1 -- MLS: 5 > 3 > 4=2 > 1 +- MLS: 5 > 3 > 4=2 > 1 - PFC: 3 > 4 > 5 >> 1 = 2 Notes: @@ -446,7 +446,7 @@ https://github.com/tc39/proposal-intl-duration-format/issues/40 USA: the original proposal by JGT included, alongside hide and show, an option called auto for all three zero fields options. I did not add them yet because of two reasons: -Since the values are set right alongside “style”, there is not a massive benefit +Since the values are set right alongside “style”, there is not a massive benefit ????? @@ -474,7 +474,7 @@ SFC: On the "weeks" issue… we need a way to toggle between 0 weeks and 0 month FYT: Is it possible to say "1 year and 200 days" without months or weeks? -JGT: There are two issues. One is SFC's issue. The second is that, if that's allowed somehow, should the default behavior to show internal things, or should the default be to hide them? They are two somewhat separate issues. And I think hiding internal by default is more likely to be a good +JGT: There are two issues. One is SFC's issue. The second is that, if that's allowed somehow, should the default behavior to show internal things, or should the default be to hide them? They are two somewhat separate issues. And I think hiding internal by default is more likely to be a good SFC: It seems like we keep getting more and more complicated with smallestUnit, largestUnit, and the three types of zeros. So should we revert back to the version where we just have an includelist of units? @@ -484,7 +484,7 @@ JGT: The challenge with SFC's suggestion is, how do you format a Temporal.Durati USA: It did work before. -SFC: a whitelist of fields is accepted as an option in the constructor. Those fields are pulled out and displayed. +SFC: a whitelist of fields is accepted as an option in the constructor. Those fields are pulled out and displayed. USA: ??? diff --git a/meetings/notes-2021-06-03.md b/meetings/notes-2021-06-03.md index fd6334d4..f4e50451 100644 --- a/meetings/notes-2021-06-03.md +++ b/meetings/notes-2021-06-03.md @@ -22,7 +22,7 @@ Attendees: Standing items: - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -395,7 +395,7 @@ FYT: formatToParts returns arrays. SFC: Yes, but this is a fundamentally different question than formatToParts. -LEO: I think developer experience is important. Via chat: Not any strong preference, but Arrays seems more intuitive for Developers Experience. In cases like this, I'd consult with JS Educators. https://twitter.com/laurieontech. Laurie helped with pretty good insights on other proposals, it might be the case here. +LEO: I think developer experience is important. Via chat: Not any strong preference, but Arrays seems more intuitive for Developers Experience. In cases like this, I'd consult with JS Educators. https://twitter.com/laurieontech. Laurie helped with pretty good insights on other proposals, it might be the case here. FYT: ??? diff --git a/meetings/notes-2021-07-01.md b/meetings/notes-2021-07-01.md index 520691cf..7651c405 100644 --- a/meetings/notes-2021-07-01.md +++ b/meetings/notes-2021-07-01.md @@ -20,7 +20,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -31,7 +31,7 @@ RCA: We did a Q&A Session where some questions were presented/asked in order to simplify the understanding of all MFWG and help unblock the Data Model progress. We are quite happy with the final outcome but we don't have a conclusive answer yet. We will continue the next Extended and Plenary meetings working on that to have the final decision soon. -Sharing documents: +Sharing documents: https://docs.google.com/document/d/1kVXGMfwNKwU8QiUvUKReGapUAOhwZYaWJUAI3NW06UA/edit#heading=h.ic6nmqb0o978 @@ -257,7 +257,7 @@ ZB: (1), Frank stated that if we aim to specify the order, that means that someo SFC: The web is huge, and it is very likely that one of its billions of pages does in fact depend on current order. -EAO: Worth noting that the [polyfill for Intl.PluralRules](https://github.com/eemeli/intl-pluralrules) returns the UTS 35 order, as it uses make-plural as its data source for the [plural categories](https://github.com/eemeli/make-plural/blob/master/packages/plurals/pluralCategories.mjs), which in turn are drawn from CLDR data. +EAO: Worth noting that the [polyfill for Intl.PluralRules](https://github.com/eemeli/intl-pluralrules) returns the UTS 35 order, as it uses make-plural as its data source for the [plural categories](https://github.com/eemeli/make-plural/blob/HEAD/packages/plurals/pluralCategories.mjs), which in turn are drawn from CLDR data. #### Conclusion diff --git a/meetings/notes-2021-09-09.md b/meetings/notes-2021-09-09.md index cc519b69..d93632bd 100644 --- a/meetings/notes-2021-09-09.md +++ b/meetings/notes-2021-09-09.md @@ -22,7 +22,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -141,7 +141,7 @@ FYT: I think we should take the whole locale to influence the result. FYT: Do we need to make any changes to the proposal, and if so, what changes are needed? -RCA: No strong opinion on that, but concerned by the possible conflict with Temporal +RCA: No strong opinion on that, but concerned by the possible conflict with Temporal #### Conclusion @@ -180,7 +180,7 @@ TOM: For performance, the obvious tweak would be to do validation on the server. YSZ: I think this is a super important part of the application. (1) Like FYT said, some of this data is not Intl data. (2) Phone validation is very complicated, like ZB said. We need to care about the UI; for example, inputting the credit card should trigger a numeric keyboard rather than an alphabetic keyboard. So it seems like we need . Did you consider starting there? -TOM: I thought about that, and I put it in the explainer as an alternative. +TOM: I thought about that, and I put it in the explainer as an alternative. SFC: In order to avoid the "15th standard" issue, you should approach the industry leader in i18n standards, the Unicode Consortium, about making a working group to establish the industry canonical solution. ECMA-402 looks for prior art, and Unicode is the place we point to most often. This is similar in a way to the MessageFormat Working Group, which was chartered to resolve the competing standards for MessageFormat by bringing all the authors together. diff --git a/meetings/notes-2021-10-07.md b/meetings/notes-2021-10-07.md index e14cacde..e5a1ff55 100644 --- a/meetings/notes-2021-10-07.md +++ b/meetings/notes-2021-10-07.md @@ -16,7 +16,7 @@ ### Standing items - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -37,9 +37,9 @@ LEO : At the moment not able to work. My availability is limited and not able to RCA : We don’t have a big update, started writing the spec, more frequent meetings, prioritization. This is the status quo. Go through the updates list. -FYT : There is anything blocking Intl.Segmenter ? +FYT : There is anything blocking Intl.Segmenter ? -GPT : Will check actual status later +GPT : Will check actual status later LEO : It’s possible to have an ETA GPT ? @@ -59,11 +59,11 @@ USA : We need TG1 consensus. Should we ref the Unicode table directly instead of SFC: We should decide together with editor what we can do this kind of PR we already have an open issue to [discuss this](https://github.com/tc39/ecma402/issues/584) -USA: We can have a template that ease going over changes of CLDR +USA: We can have a template that ease going over changes of CLDR FYT: This particular table only means that the item that is added should be supported, but it can not be the only item that should be supported. -SFC: https://github.com/tc39/ecma402/issues/584 +SFC: https://github.com/tc39/ecma402/issues/584 YSZ: This is not shipping in ICU yet, so in order to conform to the spec, we would need to be shipping ICU trunk. @@ -77,9 +77,9 @@ FYT: This table is the minimal set not the maximal set. Maybe we can wait on mer MCM: We don’t mind presenting sooner or later, but we like the resolution here. #### Conclusion -Approved +Approved -### Editorial: Define a structured signature for PluralRuleSelect +### Editorial: Define a structured signature for PluralRuleSelect https://github.com/tc39/ecma402/pull/613 (discussion notes here) @@ -109,7 +109,7 @@ https://github.com/tc39/ecma402/pull/571 ## Proposals and Discussion Topics -### Intl.Segmenter +### Intl.Segmenter RGN: Should we move to Stage 4 ? @@ -147,7 +147,7 @@ FYT: We should be careful and validate if this is PR is really editorial and non USA: I can ask implementers if this change would change the actual implementation or generate any regression before we merge this change #### Conclusion -We have to make sure that this PR is validated before we can merge +We have to make sure that this PR is validated before we can merge PR Approved ### ECMA 402: #574 @@ -165,7 +165,7 @@ FYT: We should be careful and validate if this is PR is really editorial and non USA: I can ask implementers if this change would change the actual implementation or generate any regression before we merge this change #### Conclusion -We have to make sure that this PR is validated before we can merge +We have to make sure that this PR is validated before we can merge PR Approved @@ -173,15 +173,15 @@ PR Approved -### Intl.DurationFormat: +### Intl.DurationFormat: https://github.com/tc39/proposal-intl-duration-format/ -USA: At this point we want to ask for Stage 3 in the next October meeting? +USA: At this point we want to ask for Stage 3 in the next October meeting? -USA: Any questions about the design works ? +USA: Any questions about the design works ? -MCM: We aren’t prepared to provide any feedback +MCM: We aren’t prepared to provide any feedback USA: Could we follow up offline then we can review the proposal @@ -191,31 +191,31 @@ USA: I can finish all requirements for moving stage then reach everybody address SFC: We should address all needs and concerns to move to the next stage. -FYT: I don’t think this is ready yet, I think we need to finish the spec first before asking for this. +FYT: I don’t think this is ready yet, I think we need to finish the spec first before asking for this. SFC : Last TC39 meeting Ujjwal presentend and we gave a feature complete implementation, if we can work with stage 3 reviewers offline and finish in the next days we have enough time to get to stage 3 this month -MGM: What's the urgency to reach stage 3 this month +MGM: What's the urgency to reach stage 3 this month USA: This proposal is stage 2 for long time with feature complete implementation -SFC: This proposal is likely to require changes and some ICU updates, then if we reach stage 3 we can ask for those changes to be included in ICU 71 and also affect the Temporal proposal. +SFC: This proposal is likely to require changes and some ICU updates, then if we reach stage 3 we can ask for those changes to be included in ICU 71 and also affect the Temporal proposal. -FYT : Do we have any feedback from reviewers ? +FYT : Do we have any feedback from reviewers ? USA: No feedback was provided, we wi -FYT : MGM can you review this proposal before the next ECMA402 meeting ? +FYT : MGM can you review this proposal before the next ECMA402 meeting ? YSZ: Sure FYT: Do we have an agreement to look at this PR offline from Google and Apple someone from Mozilla ? -GPT: I can check it offline +GPT: I can check it offline #### Conclusion -USA: We need to advance as much as we can on finishing the pending points of spec then reach all implementers to validate and be at the next meeting. +USA: We need to advance as much as we can on finishing the pending points of spec then reach all implementers to validate and be at the next meeting. ### Normative: Add new numbering system "tnsa" (Continuation) FYT: [...?] We have 9 months to conform. @@ -239,7 +239,7 @@ MCM: We prefer that feature to be removed from the spec but weren’t blocking o https://github.com/tc39/ecma402/issues/109 -MCM: When this issue was discussed in the past , we were concerned about fingerprinting +MCM: When this issue was discussed in the past , we were concerned about fingerprinting USA: The plan would be prepare a detailed design document to review this in detail at this group @@ -270,13 +270,13 @@ SFC: I just brought this to the meeting to have a temperature check and see how FYT: I worked with transliteration for a while. Transliteration in ICU is very generic. You have an input, some options and an output based on that. That is very generic. You could say “translate from English to German”. You have some degree of transliteration right now. It might be more practical to go for a certain type of transliteration. A lot of the CLDR files are not in great quality. We need to be careful of that to scope it well. -MCM: We want to speak in favour of transliteration, agreeing with what FYT said. We want to be sure that +MCM: We want to speak in favour of transliteration, agreeing with what FYT said. We want to be sure that USA : In support of FYT said I think we should scope this feature and benchmark the Size vs Usage of this feature MCM: This may not fit on the JS but we need to choose carefully where this feature could fit, -FYT: I have two suggestions: 1) hiragana/katana to latin 2) indic scripts to latin +FYT: I have two suggestions: 1) hiragana/katana to latin 2) indic scripts to latin If you go to google translate, they include pronunciations, and I did it using ICU but it isn’t sufficient. This is neither practical nor good enough. If we can narrow it down to these, it would be good and useful. @@ -294,9 +294,9 @@ We need to figure out the right way to idealize this proposal ### Change Array.prototype.toLocaleString to use ListFormat #422 https://github.com/tc39/ecma402/issues/422 -SFC: Do you think this is a change that we want to make ? +SFC: Do you think this is a change that we want to make ? -USA : What would be the default for this specific case when using an array +USA : What would be the default for this specific case when using an array FYT: We follow same format from the default of ListFormat diff --git a/meetings/notes-2021-11-04.md b/meetings/notes-2021-11-04.md index ff349a4f..aac08974 100644 --- a/meetings/notes-2021-11-04.md +++ b/meetings/notes-2021-11-04.md @@ -16,7 +16,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -40,11 +40,11 @@ ZB: Established a preliminary roadmap that we'll present on Monday. https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -SFC: Intl Locale Info ? +SFC: Intl Locale Info ? -FYT : I need to reflect changes proposed at plenary into the proposal, +FYT : I need to reflect changes proposed at plenary into the proposal, -ZBI : We are currently in BETA and we still cleaning up +ZBI : We are currently in BETA and we still cleaning up https://bugzilla.mozilla.org/show_bug.cgi?id=1693576 @@ -55,26 +55,26 @@ ZBI : Got merged two months ago, shipped in FF93 https://bugzilla.mozilla.org/show_bug.cgi?id=1670033 -SFC : NFv3 ? +SFC : NFv3 ? YSZ: Will land soon in JSC, we currently implementing those feature against ICU 68 that may miss some data to finish implementation SFC: I will check if there is something missing in ICU 70 for NFv3 -SFC : Intl.DurationFormat is Stage 3 :) +SFC : Intl.DurationFormat is Stage 3 :) ## Pull Requests ### Normative: Fix spec bugs in numberformat.html caused by Unified NumberFormat -https://github.com/tc39/ecma402/pull/572 +https://github.com/tc39/ecma402/pull/572 -SFC: We were waiting for Leo to merge this one but i think we have approvals and we could merge it wdyt? Would be good to have test for it +SFC: We were waiting for Leo to merge this one but i think we have approvals and we could merge it wdyt? Would be good to have test for it RGN: I think we are good to go -FYI : This is a rollback PR ? +FYI : This is a rollback PR ? SFC: RGN could you check with Ujjwall to be approved @@ -86,11 +86,11 @@ Approved to be merged , last check with Ujjwall https://github.com/tc39/ecma402/pull/571 -SFC: Could you check with Ujjwall to get this merged ? +SFC: Could you check with Ujjwall to get this merged ? #### Conclusion -Approved +Approved ## Proposals and Discussion Topics ### Strictness of selectRange #65 @@ -112,7 +112,7 @@ If start is undefined or start is undefined, throw a TypeError exception. https://github.com/tc39/proposal-intl-numberformat-v3/issues/54 -YSZ : If we accept the change this may have another affectations +YSZ : If we accept the change this may have another affectations SFC : The proposal intends to maintain the full precision, I’m inclined to accept arbitrary precision, ICU is not able to do it, in case we accept it browser should convert it. @@ -134,7 +134,7 @@ FYT: Would like to present at the next TC39 meeting about it. We get consistent MCM: We should discuss these two features independently. Batch mode in particular it passes the smell test, we would like that would be a perf improvement at least in 2 browsers, we only need a sampling to benchmark that, and have that proof that this would really improve the performance -FYT: Are you suggesting breaking this down in two proposals ? may be a possibility +FYT: Are you suggesting breaking this down in two proposals ? may be a possibility MCM: Not right now. But I do think they are separable. @@ -142,7 +142,7 @@ MCM: For line breaking, canvas and JS has never been able to paragraph layout th FYT: I think the use case is not what you are thinking , the case you mention is not for paragraph but instead applies to a title , example the Pie Chart where normally is one liner but sometimes it breaks in two lines this was the use case … but I agree that this may be important also for paragraph layout -MCM: For me paragraph is anything larger than one line +MCM: For me paragraph is anything larger than one line ZBI: We have positive feedback from our team regarding the API, we don’t expect this API to do line breaks but returns line break opportunities, that’s correct ? @@ -162,7 +162,7 @@ FYT: I agree that this is a complicated operation. I think that's exactly the re ZBI: You are proposing that this work should be aligned with Houdin worki to design this API? My concern is that I would like these two things to be aligned, but we have environments that will not be able to use Houdini. Houdini work doesn’t invalidate the needs of this API, Do you have any timeline about this ? -MCM: For the first point, I assume you're talking about Node.js. Node.js doesn't need this, because they have native modules; I think that's a separate concern. And as far as timeline, +MCM: For the first point, I assume you're talking about Node.js. Node.js doesn't need this, because they have native modules; I think that's a separate concern. And as far as timeline, SFC : Do you want to wrap up this in the form of a proposal for Stage 1? Then we can talk about it in the next meeting #### Conclusion @@ -173,13 +173,13 @@ FYT will present next ECMA402 meeting a proposal for stage 1 https://github.com/tc39/proposal-intl-locale-info/issues/59 -SFC: This was discussed at the Unicode Conference last month. Right now it only talks about RTL and LTR. However, direction is much more complicated. The question is , what should we be returning ? What is mainly the use case for these options ? Cause this must influencitate the Spec +SFC: This was discussed at the Unicode Conference last month. Right now it only talks about RTL and LTR. However, direction is much more complicated. The question is , what should we be returning ? What is mainly the use case for these options ? Cause this must influencitate the Spec SFC : Frank is a champion of this topic FYT: So the original thing is that this is based on what Mozilla has. It's for setting the global direction. If you have a web page and you know… there is no page that has a single structure. The author needs to dynamically set some layout, e.g., based on the data received. Javascript can be used to figure out the alignment and direction for that particular text. For example, user comments may be in a different language with different direction needs. JS could tell the HTML what settings should be used. -FYT: One of the prior arts is that CLosure has bidi features. This feature I think is designed to provide what is a common request; people who work with bidi need this facility. In google translate user can type their source language and is able to change to different languages that changes the global direction, +FYT: One of the prior arts is that CLosure has bidi features. This feature I think is designed to provide what is a common request; people who work with bidi need this facility. In google translate user can type their source language and is able to change to different languages that changes the global direction, Of course the internal layout engine can look at the text, but in many cases, there is no text that can be analyzed to set the directions. Japanese, Chinese, Korean can use vertical text, but not commonly used online yet. Mongolian, however, requires vertical, but it’s not very well addressed yet. @@ -192,7 +192,7 @@ CCN: How much of the complexity of directionality that was laid out at the confe FYT: This API is not covering layout at this point , is something on top of layout just giving the information about the global direction of the layout, Just what is the direction of the layout, not the detailed orientation of characters within each text segment. That’s more appropriate for CSS. -Example : we have an empty textbox the user type something with a selected language we need to “notify” the layout engine to render it correctly +Example : we have an empty textbox the user type something with a selected language we need to “notify” the layout engine to render it correctly The first character(s) typed may not give info about the text direction, i.e., many be neutral, so this proposal would give the HTML the needed information based on the language setting for this box, e.g., RTL / LTR. This also includes text alignment. @@ -240,13 +240,13 @@ MCM: It’s part of the localization data. The web site doesn't need to ask at r FYT: May I respond? This suggests that the server should know this information … -MCM: +MCM: FYI: On server side, I need to write the code to generate the correct direction information. -ZBI: Live use case: https://github.com/mozilla-b2g/gaia/blob/master/shared/js/intl/l20n-client.js#L31-L35. This code helped inspire the mozIntl that ended up with this proposal. I know I'm not the only one using it. In the absence of this API, people will assume only the binary choice of RTL and LTR. +ZBI: Live use case: https://github.com/mozilla-b2g/gaia/blob/HEAD/shared/js/intl/l20n-client.js#L31-L35. This code helped inspire the mozIntl that ended up with this proposal. I know I'm not the only one using it. In the absence of this API, people will assume only the binary choice of RTL and LTR. -SFC: This is already at stage 3, so if we need to make a change, we need to +SFC: This is already at stage 3, so if we need to make a change, we need to The most likely outcome is that this discussion should go into the record, but we don;t have enough to actdually change the proposal. ZBI: Shane’s comment may be comflating two different issues/aspects. @@ -254,7 +254,7 @@ ZBI: Shane’s comment may be comflating two different issues/aspects. SFC : We don’t have to answer all the questions now. Extensible is one question. The other is ….. -ZBI : You’re saying we can separate orientation from direction ? +ZBI : You’re saying we can separate orientation from direction ? Separate Myles’s concerns about exposing this API at all. @@ -290,13 +290,13 @@ ZBI via Chat: Here are some links for more context: Mozilla historically also used `isRtl` but I shifted it to `getDirection` to de-westernize the API -FYT via Chat: "goog.i18n.bidi.isRtlLanguage(lang) ⇒ boolean" +FYT via Chat: "goog.i18n.bidi.isRtlLanguage(lang) ⇒ boolean" ZBI via Chat: History on `getLocaleInfo` in Gecko: - Original bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1312053 - Request for direction for Reader mode in Firefox - https://bugzilla.mozilla.org/show_bug.cgi?id=1320265 - + This does not invalidate Myles concern, which I understand as "Mozilla l10n package should provide information on its direction, rather than just the locale name to be put through this API to retrieve the direction" But I'm wondering if Myles you see a reason for which Reader Mode in Firefox would like to at runtime/client-side get a hint on direction of the document in absence of the `dir` attribute, and in presence of the `lang` attribute, this API would help? diff --git a/meetings/notes-2021-12-02.md b/meetings/notes-2021-12-02.md index 01ad5ee2..81f9f052 100644 --- a/meetings/notes-2021-12-02.md +++ b/meetings/notes-2021-12-02.md @@ -18,7 +18,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -41,7 +41,7 @@ https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking ## Pull Requests ### Stage4 PR for intl-displaynames-v2 -https://github.com/tc39/ecma402/pull/622 +https://github.com/tc39/ecma402/pull/622 FYT: We have a slot in the next plenary agenda, PR is in review. We already have 2 browser implementations then we will ask for stage 4. This feature available in Safari? @@ -50,10 +50,10 @@ MCM: It's already available in preview version Consensus on aks for Stage 4 advancement -### Stage 4 PR for proposal-intl-extend-timezonename -https://github.com/tc39/ecma402/pull/621 +### Stage 4 PR for proposal-intl-extend-timezonename +https://github.com/tc39/ecma402/pull/621 -FYT: Same as the previous one , we have the min req. Needed to ask stage 4 advancement +FYT: Same as the previous one , we have the min req. Needed to ask stage 4 advancement #### Conclusion @@ -62,15 +62,15 @@ Consensus on aks for Stage 4 advancement ## Proposals and Discussion Topics ### Intl.Segmenter v2 for Stage 1 -https://docs.google.com/presentation/d/1ezpdee0r_ujHXDqqT4HHNYa2Q4VU7b4cMQWg6gQxLTk/edit#slide=id.p +https://docs.google.com/presentation/d/1ezpdee0r_ujHXDqqT4HHNYa2Q4VU7b4cMQWg6gQxLTk/edit#slide=id.p https://github.com/FrankYFTang/proposal-intl-segmenter-v2 -FYT : Can I have your support to ask for Stage 1 ? +FYT : Can I have your support to ask for Stage 1 ? MCM : This proposal is not sufficient to solve the actual problem and should be worked on by the Houdini task force and includes a larger scope to solve the problem. -FYT: This feature is asked by a large number of people and is already available in Safari. +FYT: This feature is asked by a large number of people and is already available in Safari. MCM: Canvas MeasureText is the wrong API to use in this particular use case. you've listed a bunch of use cases, and I'm not saying that those use cases are invalid and I'm not disagreeing with them, I'm saying that this feature should be implemented in this other place with a scope that gives them enough power to do it. We are giving the same feedback that we gave before, which is this proposal was insufficient to solve the problem at hand. And this proposal should be done with larger scope in the Houdini Working Group @@ -95,7 +95,7 @@ ZB: We can advance to stage 1 without with all this group consensus MCM: I will be on the next TC39 plenary and will bring up the same concerns I’am sharing here #### Conclusion We have a partial group agreement and are going to present at the next TC39 plenary meeting without support from Apple -### Temporal requirement to Intl.DateTimeFormat internal slots & review/Feedback - Ch15 Temporal proposal +### Temporal requirement to Intl.DateTimeFormat internal slots & review/Feedback - Ch15 Temporal proposal https://github.com/tc39/proposal/issues/622 FYT: I’m currently working on Temporal implementation and I’m asking if someone can help review this, my concerns are mostly about the Internal Slots loading multiple patterns instead of one, I'm calling attention to those aspects because it very high potential to slow down performance and increase the memory size. @@ -108,11 +108,11 @@ YSZ: I’m also working on temporal implementation and we are concerned by posib MCM and YSZ: There is not much description about this on the meeting agenda , next time would be helpful to have more information to be prepared for the meeting -FYT : My main concern is more about a procedural issue, how should we deal with this kind of problem, where Implementation find potential issues , should Temporal WG raise those or us proactively discussing them, do we need to devote time to discuss this issue here ? This this affects a huge part of the ECMA 402 , my concern it’s this goes to Temporal working group or we should look at it as ECMA-402 or on TC39. +FYT : My main concern is more about a procedural issue, how should we deal with this kind of problem, where Implementation find potential issues , should Temporal WG raise those or us proactively discussing them, do we need to devote time to discuss this issue here ? This this affects a huge part of the ECMA 402 , my concern it’s this goes to Temporal working group or we should look at it as ECMA-402 or on TC39. -ZB: The shortest path is that implementers to give feedback on Stage 3 , it’s exactly what this stage is about, FYT just uncovered the result of his implementation but other going to have similar issues, +ZB: The shortest path is that implementers to give feedback on Stage 3 , it’s exactly what this stage is about, FYT just uncovered the result of his implementation but other going to have similar issues, -ZB: Shouldn’t the Temporal working group bring this concern to the ECMA 402 meetings instead of the opposite ? +ZB: Shouldn’t the Temporal working group bring this concern to the ECMA 402 meetings instead of the opposite ? SFC: I understand the FYT concern, the idea is that ECMA-402 should be the place to discuss this with unfortunately Ujjwal is not here today to discuss that. @@ -128,19 +128,19 @@ https://github.com/whatwg/webidl/issues/1025 ZB: Your proposal seems to be indirectly related to “localizable metadata” and “localization bindings” for MF2.0, would you annotate the field or resolve it against another resource ? -APP: The name Localizable might be misleading, https://www.w3.org/TR/localizable-manifests/ , the actual focus is getting the metadata to refer to . +APP: The name Localizable might be misleading, https://www.w3.org/TR/localizable-manifests/ , the actual focus is getting the metadata to refer to . -ZB: On MF we are thinking similarly having available this meta information +ZB: On MF we are thinking similarly having available this meta information MCM: This is only immediate feedback. Adding a new string type that holds this metadata seems reasonable , it might be an object, not seeing examples of how to use this , what it’s the API or use cases for this metadata ? MCM: In case we are passing those objects each API needs to figure out the metadata that need to be applied to -ZB: I recommend raising an issue, we are interested in localizable manifests. +ZB: I recommend raising an issue, we are interested in localizable manifests. -MCM: About MF? +MCM: About MF? -APP: I think this would be more low-level and is something that they would consume +APP: I think this would be more low-level and is something that they would consume #### Conclusion @@ -149,9 +149,9 @@ Follow up offline - raise github issues about this ### Change Array.prototype.toLocaleString to use ListFormat https://github.com/tc39/ecma402/issues/422 -FYT : We already discussed that last meeting. I won't work on this anymore. Does anyone want to work on this ? +FYT : We already discussed that last meeting. I won't work on this anymore. Does anyone want to work on this ? -MCM: Why is this being dropped ? +MCM: Why is this being dropped ? FYT : Isn’t easy to come up with a good solution #### Conclusion @@ -169,7 +169,7 @@ YSZ: … ZB: … ### Intl.NumberFormat V3 Issues -RCA : Implementation feedback ? +RCA : Implementation feedback ? FYT : Updated implementation and sending to review , I see an issue on the rounding increment that it’s being difficult to implement. You can have different combinations that can produce the same output and readability issues aside from a bug already raised and validating if there is need to fix something on ICU. @@ -177,6 +177,6 @@ YSZ : Already Implemented formatRangeToParts as well and it depends on some ICU FYT : My implementation might be the issue, have to check cause on bigger numbers normally cause those issues -ZB: It’s marked as green it’s ready +ZB: It’s marked as green it’s ready diff --git a/meetings/notes-2022-01-13.md b/meetings/notes-2022-01-13.md index 9186979b..b7d524cb 100644 --- a/meetings/notes-2022-01-13.md +++ b/meetings/notes-2022-01-13.md @@ -15,14 +15,14 @@ - Yusuke Suzuki - Apple (YSZ) - Zibi Braniecki - Invited Expert (ZB) - Myles C. Maxfield - Apple (MCM) -- Younies Mahmoud - Google i18n (YMD) +- Younies Mahmoud - Google i18n (YMD) - Richard Gibson - OpenJS Foundation (RGN) ### Standing items - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -37,7 +37,7 @@ USA: Happy ISO 2022 new year! Thank you RGN for amazing editorial work. The big Presenter: RCA -- Runtime behaviour document - https://docs.google.com/document/d/1lCSg7H_Nz20_LITon3g12Iq5KtE9cxXTg58zyLeW3gw/edit originated by previous the discussion about Message Patterns https://www.google.com/url?q=https://github.com/unicode-org/message-format-wg/issues/212&sa=D&source=docs&ust=1642100404806359&usg=AOvVaw0P4Ojl-X0F1i8wM7UvfZrd +- Runtime behaviour document - https://docs.google.com/document/d/1lCSg7H_Nz20_LITon3g12Iq5KtE9cxXTg58zyLeW3gw/edit originated by previous the discussion about Message Patterns https://www.google.com/url?q=https://github.com/unicode-org/message-format-wg/issues/212&sa=D&source=docs&ust=1642100404806359&usg=AOvVaw0P4Ojl-X0F1i8wM7UvfZrd - Case Selection - https://docs.google.com/document/d/1nT-_-ZMknbtKvUc9lR9v9esOGiXK-OOPwJv7Ccl-2EI/edit#heading=h.6x3fflpb0yjs - ECMA-402 Champions (EAO, DLM) - Roadmap - https://github.com/unicode-org/message-format-wg/wiki/Roadmap-2022 @@ -54,7 +54,7 @@ RCA : Wiki is updated and major milestones are Intl. Segmenter MDN and Intl.Dura https://github.com/tc39/ecma402/pull/614 -USA: The list of numbering systems in the spec is out of date. There is a new numbering system, "tsna". This PR is from Anba who wants to make sure we are in sync. There is a comment from JSC team asking us to wait. What’s the status ? +USA: The list of numbering systems in the spec is out of date. There is a new numbering system, "tsna". This PR is from Anba who wants to make sure we are in sync. There is a comment from JSC team asking us to wait. What’s the status ? YSZ : We did not want to merge it until ICU shipped it. @@ -64,7 +64,7 @@ YSZ : I think it is ok. It is in ICU now. #### Conclusion -USA : We can merge this one +USA : We can merge this one ### Normative: Add Intl.Segmenter #553 @@ -76,7 +76,7 @@ GPT: I think it's useful to have consistency in the spec text, but I don't have USA: I'll just ask RGN to do what he thinks is best. -FYT : My preferences it’s to land whatever we have now, we are close to the publish deadline, and this is a minor editorial issue that we can address later. This change does only affects the location of the section not text itself +FYT : My preferences it’s to land whatever we have now, we are close to the publish deadline, and this is a minor editorial issue that we can address later. This change does only affects the location of the section not text itself SFC : Ideally we should apply RGN's suggestion, but if we cannot make ECMA deadline the best it’s to keep as is @@ -84,7 +84,7 @@ RGN: If we come to agreement on these changes, I can have a PR likely by the nex USA: I don't have strong opinions, and others don't have strong opinions, so I think you should make the PR. -EAO: It would be useful to have a document/contributing guideline to help you when writing the spec(Best practices etc …) ? +EAO: It would be useful to have a document/contributing guideline to help you when writing the spec(Best practices etc …) ? RGN: It has been a goal of mine to create just that since I started working on ECMA-402. The biggest obstacle is what aspects belong in the spec itself as opposed to adjacent to it. The idealized form of a section likely belongs in contributing guidelines. @@ -118,9 +118,9 @@ FYT: I was convinced by SFC that my proposed solution isn’t good, but his prop GPT: It’s better to be more restricted now since we always have the option to relax it later. -EAO : Can we relax it later if we don’t require it ? +EAO : Can we relax it later if we don’t require it ? -SFC: *points out the options* exceptions are the most forward compatible.I tend to Require and throw exception +SFC: *points out the options* exceptions are the most forward compatible.I tend to Require and throw exception RGN: I think I support this. I'm trying to remember if this is covered by the earlier discussion about the interaction on fraction and significant digits. But if we gate on the presence of the property, I support. @@ -153,19 +153,19 @@ SFC : That’s correct GPT: It seems like in the past, you want to have it be on the locale side. I'm unsure. -FYT: Hints suggest that locale may or may not have value , but in local model all the values has a resource fallback, writing this as an a hint , might never been use +FYT: Hints suggest that locale may or may not have value , but in local model all the values has a resource fallback, writing this as an a hint , might never been use -SFC : If we have useGrouping = auto all fallback to use grouping separators , min2 instead fallback to the root will fallback to a min of 2 digits but some locales has more than 3 digits +SFC : If we have useGrouping = auto all fallback to use grouping separators , min2 instead fallback to the root will fallback to a min of 2 digits but some locales has more than 3 digits FYT: If I have en-Deva-IN. If that has a value, but en-Deva has a different value, and en has a different value, which one do we obey? There are different levels of fallback. SFC: There is no data for this, it’s a spec issue, once we find user preferences for that locale using those preferences , useGrouping overrides the lowest locale values in case local value is 1 we set it to 2. Other proposal it’s always set to two. I prefer set it to at least minimum 2. -FYT: Why we are changing this ? what’s the key motivation for this change ? +FYT: Why we are changing this ? what’s the key motivation for this change ? SFC : The motivation was when writing test262 was difficult to predict the behaviour to be more testable, I’m not asking for a change I’m trying to have consensus on this. -Should we change for the proposed behaviour or keep it as it is ? +Should we change for the proposed behaviour or keep it as it is ? SFC: Close the issue? @@ -215,7 +215,7 @@ FYT : I don’t understand in which condition we won’t be able to represent th USA: Days are not always 24 hours long; they can be 23 or 25, which means it depends on where you count from. -FYT : We are talking about differences between daylight saving time ? same issue also apply to leap seconds +FYT : We are talking about differences between daylight saving time ? same issue also apply to leap seconds USA: Say you have a ZonedDateTime that starts before a daylight boundary. You have a duration that is 0.5 days. If you add that duration to it twice, you expect the exact same time one day after, but you don't get the exact same time. What if you take the same time and take the difference and divide by two? I think it would be confusing for arithmetic. @@ -239,7 +239,7 @@ EAO: Same opinion , it’s ok to proceed as is, but it’s good to have a possib #### Conclusion -USA : I will try to come up with a spec text modification to demonstrate this possibility +USA : I will try to come up with a spec text modification to demonstrate this possibility ### Should we accept '_' in identifiers? @@ -265,7 +265,7 @@ SFC: I would like to YZS , USA and FYT to follow up offline to correct this FYT : I can do a PR but this would be a normative PR -### Intl Segmenter V2 for Stage 2 +### Intl Segmenter V2 for Stage 2 - [Slides](https://docs.google.com/presentation/d/1BJl99uYveimKrMw605KyaZ0qLthIhNaqONDPwdYH53A/edit#slide=id.g1085d0d2c96_0_204) diff --git a/meetings/notes-2022-02-10.md b/meetings/notes-2022-02-10.md index 4aeee5d5..6feb3a94 100644 --- a/meetings/notes-2022-02-10.md +++ b/meetings/notes-2022-02-10.md @@ -20,7 +20,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -29,11 +29,11 @@ ### Editor's Update -USA: Updates Intl.Segmenter to Stage 4 +USA: Updates Intl.Segmenter to Stage 4 ### MessageFormat Working Group -RCA: We are having Extended meetings again in a weekly basis to cover +RCA: We are having Extended meetings again in a weekly basis to cover - [ ] Aliases / macros to expressions (#220) - [ ] Message references vs. aliases to message fragments (#221) @@ -44,10 +44,10 @@ RCA: We are having Extended meetings again in a weekly basis to cover - [ ] Metadata and comments - [ ] Container format -Extended Meetings +Extended Meetings Prev. summary - https://github.com/unicode-org/message-format-wg/issues/220 - Next meeting agenda and questionnaire + Next meeting agenda and questionnaire - https://github.com/unicode-org/message-format-wg/issues/221 - https://forms.gle/D9vVAHXxjXoq3hLP6 @@ -55,7 +55,7 @@ Intl.MessageFormat EAO: Feedback from CLDR-TC about MFWG proposals to help unblock progress , by extending the recurrence of meetings we expect to improve the progress and move further fast -## Temporal Presentation +## Temporal Presentation PFC : Presenting [Slides](http://ptomato.name/talks/tc39tg2-2022-02/) about temporal @@ -75,11 +75,11 @@ USA: Sounds good , the question it’s if we are generally supportive of this id SFC: The idea was that we don’t want to add a new API for that. We already had this proposed in DisplayNames v2, and we decided not to move further due the complexity. In ICU4X, we’re also working on a TimeZoneFormat class. There’s an argument to be had to bring that to ECMA-402. But ECMA-402 already has a lot of control over time zone display names. The extend-timezone-name proposal added more time zone display options, and I think we should stick with that. -USA: It makes sense to keep as is know, I believe it's fairly complicated to to write a, you know, a to come up with a snippet of code, that would localize a time zone, right? So, so I think the merits of something like a tulocal, string that sort of does this for you already. +USA: It makes sense to keep as is know, I believe it's fairly complicated to to write a, you know, a to come up with a snippet of code, that would localize a time zone, right? So, so I think the merits of something like a tulocal, string that sort of does this for you already. JGT: Temporal would be supportive for that, I assume that work would be on the 402 side, It might be a starting point to add support for time zones in DisplayNames. -USA: Is it the case that the instant changes the localized name of the time zone? +USA: Is it the case that the instant changes the localized name of the time zone? JGT: Yes, because depending on the display options, it could be "Pacific Standard Time" versus ""Pacific Daylight Time". @@ -92,7 +92,7 @@ PFC: I was wondering if it would be helpful to open an issue in Temporal v2. We SFC : Yes, agree on having an issue. As for the question, what is the canonical name of a time mzone? I'd say there is no canonical name. We have the "generic" name Pacific Time, which CLDR calls the "metazone". But you have things like America/Indiana/Indianapolis that switches between Eastern Time and Central Time depending on the instant. The closest thing we have to a canonical display name is what CLDR calls the "exemplar city display name", e.g. "Paris Time". We currently don't carry that data because no-one could present a compelling use case for assuming the burden of that large data size. I agree with the spirit of time zone display names, but there needs to be more discussion and a compelling use case. USA: I understand the complexity and supportive to start a discussion, in the case where we localize a single time zone, a question it’s what’s the expected output ? also think the localization should be a kind of 1:1 mapping applying to al set of time zones. But looks that at least calendar.tolocalString would be easier and have more support. - + Additional CC excerpt: > he should apply for for the whole time zone and not just Periodically to that @@ -122,7 +122,7 @@ JGT: My memory of this is that there are 2 issues. (1) could we enumerate the er LAF: I believe you're right, JGT. -USA: We talked about numeric questions , and we had consensus of not having numeric identifiers due that cannot be generally applied to all calendars, About LAF arguments, they agree that it’s problematic for Japanese calendars, might be supported in future by Temporal and ICU4X. Some calendars like Ethiopian calendar has eras but they also has errors which means that there is an invisible negative on error in these calendars +USA: We talked about numeric questions , and we had consensus of not having numeric identifiers due that cannot be generally applied to all calendars, About LAF arguments, they agree that it’s problematic for Japanese calendars, might be supported in future by Temporal and ICU4X. Some calendars like Ethiopian calendar has eras but they also has errors which means that there is an invisible negative on error in these calendars JGT: I think this is a problem of how to display an ordered list of localized strings, and an ordered list of string identifiers for eras. If there were a display names proposal for eras, this is what would be in it. @@ -167,11 +167,11 @@ USA: This is part of a bigger story of how to deal with non-=Gregorian calendars JGT: There is a kind of two sets of behavior to specify: How do all calendars behave, and how do specific calendars behave? The second area is out of scope for this PR, but is something interesting to look at in the future. -USA: We are also working on this second area, but it’s unclear if it’s also in scope for temporal, we might address this question later on, I ask for the group to give feedback on this PR +USA: We are also working on this second area, but it’s unclear if it’s also in scope for temporal, we might address this question later on, I ask for the group to give feedback on this PR LAF: I want to understand the consequences. Is the question whether we should support… should all the built-in calendars be supported? Or is it a question about… we should have more information about calendars? I want to understand what is required here. As far as I understand, in Unicode, there are 5 muslim calendars. I'm not sure they are all used. And there is not even the Julian calendar, which is the reference calendar for all European calendars from a historical point of view. -USA: You mean your question it’s intended for the calendar specific parts ? +USA: You mean your question it’s intended for the calendar specific parts ? LAF: Yes @@ -189,11 +189,11 @@ EAO: Presenting [Slides](https://docs.google.com/presentation/d/1oThTeL_n5-HAfmJ SFC: I do have a couple of questions. First, about the shape of the API. The Temporal proposal added 7 new types (primordials). But primortials are somewhat costly to implementers. It looks like this proposal introduces even more classes. If you can change the data-focused classes to be Records & Tuples, it would align with editors' vision of ECMAScript -EAO: The actual proposal only has 2 primordial classes, these are MessageFormat and MessageResource, the MessageValue in particular has the type string, so that can be built as records. +EAO: The actual proposal only has 2 primordial classes, these are MessageFormat and MessageResource, the MessageValue in particular has the type string, so that can be built as records. USA: The main motivation of resistance against adding Primordial are because every new Primordial deed to do extra work. This could be bring major concerns, the ideal would try to have subclasses instead and won't raise so many concerns. -SFC: The second question it’s about why you were thinking that MessageFormat Resource functions should be mutable. Intl objects are immutable with only a few exceptions. Why do you think that we should have a mutable function here? +SFC: The second question it’s about why you were thinking that MessageFormat Resource functions should be mutable. Intl objects are immutable with only a few exceptions. Why do you think that we should have a mutable function here? EAO: MessageFormat unlike the existing formatters fundamentally builds on user data. It is currently structured in a way that it would not be deeply frozen so the customizability of the data would depend on whether we want this or not, since this is a JavaScript invariant. @@ -229,7 +229,7 @@ https://github.com/tc39/proposal-intl-eradisplay/issues/7 LAF : (introduced the issue) -SFC: I want to have more input on this topic JGT , USA ? +SFC: I want to have more input on this topic JGT , USA ? JGT: I think this is interesting, apparently there is a straightforward work around that you can do it with some logic, in Temporal we have the ability to to compare the same localized year in that particular calendar, for me, the highest priority is hiding the auto option: hiding the "CE". I think it's interesting to do the other one, but since there's a workaround that's fairly straightforward, it seems like a lower priority. @@ -239,11 +239,11 @@ SFC : How do you implement those fields, my thoughts are about how to implement GPT: I think that would make me nervous: there is already some complexity. The current spec already includes a pattern in there. In SM, we do it in a way that reduces burden, but this would add more complexity and maintenance cost. -SFC: Perhaps we could design this in a way that would scale? +SFC: Perhaps we could design this in a way that would scale? GPT: I was thinking of maintenance cost: era is definitely harder to deal with.era it’s difficult to work with, if i had to handle that case more automatically by providing more quality results would be nice, maybe separating out the proposal would be better for the more general use case -USA: +USA: JGT: I don’t see this as a common use case to justify a built-in diff --git a/meetings/notes-2022-03-17.md b/meetings/notes-2022-03-17.md index d92065cd..e60cf906 100644 --- a/meetings/notes-2022-03-17.md +++ b/meetings/notes-2022-03-17.md @@ -21,7 +21,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -42,7 +42,7 @@ RCA : We’ve been meeting with CLDR-TC working on the three existing proposals, EAO: The MessageFormat 2.0 spec may not include a message bundle spec. Which means we would need to think about what this means for the ECMA proposal. Do we add parsing for a single resource, or do we create the bundle spec elsewhere? -SFC : Those are really good questions , when CLDR-TC discussion it’s over it’s a good moment to have those issues discussed +SFC : Those are really good questions , when CLDR-TC discussion it’s over it’s a good moment to have those issues discussed EAO: Mentioning this now because it’s likely to happen but it hasn’t happened yet. @@ -58,7 +58,7 @@ Some of these PRs look old and this needs another pass. RCA: A few things were worked on more recently, will update. -USA: The Stage 3 proposals have been implemented in JSC. Is that correct ? +USA: The Stage 3 proposals have been implemented in JSC. Is that correct ? YSZ : Yes I’ll update the Table with to reflect the actual status of Intl.Locale Info , NumberFormat v3 and Intl Enumaration @@ -196,7 +196,7 @@ Presenter: YMD YMD: Presents slides -YMD: In order to make Intl locale-aware units conversion +YMD: In order to make Intl locale-aware units conversion ZB: ??? @@ -240,7 +240,7 @@ YMD: There are multiple systems across the world, not just the imperial system. USA: Another thing is, how high-level do we want this API to be? Do we want an API that does unit conversion, or do we want an API that takes values in meters and localizes it, as a complete black box? -YMD: We need a lower level of abstraction for many reasons, +YMD: We need a lower level of abstraction for many reasons, SFC: YMD already made such a black-boxed proposal previously, which is still in Stage 1; however, we didn’t manage to make progress on it due to the lack of user preferences. Some TC39 delegates said that the unit preferences proposal did not have sufficient value on its own without user preferences; there were concerns regarding how high quality the results would be. Some folks for example would prefer to have specific precision when dealing with the conversions. Another example would be the BMI calculator that YMD talked about in the slides. Therefore, I think there’s a strong rationale behind the proposal as it is. @@ -310,7 +310,7 @@ RGN: When you have a non-integer number with separators, ICU would want that to MCM: On this topic, in Apple frameworks, we have a whole system for solving this prohbnlem. It's a framework called DatDetectors, and its job is to find structured items in text like phone numbers and URLs. So I feel this is a larger problem than just email addresses. It also detects flight numbers, etc. Recognizing regular numbers is also a complicated task. So I feel that this problem may be out of scope for this particular API. If you want an API that is smarter about structured data, you should use a differn toslution. -SFC: The main bit we want to solve is web compatibility. I know this is a problem since Chrome works in a different way than Firefox and WebKit. +SFC: The main bit we want to solve is web compatibility. I know this is a problem since Chrome works in a different way than Firefox and WebKit. MCM: Another solution we haven’t discussed so far is that Chrome can roll back its change and restore web compatibility. diff --git a/meetings/notes-2022-04-21.md b/meetings/notes-2022-04-21.md index 6158ef25..2b5b7728 100644 --- a/meetings/notes-2022-04-21.md +++ b/meetings/notes-2022-04-21.md @@ -19,7 +19,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -40,13 +40,13 @@ YSV: I have to check with Brian how to coordinate the update of ecmarkup, we hav EAO: About in-flight proposals… at what stage do they get covered by the permissive license? Are we guaranteed that all in-flight proposals will be able to be adopted with the permissive license? -YSV: The repositories hold a copyright ? +YSV: The repositories hold a copyright ? -USA : They use the author copyright +USA : They use the author copyright YSV: Up until now, the only way you had a right to make a derivative work was if it was intended to be merged back into the standard. By virtue of being a derivative work, you're already covered by the ECMA copyright. I think there are no issues. -USA: Ecmarkup generates copyright text for both proposals and spec +USA: Ecmarkup generates copyright text for both proposals and spec EAO: How do champions transition the copyright to ECMA? @@ -95,7 +95,7 @@ USA: ICU4X can be used in a web application after being compiled into WASM. SFC: By the end of 2022, ICU4X will be a polyfill for many of the items on this list, including Display Names. -USA: Given this situation, it may be more prudent to get help on ICU4X rather than doing additional work on JS implementations. +USA: Given this situation, it may be more prudent to get help on ICU4X rather than doing additional work on JS implementations. SFC: I agree , but I believe that it still makes sense to have a JS implementation of polyfill while people do the transition. LHO has not had time lately to work on this. @@ -144,7 +144,7 @@ FYT: Not working on this recently. Temporal has problems making implementation d The particular part of changes of Intl.DateTimeformat , where they need to handle different types of patterns related with Temporal we might focus on those changes in future -USA: Jordan already reviewed and pointed that it’s awkward how dependencies of those two proposals work +USA: Jordan already reviewed and pointed that it’s awkward how dependencies of those two proposals work USA: Will talk with the editors re: the proposal to resolve issues. @@ -174,7 +174,7 @@ SFC: At this time I’m not aware of any external dependencies ## Proposals and Discussion Topics -### Intl.DateTimeFormat.prototype.formatToParts ( date ) using eraDisplay - patterns or last time deletion +### Intl.DateTimeFormat.prototype.formatToParts ( date ) using eraDisplay - patterns or last time deletion https://github.com/tc39/proposal-intl-eradisplay/issues/4 @@ -217,7 +217,7 @@ USA: One thing to point out - ignoring the question of capability, focusing on s SFC: More issues on this topic? If not, assume that we’ll move forward with what I proposed for the Stage 2 proposal. -USA: Would it be possible to work editorially to avoid the duplication. Temporal takes patterns that we had and duplicates. Addition of more slots requires +USA: Would it be possible to work editorially to avoid the duplication. Temporal takes patterns that we had and duplicates. Addition of more slots requires them in multiple places, not quite doubling the number of slots. SFC: these two proposals are moving forward in parallel. They should be resolved later, not resolving at this time, but to be resolved later with Temporal. @@ -234,16 +234,16 @@ https://github.com/tc39/proposal-intl-enumeration/issues/45 FYT: Must now include Gregorian. Temporal champions suggest that ISO-861 is more precise. Should we include both Gregorian and ISO-861? USA: If it’s useful i can give some context on this , one of the reason that Temporal champions decided to depart form unset convention because they knew that they had to specify IS0-8601 , I fell that Gregory will behave not so differently from the ISO-861. Do we use the IS0-8610 ? or we should keep the Gregorian calendar ? … Ujjwal - + USA: Later a completely specified calendar could be used but for now, “gregory” is usable even though it’s defined by implementation. ISO-8601 (aka “Proleptic Gregorian”) -SFC: We are looking to Temporal spec , can we ask someone (champions) why this still like this on the spec ? +SFC: We are looking to Temporal spec , can we ask someone (champions) why this still like this on the spec ? FYT: Other parts have been amended. This should not have any observable behavior. -USA there may be some edge cases in which Gregory and other implementations may have some visible differences. +USA there may be some edge cases in which Gregory and other implementations may have some visible differences. LFA: Gregory is not specified, but ISO-8601 is specified. For this reason, we should refer to the 8601. At this point, there’s no observable difference between them. As a matter of fact, the current ISO calendar doesn’t stick to the standard, but we should do that moving forward. @@ -254,21 +254,21 @@ SFC: The reference to gregory in ECMA-402, we shouldn’t use that to influence FYT: The reason I’ve used gregory here instead of iso8601 because before Temporal reaches Stage 4, there’s no reference to this calendar. (discussion notes here) -In the proposal we look into the available class and we have 3 options +In the proposal we look into the available class and we have 3 options 1 . Keep this to be just gregorian. 2. A normative change to say this list must include both calendars -3. We must change Gregorian to ISO-8601 +3. We must change Gregorian to ISO-8601 EAO: If The gregorian calendar is not specified we should use ISO-8601? USA: For all practical purposes the ISO 8601 aligns with Gregory. However, the holes in how the Gregorian calendar should behave can motivate us to use 8601. More “duct taping” on Gregorian may make more of a mess. -SFC: Biggest difference is that Gregory has eras while 8601 has negative years. +SFC: Biggest difference is that Gregory has eras while 8601 has negative years. -FYT : The main diff they don’t have same +FYT : The main diff they don’t have same “Starting” days of the week ? RGN: Formatting and conception are actual differences @@ -285,19 +285,19 @@ SFC: In practice, “gregory” will be on the list (along with “buddhist”, LAF: Don’t forget that at present time when you try the buddhist and japanese calendar for 1st January of year 1 you still have different results from those calendars due the fact that implementation uses Julian calendar, this is another reason that we should use ISO-8601. Being the reference calendar before the 16th century. I support the ISO 8601 and gregorian it’s a case that should be implemented after all. -SFC: Should we move ISO-8601 without Gregorian ? +SFC: Should we move ISO-8601 without Gregorian ? 1 . Keep this to be just gregorian. 2. A normative change to say this list must include both calendars -3. We must change Gregorian to ISO-8601 +3. We must change Gregorian to ISO-8601 #### Conclusion Use "iso8601" only. -### CollationsOfLocale() order #33 +### CollationsOfLocale() order #33 https://github.com/tc39/proposal-intl-locale-info/issues/33 diff --git a/meetings/notes-2022-05-19.md b/meetings/notes-2022-05-19.md index 0386fe6b..a1d9203f 100644 --- a/meetings/notes-2022-05-19.md +++ b/meetings/notes-2022-05-19.md @@ -21,7 +21,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -36,7 +36,7 @@ FYT: Do we have the PDF of the 2022 edition? Are the tables working this year? USA: There's a draft PDF on the reflector issue. It seems that ECMA is trying to get professional help. -RGN: https://github.com/tc39/ecma402/releases/tag/es2022-candidate that includes PDFs: https://github.com/tc39/ecma402/releases/download/es2022-candidate/ECMAScript.2022.Internationalization.API.Specification.pdf and https://github.com/tc39/ecma402/releases/download/es2022-candidate/ECMAScript.2022.Internationalization.API.Specification.-.A4.pdf +RGN: https://github.com/tc39/ecma402/releases/tag/es2022-candidate that includes PDFs: https://github.com/tc39/ecma402/releases/download/es2022-candidate/ECMAScript.2022.Internationalization.API.Specification.pdf and https://github.com/tc39/ecma402/releases/download/es2022-candidate/ECMAScript.2022.Internationalization.API.Specification.-.A4.pdf ### MessageFormat Working Group @@ -50,7 +50,7 @@ EAO: We're hoping to avoid large sets of options and address individual issues. SFC: What are the plans to address the comments on the slide deck? -EAO: Specific comments were migrated to individual issues on the repo. +EAO: Specific comments were migrated to individual issues on the repo. https://github.com/unicode-org/message-format-wg/issues?q=is%3Aissue+is%3Aopen+label%3Asyntax @@ -81,7 +81,7 @@ SFC: There are still a lot of other PRs in the spreadsheet. RCA: Will look at these. GPT: Re: SpiderMonkey and Segmenter. When Ting-yu gets back from parental leave, this will be picked up again. -USA: We should create a new header from next year’s ECMAScript ? +USA: We should create a new header from next year’s ECMAScript ? SFC: LocalInfo and Enumeration still in stage 3? To be merged? Maybe stage 4 candidates? @@ -93,7 +93,7 @@ FYT: Some implementation issues remain, but handling of string is moving forward SFC: DurationFormat? -USA: Yes, making progress on DurationFormat. There is a discussion that i added to the agenda for today, +USA: Yes, making progress on DurationFormat. There is a discussion that i added to the agenda for today, FYT: Temporal has lots of things needing discussion in 402. These issues should be tracked here, especially things in Section 15. THere is no mention here of Temporal. E.g., Era, etc. should be made visible to this community. @@ -105,7 +105,7 @@ USA: Intl part of the proposal is somewhat neglected that would benefit from dis SFC : In February, we did a deep dive about Temporal in this meeting. I think it would be useful add parts to track in our wiki, but material discussions should happen in the Temporal champions meeting -https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-02-10.md#temporal-presentation +https://github.com/tc39/ecma402/blob/HEAD/meetings/notes-2022-02-10.md#temporal-presentation SFC: It may be useful to add USA’s work on the Calendar spec here. FYT is working on this in ICU. We are waiting on this for our work. It would be helpful to track this in our document. @@ -178,7 +178,7 @@ SFC: Re: existing limits, maximum significant digits is set to 21, rather low. B FYT: First, the string format is the same as the grammar of Number. The grammar can express an Infinity value. But in 262, once you reach a very large number, it treats the value as infinity. -The second thing is that whenever the value gets too large, we have this MAX_SAFE_INTEGER value which says that the precision beyond it is not very accurate. It’s still usable though. In some ways, we have precedence in 262 for this. We may choose not to throw, but it’ll definitely cause some unex pected side-effects. They have different effect when they’re beyond that value , current proposal already has a minimum/maximum value +The second thing is that whenever the value gets too large, we have this MAX_SAFE_INTEGER value which says that the precision beyond it is not very accurate. It’s still usable though. In some ways, we have precedence in 262 for this. We may choose not to throw, but it’ll definitely cause some unex pected side-effects. They have different effect when they’re beyond that value , current proposal already has a minimum/maximum value We need to think about wether it’s even needed to have that power. Let’s say I use a 64-bit integer to store it but there’s always a limit. Should we pick a reasonable boundary then? If we have no use-cases for something as big as a 64-bit exponent, why bother going that far since you have that limit anyway. @@ -205,7 +205,7 @@ Given a string, may possibly convert to integer type. If there’s a magical way SFC: For stack allocation, rule of thumb is about 500 bytes to prevent overflow. -FYT: You will have 45 bytes of… I agree. You may choose to do it this way. It’s limited, not infinite. +FYT: You will have 45 bytes of… I agree. You may choose to do it this way. It’s limited, not infinite. It’ll be tricky how to check. If you set a limit on the number of digits. If your spec would like to do that, then you’d need an adding algorithm. It is necessary to write methods to check whatever limits are set, This may be very complicated. Need to parse the string, finding the decimal point. The algorithm will be more complicated. @@ -255,13 +255,13 @@ OK to add limits. SFC to follow up with a specific PR. https://github.com/tc39/proposal-intl-numberformat-v3/issues/97 -YSZ: THe problem is that when max and min fraction digits are different, an error is thrown with roundingIncrement. What do we think about +YSZ: THe problem is that when max and min fraction digits are different, an error is thrown with roundingIncrement. What do we think about FYT: it’s very difficult for the user to figure out how to use this. SFC: We already have an example of setting min/max to different values in some cases. One way to fix this is to set min/max to zero since default is zero. -FYT: If we set it to zero, it’ll fix it? +FYT: If we set it to zero, it’ll fix it? SFC: That fixes the issue where the roundingIncrement is set by itself. @@ -314,7 +314,7 @@ USA: This is regarding intl duration formation (originally PR #92). #92 was inte However, it’s going to be very difficult to implement this in a pre-Temporal world. There’s effectdively a chain of references that need to be implemented. -We can recognize the dependency explicitly. However, it requires lots of work that is effectively large parts of Temporal. +We can recognize the dependency explicitly. However, it requires lots of work that is effectively large parts of Temporal. Does this match with what implementers think about this? Is it possible to ship DurationFormat without Temporal? @@ -336,14 +336,14 @@ USA: The original intent was to be decoupled. PR#92 was merged 28 days ago. That FYT: CUrrently Duration is S3, Temporal is S3. They depend on each other (Ch. 15 of Temporal). Should we merge these? We already have a big piece of Temporal implemented now that we support string, now that we need the grammar. Now we need a parser to move forward. -USA: Let me clarify there is 3 ways forward +USA: Let me clarify there is 3 ways forward 1. DurationFormat it’s very difficult to implement without temporal - and will be shipped after temporal 2. If temporal can ship a duration formatter that way would be more independent from Temporal 3. We don’t want to do this, and we really want to ship DurationFormat before Temporal, with only option bags. This works. SFC: It the only dependency is on input type, then we should decouple them. That’s easy and can be done. -The thing really concerning is the editor’s note re: question about doing arithmetic - expects Yes or No as answers. The specification doesn’t indicate this. +The thing really concerning is the editor’s note re: question about doing arithmetic - expects Yes or No as answers. The specification doesn’t indicate this. USA: There should be text answering this - looking at DurationFormat spec. @@ -357,7 +357,7 @@ FYT: without string form supported, agree that these can be separate. SFC: Who were the S3 reviewers on this? There seem to be holes that should have been handled at S2. Handling these at S3 breaks the process because the linkage wasn’t resolved in the promotion from S2 to S3. -FYT: Still somehow DF progressed to S3 but should not have before resolving exact AOs (dependencies). Missing that means that it’s not clear at S3. +FYT: Still somehow DF progressed to S3 but should not have before resolving exact AOs (dependencies). Missing that means that it’s not clear at S3. USA: Was not aware that there should not be such dependencies between two S3 proposals. Reviewer’s did not flag it. @@ -369,7 +369,7 @@ SFC: Is removing the editorial note OK? USA: Will keep this “pre-Temporal” as a separate proposal. -FTY: What do we need to do to DurationFormat to keep these separate? Do +FTY: What do we need to do to DurationFormat to keep these separate? Do SFC: Want’s to flip dependencies around, making Temporal dependent on DurationFormat. diff --git a/meetings/notes-2022-06-16.md b/meetings/notes-2022-06-16.md index d4e94ef2..03d9ea27 100644 --- a/meetings/notes-2022-06-16.md +++ b/meetings/notes-2022-06-16.md @@ -14,7 +14,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -54,7 +54,7 @@ FYT: The real question is is this will make it into 2023 version, February. We w SFC: It’s good to land the proposal in the fall if possible. -FYT: This is not a tiny proposal , we should give time for editors to review +FYT: This is not a tiny proposal , we should give time for editors to review SFC: Any updates on Duration Format? It’s been at Stage 3 for a year, stable. It’s waiting. @@ -124,7 +124,7 @@ CRN: I expect “1.00”, based on minFraction. SFC: describes how this actually works with implicit maximum significant digits. Because min Sig Digits is indicated, fraction digits is ignored, so 2 significant digits is all the counts → “1.0”. -CRN: Should this be disallowed when they have conflicts ? +CRN: Should this be disallowed when they have conflicts ? SFC: roundingPriority is the way to indicate which wins. Depends on what roundingPriority actually means. @@ -183,7 +183,7 @@ What are the use cases? Intl.Collator doesn’t allow “standard” and “sear SFC: This is a fun problem but we apparently aren’t ready to decide. FYT made proposal #36 last year to excluded “standard” and “search” . -FYT : We also it’s mentioned in the [#31]() , we can consider the first items are implicitly defaults ones, so we don’t have any +FYT : We also it’s mentioned in the [#31]() , we can consider the first items are implicitly defaults ones, so we don’t have any Additional sorting we do not list there SFC: the first entry of the list should be what the Intl Collator does in effect. Gives an example in inspector, showing how Chrome’s Intl.Collator(“en”... ) works. Trying with ‘zh-TW’ and various options. Trying with “zh-CN”, which gives “pinyin” as default. Trying with “en-u-co-emoji”. @@ -210,7 +210,7 @@ Added note in #33 asking about option b. above. FYT: would there then be “default” at the start of every list? This collations would only return that if it is in the right order you have an implicit default -SFC: “default” at the beginning? What is the default for “zh-CN”, for “en”? The first default should be spelled out rather than be implicit. +SFC: “default” at the beginning? What is the default for “zh-CN”, for “en”? The first default should be spelled out rather than be implicit. #### Conclusion @@ -222,7 +222,7 @@ https://github.com/tc39/ecma402/issues/656 SFC: last discussed at March meeting. -FYT: Long ago, in Chromium, patch was made to break differently. The patch has been inherited and the desire is to break differently. Should this be treated as spec problem or as a bug in V8 ? +FYT: Long ago, in Chromium, patch was made to break differently. The patch has been inherited and the desire is to break differently. Should this be treated as spec problem or as a bug in V8 ? SFC : What do you mean by that ? @@ -236,16 +236,16 @@ SFC: What we agree that what should be needed to get specified its a bit fuzzy , RGN: we effectively have this because we defer to Unicode. -FYT : This is an issue because in V8 we have this patch - this it’s a bug in V8 not a spec issue +FYT : This is an issue because in V8 we have this patch - this it’s a bug in V8 not a spec issue SFC: We already have a note (in prose) that is clearly not sufficient. We could tighten the text in ecma402/segmenter-objects. My proposal it’s to modify this prose to be more specific about correct behavior with URL’s. RGN: We could make a PR, but it’s purposely under-specified. But it does reference to the default rules and default rules do not permit identification of a break inside of a domain name, WB6 and WB7 in Unicode TF29 -SFC : This a chrome bug , we agree +SFC : This a chrome bug , we agree -FYT : Would be helpful have test262 that covers this +FYT : Would be helpful have test262 that covers this RCA : Yes we can add it diff --git a/meetings/notes-2022-07-07.md b/meetings/notes-2022-07-07.md index a6832779..4f34d759 100644 --- a/meetings/notes-2022-07-07.md +++ b/meetings/notes-2022-07-07.md @@ -17,7 +17,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -26,24 +26,24 @@ ### Editor's Update -USA : No updates except for the fact we have a draft for the .pdf version of the spec. We are trying to get some help on publishing it and we expect to have it soon. +USA : No updates except for the fact we have a draft for the .pdf version of the spec. We are trying to get some help on publishing it and we expect to have it soon. -RGN : Enums PR are replacing language values, following 262 conventions. +RGN : Enums PR are replacing language values, following 262 conventions. FYT: Can you show an example? SFC: Is there a PR? RGN: https://github.com/tc39/ecma402/pull/689/files and https://tc39.es/ecma402/#sec-getoption this change might be propagated by the spec as soon we have an opportunity to do it. - -SFC: Interesting how the EC Markup decided to use sans-serif to style enum values - + +SFC: Interesting how the EC Markup decided to use sans-serif to style enum values + RGN : Yeah there are a lot of styles not very well documented bold , italic etc … - + FYT: Are the long tables in the PDF fully visible? RGN: Yes. - + FYT: The issue is the number systems table and units tables are broken. SFC: The tables wrap now. @@ -66,7 +66,7 @@ FYT: My proposal is already tracked in Stage 0 proposals page. There’s a link SFC: Are you ready to talk about Temporal today? -FYT : We can talk about it later , I wanted to get some feedback from the group +FYT : We can talk about it later , I wanted to get some feedback from the group SFC: Sounds good @@ -74,7 +74,7 @@ SFC: Sounds good FYT: Intl.NumberFormat V3 will ship in Chrome soon. I missed 105 shipping but will propose ship it on Chromium 106 mid september -SFC: Do you know if V8 reflects actual spec +SFC: Do you know if V8 reflects actual spec FYT : It should reflect current spec text @@ -92,8 +92,8 @@ FYT: One problem with exponents. If ICU would have a limitation, would we follow SFC : The proposal it’s limit it to 10k exponent otherwise Infinity , that’s right FYT? -FYT: First issue it’s that this might if this it’s an observable behavior or not , we can consider observable if that format we use Infinity, -When we use ICU implementation a much smaller value will be formatted as Inifinity +FYT: First issue it’s that this might if this it’s an observable behavior or not , we can consider observable if that format we use Infinity, +When we use ICU implementation a much smaller value will be formatted as Inifinity SFC: That’s the question about exponents. Should we match ICU behavior? It should allow us to format larger numbers. @@ -119,15 +119,15 @@ SFC: (introduces issue) FYT: Intl.NumberFormat is modeled on Intl.DateTimeFormat. However, there are two issues. First, checking the range introduces implementation complexity. Second, it rules out legitimate use cases. An example use case is a cycle of angles, or a cycle of time values. I may prefer if we make the change to Intl.NumberFormat v3 first, and then address Intl.DateTimeFormat. So, could we agree to make that normative change to NFv3? Second, should we adapt that into DTF? -SFC: We first should agree on the end result then we should talk about how to get there. I am convinced that we should support/allow ranges to be specified in either order. To get there, we can change NFv3 now and DateTimeFormat later, or we can do it as a separate proposal in order to align changes in both APIs. We could get the DateTimeFormat change ready now, either as a proposal or a normative PR; for example, we can propose this change for DTF directly for Stage 2 and start implementation to get stage 3. But first, do we agree to allow ranges to be specified in either order? +SFC: We first should agree on the end result then we should talk about how to get there. I am convinced that we should support/allow ranges to be specified in either order. To get there, we can change NFv3 now and DateTimeFormat later, or we can do it as a separate proposal in order to align changes in both APIs. We could get the DateTimeFormat change ready now, either as a proposal or a normative PR; for example, we can propose this change for DTF directly for Stage 2 and start implementation to get stage 3. But first, do we agree to allow ranges to be specified in either order? -RCA : +1 +RCA : +1 -USA : + 1 I am convinced by use cases presented by FYT , that the same argument applies for selectRange ? +USA : + 1 I am convinced by use cases presented by FYT , that the same argument applies for selectRange ? SFC : PluralRules selectRange should be consistent with NumberFormat formatRange. -DLM : +1 +DLM : +1 YSZ : +1 Motivation and use cases are reasonable. I agree that comparing Intl Mathematical Value is complicated in the implementation. @@ -137,7 +137,7 @@ SFC: We don't necessarily know at the call site whether the thing we're formatti QMO: Can we add an additional function, one that does the range check and one that doesn't? -FYT : I want to know if any people know why we originally added this range check +FYT : I want to know if any people know why we originally added this range check SFC : The person was me 4 years ago before being convinced by the use cases @@ -155,22 +155,22 @@ FYT: But the implementation would need to continue to carry the complexity. SFC: See the notes from 2019 here: -- https://github.com/tc39/ecma402/blob/master/meetings/notes-2019-01-17.md -- https://github.com/tc39/ecma402/blob/master/meetings/notes-2019-02-21.md +- https://github.com/tc39/ecma402/blob/HEAD/meetings/notes-2019-01-17.md +- https://github.com/tc39/ecma402/blob/HEAD/meetings/notes-2019-02-21.md SFC: My opinion then is that we should change the formatRange behavior and not retain it in another form, due to the implementation complexity concerns. QMO: Makes sense. -USA : What you’re thinking about normative PR for July meeting ? +USA : What you’re thinking about normative PR for July meeting ? SFC : Let’s think about how we can do this , we can add an Agenda item , with a combined proposal from two normative PR’s , if plenary agrees we can merge both. -FYT : We might have to change temporal as well +FYT : We might have to change temporal as well -USA : This can be part of the Stage 4 review for Temporal +USA : This can be part of the Stage 4 review for Temporal -SFC: We can do it without making any change in Temporal , do we like this approach ? +SFC: We can do it without making any change in Temporal , do we like this approach ? USA: +1 @@ -180,7 +180,7 @@ RCA: +1 - Remove the range check from the main formatRange functions -- Next Steps for TC39 July meeting +- Next Steps for TC39 July meeting - Presentation with two normative PR’s to change NF and DTF - FYT to prepare the presentation and add it to the agenda @@ -193,19 +193,19 @@ RCA: I updated the test to reflect ICU, and it has revealed the V8 issues. USA : The part of segmenter we are trying to test here it’s not exactly specified , this means we are restricting implementation behavior on test262, This probably done better by testing in ICU -FYT : The origin of the conversation was a V8 bug +FYT : The origin of the conversation was a V8 bug USA : How other engines are dealing with this ? -FYT : Actually V8 changes the ICU behavior then we have this bug +FYT : Actually V8 changes the ICU behavior then we have this bug -RGN : UAX29 defines a set of rules but implementations +RGN : UAX29 defines a set of rules but implementations SFC : The spec has a note about boundary definition based on UAX29. I am strongly in favor of adding this test. FYT: I understand USA concerns , but there is precedence of having some tests specifying locales -RGN: I don't think it is appropriate to put in place this testing that makes a conformance requirement that doesn't appear in the specification. If you have your own constraints you could layer on top of it from what’s provided by the implementation +RGN: I don't think it is appropriate to put in place this testing that makes a conformance requirement that doesn't appear in the specification. If you have your own constraints you could layer on top of it from what’s provided by the implementation USA: Are we discovering that we need to bring more of UAX 29 into ECMA-402? @@ -215,8 +215,8 @@ FYT: I can see both arguments. On one hand, ECMA-402 is scoping a consistent API SFC: The goal of ECMA-402 is to provide an API surface where we specify enough for implementing use cases. It could be argued that in some cases we specify too much. But in general, we don’t specify how some locale dependent operations should be. For Segmenter I think it’s totally reasonable for a user to expect a certain behavior involving the segmentation of URLs, email addresses, acronyms, and abbreviations. Last month we agreed that we were happy with the UAX 29 reference, and I'm fine with conclusion, but now we are saying the opposite. My proposal is to make sure that implementations obey this normative reference. Ultimately there are two questions: -1. Is it reasonable for developers to request/expect this consistency? -2. Do we need to make any spec changes? +1. Is it reasonable for developers to request/expect this consistency? +2. Do we need to make any spec changes? USA: IETF has normative and informative references. One question is, is the UAX 29 reference a normative reference? This would determine whether or not implementations can be more loose. @@ -224,15 +224,15 @@ RGN : I’m not clear in what you’re proposing to making normative or not , fo YSZ: Consistency for javascript and consistency for internationalization is between browsers but also with the rest of the platform's internationalization. -USA: What RGN mention about the rules , goes back to the previous discussion - perhaps lower level segmented that allows more control +USA: What RGN mention about the rules , goes back to the previous discussion - perhaps lower level segmented that allows more control SFC : When this was 1st raised I offered several solutions. One was including a word mode and token mode that would cover this use case of URLs and emails. -The Gdocs use case it’s a real strong case and I believe that consistency it’s important - this is not a locale dependent change it’s based in how implementation interpret the UAX29 main reason that we should cover this somehow. If we don’t want to have a more strong ref to UAX we should advocate for a word type and token type where we can specify to be more specialized for this use cases +The Gdocs use case it’s a real strong case and I believe that consistency it’s important - this is not a locale dependent change it’s based in how implementation interpret the UAX29 main reason that we should cover this somehow. If we don’t want to have a more strong ref to UAX we should advocate for a word type and token type where we can specify to be more specialized for this use cases -USA : If we do token mode we should update UAX29 anyway , correct ? +USA : If we do token mode we should update UAX29 anyway , correct ? -RGN: I understand that there is a problem here , but isn’t with the spec. V8 it’s not useful for Gdocs purposes and some of the case aren’t even specified in UAX29. +RGN: I understand that there is a problem here , but isn’t with the spec. V8 it’s not useful for Gdocs purposes and some of the case aren’t even specified in UAX29. SFC : This use cases for emails/URLs etc are wider and not a domain specific requirement. @@ -246,7 +246,7 @@ SFC: Last month we had said UAX 29 was clear enough in about what happens with USA : I think that a good idea to strengthen it on our side based on what RGN mention -SFC: I do believe we should have that discussion at Unicode side independently of this. +SFC: I do believe we should have that discussion at Unicode side independently of this. FYT: I think we can address this from the implementation side, but what would be more interesting would be to have another implementation with another configuration. diff --git a/meetings/notes-2022-08-04.md b/meetings/notes-2022-08-04.md index 49b1212e..67d6d515 100644 --- a/meetings/notes-2022-08-04.md +++ b/meetings/notes-2022-08-04.md @@ -19,7 +19,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -61,16 +61,16 @@ https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking https://github.com/tc39/proposal-intl-numberformat-v3/issues/74 -KG: The reason that’s coming up it’s because we are proposing new possible values , and the question it’s what we should do with string that are not -Recognized. +KG: The reason that’s coming up it’s because we are proposing new possible values , and the question it’s what we should do with string that are not +Recognized. FYT: Clarification question… if the input in the past before v3 is the string "false", how will it be treated by the spec? -SFC: We cast string to bool and get the “auto” behavior +SFC: We cast string to bool and get the “auto” behavior YSZ: It is treated as true. And before this fix, "false" was throwing an error. -FYT : Before V3 any string would be treated as true +FYT : Before V3 any string would be treated as true KG: Other than the empty string. @@ -106,11 +106,11 @@ USA: Throwing an error on something that didn't throw an error is a breaking cha KG: So there's breaking in theory and breaking in practice. It sounds like we know there are users in the wild using "true" and "false". Rejecting other values is breaking in theory, but we hope we can get away with it. -FYT: How about different casing of strings ‘True’ or ‘False’ +FYT: How about different casing of strings ‘True’ or ‘False’ KG: As I mentioned, there’s an important difference between breaking in theory and practice, and I’d recommend we should special-case only the string we know about so far. -FYT; How we know the difference between lowercase and uppercase true +FYT; How we know the difference between lowercase and uppercase true SFC: Because "true" and "false" are stringified ECMAScript identifiers. @@ -136,7 +136,7 @@ https://github.com/tc39/proposal-temporal/issues/2363 FYT: There are a lot of changes to 402 in the Temporal proposal, but I feel that our group has not discussed it enough. This issue, #2363… in Intl.DateTimeFormat, we have a particular order in which fields are accessed. Temporal changes this order which is observable. Many test262 tests check this order which fail now. -USA: Clarifying questions … Does this cause existing test262 to fail ? +USA: Clarifying questions … Does this cause existing test262 to fail ? FYT: Yes. @@ -176,11 +176,11 @@ https://github.com/tc39/proposal-temporal/issues/1932 FYT: (introduces issue) -USA: It’s obvious that the original function throw RangeError and now throw TypeErrors , might be justifiable that this be used and now accepting multiple different types , semantically makes sense. Do we care more about semantics or about Web Compatibility ? +USA: It’s obvious that the original function throw RangeError and now throw TypeErrors , might be justifiable that this be used and now accepting multiple different types , semantically makes sense. Do we care more about semantics or about Web Compatibility ? SFA: This is similar to the previous discussion, my take is that we should normally have the current web reality behavior, and we should be explicit about the changes on the behavior. It’s unclear where changes are introduced making it difficult when reading the specification to understand what's the intent. -USA: Is it a Web compatibility issue if we change the error type ? still an error no ? +USA: Is it a Web compatibility issue if we change the error type ? still an error no ? KG: In practice, we have not found that changing the type of an error is a web compat issue. In theory, people could be depending on the certain type of error, but in practice, they don't very often, and HTML has a policy that changing an error type is not a web compat issue. @@ -202,7 +202,7 @@ FYT: We need more people to look at chapters 15 and 16. I've been saying this fo SFC: We had this discussion about this process issue several times and I tried to solve this by bringing champions from Temporal to present several times. Temporal champions might have done a better job on communicating and making more transparent those changes, but some ECMA402 delegates are quite familiar with this section of spec. I think we have discussed this at least 3 times and let’s learn from it. I encourage FYT and others to open issues and provide implementers feedback. -FYT : It’s nothing to do with … Most of object has an +FYT : It’s nothing to do with … Most of object has an USA: I can explore the feasibility of reverting the error type, but even if I can, do we want to do it? @@ -218,9 +218,9 @@ USA to investigate the issue, and either revert the behavior change or come back https://github.com/tc39/proposal-temporal/issues/2367 -USA: What’s your proposed behavior ? Use DisplayNames to display names of calendars ? +USA: What’s your proposed behavior ? Use DisplayNames to display names of calendars ? -SFC : Point of Order : We should discuss only issues on the agenda we can postpone it for the next meeting [#Issue] +SFC : Point of Order : We should discuss only issues on the agenda we can postpone it for the next meeting [#Issue] ### Include individual numeric parts #19 @@ -228,7 +228,7 @@ https://github.com/tc39/proposal-intl-duration-format/issues/19 USA: (introduces issue) -FYT: My opinion is that we should follow the precedent of DateTimeFormat and RelativeTimeFormat. +FYT: My opinion is that we should follow the precedent of DateTimeFormat and RelativeTimeFormat. SFC: I feel we should follow the RelativeTimeFormat precedence most closely, which is to use the numeric types. @@ -274,7 +274,7 @@ https://github.com/w3c/i18n-discuss/blob/gh-pages/explainers/string-meta-explain AP: The ask is whether we could add a new ECMAScript type for localizable strings. -USA. Within the context of this API we always be accepting regular string , that’s what we already do , we will be returning internationalized strings +USA. Within the context of this API we always be accepting regular string , that’s what we already do , we will be returning internationalized strings AP: Right. You have multiple reasons to be interested in this. For example, you could output strings that have an ordering associated with them. Because if something is being inserted, you may benefit from being able to return an LString instead of just a String. @@ -286,13 +286,13 @@ FYT: When you mention this for transmitting the natural language data, basically AP: Our thinking goes like this. There are existing document formats and APIs that exist on the web and in other places. We can certainly use those to assemble what we need for message metadata values. What we're finding is that we need to have this conversation over and over again to accomplish the ability of that language to handle natural language content. We collaborated with Json-LD. We're satisfied that it solves our problems in that space. But that's only for that specific spec. Our next stop was, okay, we take existing primitives and assemble them into something. But we'd like to get this into WebIDL, etc. So then we think that we should approach TC39 to add a data type. -FYT: I think that makes sense, when you add a new Data Type to the language the question should be coming from TC39 , “is there any benefit in adding this ? or this solves a problem that cannot be solved without it” , what's the “added value for the language”. +FYT: I think that makes sense, when you add a new Data Type to the language the question should be coming from TC39 , “is there any benefit in adding this ? or this solves a problem that cannot be solved without it” , what's the “added value for the language”. AP: That's a great question. You can imagine that having a standard serialization could be useful. SFC: Temporal is an example where TC39 it’s adding new primordials for those examples of data types. One comment I brought up it’s if we had R&T would we need Temporal ? Your proposing a string with metadata should be appropriate, have a “schema” then use R&T to represent it in JS. Not saying that we should do it but it’s another possible avenue using R&T as an immutable data type that can be used already with built in deserialization/serialization capabilities etc… -EAO: Wondering if implementation we add a couple of metadata fields … +EAO: Wondering if implementation we add a couple of metadata fields … AP: The question is what defaults should become … but could be a more effective way to make it @@ -304,25 +304,25 @@ FYT : Do we have a list of attributes , are you only considering those (Language AP: Yes, those are core ones we like to see in general -FYT : Why do we need directions here ? +FYT : Why do we need directions here ? AP: You need base paragraph direction for strings in cases strong heuristics determinate directions , document shows spillover effects . - AP: Your data it’s only data , nothing says you cannot use RLM but we should have to take your string RLM in front of it to get the right behavior + AP: Your data it’s only data , nothing says you cannot use RLM but we should have to take your string RLM in front of it to get the right behavior FYT: You have to annotate that string anyway, you’re just annotating externally. -AP: It annotates outside of the string +AP: It annotates outside of the string FYT: But you can treat the first and last characters differently, right? EAO: Responding to USA… String instances don't have toJSON defined for them. So it would be an interesting change to add that. It might change something or it might not. -USA: I wasn’t aware of that … this falls back to obj.toJSON … +USA: I wasn’t aware of that … this falls back to obj.toJSON … -EAO: this is not defined … But it’s entirely possible that folks have code that verifies if that exists +EAO: this is not defined … But it’s entirely possible that folks have code that verifies if that exists SFC: No thoughts on the toJSON issue. My high level comments are, I feel that W3C group came to ECMA-402 with a solution and hoping we can implement it, but I think we should have more discussion on the problem before jumping to the solution. We should consider use cases for ECMA402 and TC39 having them as stakeholders instead of an “implementers” body of standards. For example, is there a unified way to handle issues we have such as formatToParts, MessageFormat v2, text layout, spoken text, and display context / inclections? diff --git a/meetings/notes-2022-09-01.md b/meetings/notes-2022-09-01.md index 45776bd7..093827d0 100644 --- a/meetings/notes-2022-09-01.md +++ b/meetings/notes-2022-09-01.md @@ -15,7 +15,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -220,13 +220,13 @@ FYT: Currently, because all the display are auto, it means that if you have the USA: What I meant was that a wall clock will display only two units , always minutes and seconds and hours, The SFC statement made me think about the educational burden , but I don't agree with the full rationale. I don’t feel that’s necessary to increase that educational burden. -FYT : If we don’t change it we still have an educational burden +FYT : If we don’t change it we still have an educational burden -USA : My understanding of digital outputs not be necessary , example when microwaves shows duration, use cases where frequency of changes are visible … +USA : My understanding of digital outputs not be necessary , example when microwaves shows duration, use cases where frequency of changes are visible … FYT: You're assuming that the user only shows two fields. But it could be used in a place where it shows 3 fields most of the time, but occasionally it jumps to 2 fields or 1 field. The default behavior is to automatically switch depending on the data. It makes sense if the hour+minute or the minute+second are always displayed. But that is not the setting I'm talking about. -SFC: I have two comments , 1st we should talk about the incoherent results , 2nd focus on FYT it’s talking about : +SFC: I have two comments , 1st we should talk about the incoherent results , 2nd focus on FYT it’s talking about : The default behavior for a descending duration is: @@ -252,7 +252,7 @@ The default behavior for a descending duration is: 58 ``` -FYT's proposal it’s that all fields show by default +FYT's proposal it’s that all fields show by default SFC: So basically the proposal is for style: "digital" to set the default for hour, minute, and second each to numeric and always display. @@ -304,7 +304,7 @@ USA : We’re switching from narrow to short , I’m not if it should affect FYT : The right hand side you have only two possible values - short and numeric -USA : We still need the digital base , you’re not allowed to use a longer style if you use numeric, we can switch from narrow to short to reduce the ambiguity +USA : We still need the digital base , you’re not allowed to use a longer style if you use numeric, we can switch from narrow to short to reduce the ambiguity SFC: Anyone want to voice support or opposition? @@ -312,7 +312,7 @@ FYT : +1 to "short" USA: What I said , was whatever we do in this case will be the a best effort in formatting , cause there is no way to represent digitally those values -SFC : USA is neutral +SFC : USA is neutral SFC : +1 for “short” @@ -334,7 +334,7 @@ FYT: (introduces issue) USA : The current design it’s the most permissive design we considered for the proposal, all designs we tried all had edge cases they didn’t work, and current design it’s the one that works. If we isolate some cases we don’t have to deal all combinations and only deal with this in digital and few others similar to what it’s used in DateTimeFormat. The current design it’s usable different from all others we tried -SFC : Two big challenges led to the actual shape of the proposal, how to deal with digital format and zero-valued fields… we arrived at a point where those use cases are solved. Now we could try to go back down and tweak things. Regarding testing (reason why FYT raised the concern) the testing surface shouldn’t be that big, because most options bubble down to other formatters that are already tested. +SFC : Two big challenges led to the actual shape of the proposal, how to deal with digital format and zero-valued fields… we arrived at a point where those use cases are solved. Now we could try to go back down and tweak things. Regarding testing (reason why FYT raised the concern) the testing surface shouldn’t be that big, because most options bubble down to other formatters that are already tested. FYT : The testing complexity it’s nothing to do with NF but with resu option. We need to test that we aren’t changing while getting unit options to check if they are impacted by those modifications. The implementation and complexity to run tests for all options are likely to be a problem @@ -344,7 +344,7 @@ SFC : If you want to reduce the scope of options, we can have two on/off setting SFC: Let’s figure out what next steps and path forward for this. We should discuss the testing strategy for this. Maybe talk with Test262 Maintainers (Philip C.). FYT came with a problem (an important problem), but in order to get a solution, we should chat with PFC and others. -USA : We are going to talk with tests262 folks and see how we can do this +USA : We are going to talk with tests262 folks and see how we can do this #### Conclusion diff --git a/meetings/notes-2022-10-06.md b/meetings/notes-2022-10-06.md index fe679935..08e27004 100644 --- a/meetings/notes-2022-10-06.md +++ b/meetings/notes-2022-10-06.md @@ -18,7 +18,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -29,15 +29,15 @@ RGN: We clarified layering between 262 and 402. An ECMA-262 normative change is going to have normative consequences on 402 as a result, such as time zones accepting offset strings. I'm excited to shepherd through the Stage 4 proposals landing soon. -FYT: Can you clarify the timezone part? How about implementation ? +FYT: Can you clarify the timezone part? How about implementation ? RGN: Currently the constraint in 402 to get the default timezone will go away , the change in 262 will propagate to 402, implementation if does not output offset timezone won’t be affected, current implementations cannot output a numeric offset. -FYT: Currently depending on the platform the values are picked differently , so this change may return a offset ? +FYT: Currently depending on the platform the values are picked differently , so this change may return a offset ? RGN: It’s not a named timezone it’s anumeric signed followed by hours+minutes -FYT: Should this be covered by test262 ? How should we test this change +FYT: Should this be covered by test262 ? How should we test this change RGN: I have to look into that with test262 folks at test262 meeting @@ -51,13 +51,13 @@ https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking Intl.DurationFormat -YSZ: We currently implemented based in the proposal still have to look at the decision on formatToParts +YSZ: We currently implemented based in the proposal still have to look at the decision on formatToParts -FYT: The implementation , is in progress still have bugs mostly related with formatToParts +FYT: The implementation , is in progress still have bugs mostly related with formatToParts -FYT : Intl.NFv3 already shipped in Chrome V? , +FYT : Intl.NFv3 already shipped in Chrome V? , -SFC: This proposal it’s close to be ready for Stage4 , maybe we can ask for stage advancement in next January meeting +SFC: This proposal it’s close to be ready for Stage4 , maybe we can ask for stage advancement in next January meeting ## Announcements @@ -81,11 +81,11 @@ FYT: If there is other benefits of this PR it’s ok but if no we should wait fo PFC: It does have value to peel things off the large proposal. This change isn't directly related to a Temporal API. That's what we're doing with default time zone in ECMA-262. I think it doesn't duplicate work; it saves work and allows people to look at it more carefully when it's not inside the giant proposal. -FYT: Without temporal we can keep the support from 0-3 , if temporal never ships why we are support the 4-9 ? +FYT: Without temporal we can keep the support from 0-3 , if temporal never ships why we are support the 4-9 ? SFC: There are 2 different issues solved by this PR the 0 not throwing and the 4-9 support also is not harmful -SFC: My proposal is to discuss offline so next month we can proceed +SFC: My proposal is to discuss offline so next month we can proceed #### Conclusion @@ -99,11 +99,11 @@ YSZ: What is the ICU version that has these? SFC: Unicode 15, which is ICU 72. -FYT: Last year, in similar cases we hold off until ICU releases, so we should wait probably until november +FYT: Last year, in similar cases we hold off until ICU releases, so we should wait probably until november #### Conclusion -Next meeting ICU should be released so we can revisit this again +Next meeting ICU should be released so we can revisit this again ### Normative: Read date-time options only once when creating DateTimeFormat objects @@ -113,13 +113,13 @@ FYT: The current shape of code currently passes test262 , but this could be an w RGN: I do believe that’s necessary, so current specification would improve if we can move to the proposed state -SFC: There is a chance to evaluate the web compat risk ? +SFC: There is a chance to evaluate the web compat risk ? -RGN: Usage counters might be the appropriate approach +RGN: Usage counters might be the appropriate approach FYT: I think we should list the Test262 that would be affected, and then we can tell if there is a "red flag" that could cause a compatibility issue. So I support the change but I think we need to understand the potential impact, be cautious. -RGN: That's reasonable and it's not difficult to do. Using engine262 +RGN: That's reasonable and it's not difficult to do. Using engine262 EAO: +1 @@ -139,7 +139,7 @@ https://github.com/tc39/proposal-intl-enumeration FYT: Presenting - https://docs.google.com/presentation/d/1IIlwdOospGLmqCNjGuhh-NrZrxlHGhGbo0-uQFqfmyM/edit -SFC: I see 3 open issues what’s this affect the Stage 4 advancement ? +SFC: I see 3 open issues what’s this affect the Stage 4 advancement ? FYT: The first issue is #39. @@ -149,29 +149,29 @@ FYT: There's no contradiction. SFC: I vote we should close it or tag it as editorial. It shouldn’t affect stage 4 . -FYT : The second issue #37 we have a PR , with a simple solution to make it clear that’s a canonical id the changes are basically adding word canonical +FYT : The second issue #37 we have a PR , with a simple solution to make it clear that’s a canonical id the changes are basically adding word canonical -PFC: If there is no compromise possible , we should find a work around it , I would prefer not continue with discussion +PFC: If there is no compromise possible , we should find a work around it , I would prefer not continue with discussion FYT: Do we have support for this Normative PR in TG2? SFC: I see a lot of discussion on that issue and maybe we should add this PR to the TC39 agenda to have more people discussion about it -PFC: Unsure if that would be a good use of plenary time, this is an Editorial preference that might bring more people to bikeshedding on this issue +PFC: Unsure if that would be a good use of plenary time, this is an Editorial preference that might bring more people to bikeshedding on this issue -SFC: I have to catch up on the current status of this PR to have a informed opinion about this +SFC: I have to catch up on the current status of this PR to have a informed opinion about this -RGN: Would be possible to summarize the positions ? +RGN: Would be possible to summarize the positions ? -SFC: We don’t have time for it , best option it’s do it offline, None of the discussed issues are stage advancement blockers, changes might only apply strictness to the implementations, +SFC: We don’t have time for it , best option it’s do it offline, None of the discussed issues are stage advancement blockers, changes might only apply strictness to the implementations, -FYT : This is a normative change, so we should take this strictness requirement before merge , making sure that only return canonical … +FYT : This is a normative change, so we should take this strictness requirement before merge , making sure that only return canonical … SFC: Are we all ok on merging this 43 PR and discuss future improvements later PFC: Ok with that , my objection was based that this would be more work around everybody -FYT: Do we have support from Moz and Apple ? +FYT: Do we have support from Moz and Apple ? YSZ: Yeah, +1 @@ -179,23 +179,23 @@ EAO: That's fine DLM: Looks ok to me! -#### Conclusion +#### Conclusion -Merge PR #43 and go stage 4 and after work on the 3 remaining issues +Merge PR #43 and go stage 4 and after work on the 3 remaining issues -### Intl Locale Info API for Stage 4 +### Intl Locale Info API for Stage 4 FYT : Presenting - Slides https://docs.google.com/presentation/d/1_GAPg4P6FWNN9vJ_BwAHMsjikF7WHuJUX7VJczV0t0Y/edit#slide=id.p FYT: What should we do with issue #62? https://github.com/tc39/proposal-intl-locale-info/issues/62 -RGN: I'm willing to help with that , +RGN: I'm willing to help with that , -FYT: Should this should be resolved before stage 4 ? or current behavior it’s ok for stage 4 ? +FYT: Should this should be resolved before stage 4 ? or current behavior it’s ok for stage 4 ? -RGN : Why is this is different right now ? +RGN : Why is this is different right now ? -FYT: This is not intention +FYT: This is not intention RGN: We should return the same object. @@ -205,13 +205,13 @@ FYT: We'd need to make the object so it couldn't be modified. RGN: I didn’t realize the value return is a object , you could either freeze it and always return the same thing. Or you could replace the property getter with a method. -SFC : My question is, what is the extent to which there is precedent for this and in other APIs ? since is a getter behavior should be consistent +SFC : My question is, what is the extent to which there is precedent for this and in other APIs ? since is a getter behavior should be consistent -RGN : It’s a free choice , we don’t have get methods that return objects , but I’m ok to set this new precedent, +RGN : It’s a free choice , we don’t have get methods that return objects , but I’m ok to set this new precedent, -SFC: This Stage 3 and already shipped in the browsers, so the change might affect implementations and maybe we shouldn’t be changed at this point +SFC: This Stage 3 and already shipped in the browsers, so the change might affect implementations and maybe we shouldn’t be changed at this point -RGN: I think this should be changed +RGN: I think this should be changed EAO : It look like a good use case for a Record @@ -219,15 +219,15 @@ SFC: That would be a breaking change if in future we replace this by a Record ? RGN : Web compat only applies when something is merged into the spec -SFC: Disagree cause this shipped in V8 for a long time… +SFC: Disagree cause this shipped in V8 for a long time… -EAO: The best way is to leave it for now and wait for Record +EAO: The best way is to leave it for now and wait for Record -RGN : How essential is this interface for the proposal ? and what be the consequences for not having this ? +RGN : How essential is this interface for the proposal ? and what be the consequences for not having this ? FYT I believe that would affect all of it -SFC: I believe this would be a good question for TG1 plenary - this is one of the issues that we should discuss there +SFC: I believe this would be a good question for TG1 plenary - this is one of the issues that we should discuss there 1. Make it a function 2. Leave it the way it is @@ -248,23 +248,23 @@ SFC: Other getters are specified to return data in implementation-defined locale FYT: Currently time zones are returned in alphabetical order -SFC: So timezone is alphabetic? So maybe it’s ok make collations alphabetic as well. For timezones, do we return timezone as first element of the array? +SFC: So timezone is alphabetic? So maybe it’s ok make collations alphabetic as well. For timezones, do we return timezone as first element of the array? FYT: It’s alphabetical order SFC: We may want to add -u-tz at some point, in which case the 1st element of the array should be the locale's time zone. If we insert the 1st element now, then developers can get used to that pattern. But, I'm okay relaxing this point and just always returning time zones and collations in alphabetical order. -FYT: It’s ok not considering drop the api ? +FYT: It’s ok not considering drop the api ? SFC: Yes -SFC: Do we have support for this ? +SFC: Do we have support for this ? DLM: Based upon the context of this issue, he landed half the patches and is waiting for further feedback. We should leave info for him on Bugzilla on what to do next. I wouldn't expect that if we are approaching Stage 4 that there are other blocking issues. FYT: I’ll change my slot in the agenda , not feeling comfortable going stage 4 , and will do change proposal to sort alphabetically and follow up with Mozilla to check if we have all we need to ask stage 4 -#### Conclusion +#### Conclusion Delay Stage 4 advancement and wait for Moz feedback and meanwhile we can fix the alphabetical sort @@ -276,11 +276,11 @@ https://github.com/eemeli/proposal-intl-message-resource EAO: (discusses issue) -SFC: I’m supportive with this change , also compatible with direction with direction group is taking decoupling this , I support this +SFC: I’m supportive with this change , also compatible with direction with direction group is taking decoupling this , I support this DLM: +1. I think it makes sense to consider these separately. So I support this. -RCA: +1 +RCA: +1 YSZ: I support splitting. One question; in the resource spec, will we also specify the actual format of the resource? @@ -298,33 +298,33 @@ https://github.com/FrankYFTang/proposal-intl-temporal PFC: RCA and I were talking and we'd like to suggest a different name for the proposal, to avoid confusion with Temporal. The purpose of the proposal is to specify the calculations, which is not only about Temporal but also about DateTimeFormat, which also uses these calculations. I'm worried that if you take this to TG1 with the name "intl-temporal", it will raise unnecessary questions. I'd like to suggest a name like "intl-calendar-calculations" or something like that. -FYT: Originally the core of proposal , the most important things in this proposal was not specify calendar calculation and might not be achievable , the core part is the ERA for each calendar and the meaning of each month when working with temporal. When we specify anything related with calculation can be vaguely mentioned in this proposal. +FYT: Originally the core of proposal , the most important things in this proposal was not specify calendar calculation and might not be achievable , the core part is the ERA for each calendar and the meaning of each month when working with temporal. When we specify anything related with calculation can be vaguely mentioned in this proposal. -Ideally by this time we should have enough information on Temporal information to progress implementation , at current state there is no mention calendars , but we have test262 testing that behavior that we have a gap between proposal , documentation and proposal, so my intention was to have a minimum set of spec to unblock that. +Ideally by this time we should have enough information on Temporal information to progress implementation , at current state there is no mention calendars , but we have test262 testing that behavior that we have a gap between proposal , documentation and proposal, so my intention was to have a minimum set of spec to unblock that. -Do we want to include simple calculations there ? Example differences in calendars … +Do we want to include simple calculations there ? Example differences in calendars … -It could belong internally to Temporal proposal , but at the moment is stage 3 being more difficult to expand the scope, so this new proposal would be complementary to temporal as an independent proposal that can be used in future by temporal. Currently this also block temporal implementation if we don’t have this bits of spec to fulfill the existing gap +It could belong internally to Temporal proposal , but at the moment is stage 3 being more difficult to expand the scope, so this new proposal would be complementary to temporal as an independent proposal that can be used in future by temporal. Currently this also block temporal implementation if we don’t have this bits of spec to fulfill the existing gap -SFC: We should resolve the naming, I would suggest call it intl-calendar-proposal +SFC: We should resolve the naming, I would suggest call it intl-calendar-proposal -FYT: I’m afraid that if we change it to calendar that would be much bigger task +FYT: I’m afraid that if we change it to calendar that would be much bigger task -PFC: I was going to suggest, intl-era-and-month-codes +PFC: I was going to suggest, intl-era-and-month-codes FYT : I’m open to that -PFC: I’m happy to discuss later about this and if this should belong to the temporal proposal scope +PFC: I’m happy to discuss later about this and if this should belong to the temporal proposal scope -SFC : Everybody is happy with proposal-intl-era-and-month-codes ? +SFC : Everybody is happy with proposal-intl-era-and-month-codes ? RCA : +1 -SFC : + 1 +SFC : + 1 -FYT : +1 +FYT : +1 -#### Conclusion +#### Conclusion We approved the change of name proposal-intl-era-and-month-codes @@ -332,11 +332,11 @@ We approved the change of name proposal-intl-era-and-month-codes https://github.com/tc39/proposal-intl-duration-format/issues/125 -RCA: How many implementations are in progress ? This would affect them ? +RCA: How many implementations are in progress ? This would affect them ? YSZ: We agreed that the default unit length is short, so this looks consistent. -#### Conclusion +#### Conclusion LGTM from two implementers. Bring back to the issue for agreement from Ujjwal. @@ -344,15 +344,15 @@ LGTM from two implementers. Bring back to the issue for agreement from Ujjwal. https://github.com/tc39/proposal-intl-duration-format/issues/115 -PFC : I talked with Ujjwal Sharma about this and we do believe that a table driven test would fit here , cause if we do exhaustive test we would likely to have more than 12M combinations , so this option of having a table driven test can cover the needs we have for validate spec correctness +PFC : I talked with Ujjwal Sharma about this and we do believe that a table driven test would fit here , cause if we do exhaustive test we would likely to have more than 12M combinations , so this option of having a table driven test can cover the needs we have for validate spec correctness -FYT : There is a strong dependency between option fields that impact others so those combinations are difficult to test and are likely to cause errorsthis case is different from DateFormat or others, current the DurationFormat has dependencies on previous options so it makes more complicated +FYT : There is a strong dependency between option fields that impact others so those combinations are difficult to test and are likely to cause errorsthis case is different from DateFormat or others, current the DurationFormat has dependencies on previous options so it makes more complicated PFC: I don’t have much to say about the proposal , we discussed a testing strategy that would work for the proposal SFC: It sounds like the action here is to write the tests. Not much more to discuss. -#### Conclusion +#### Conclusion RCA and USA to write the tests. diff --git a/meetings/notes-2022-11-03.md b/meetings/notes-2022-11-03.md index 0bde4469..eba3fa8d 100644 --- a/meetings/notes-2022-11-03.md +++ b/meetings/notes-2022-11-03.md @@ -18,7 +18,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -48,7 +48,7 @@ No updates. https://github.com/tc39/ecma402/pull/724 -USA: This PR needs to be approved by TG1 , expands current behavior by adding “GTM” to the supported formats, do you all agree ? +USA: This PR needs to be approved by TG1 , expands current behavior by adding “GTM” to the supported formats, do you all agree ? LAF: What's the impact? That you can specify "GMT" without "Etc"? @@ -188,7 +188,7 @@ FYT: I am a bit lost when you talk about depending on Temporal from the now obj SFC: How to get current time is a bit of a red herring, since we can get the current time through other ways. Temporal.Now.plainDate().era gives us the current era, so it avoids duplicating some of that work. But indeed, the current date can indeed be done in the language currently. -EAO: My question is , if we implement this now as in implementation defined behavior and later we use Temporal , would this allow this to land without Temporal dependency ? +EAO: My question is , if we implement this now as in implementation defined behavior and later we use Temporal , would this allow this to land without Temporal dependency ? SFC: That’s definitely the approach to get them decoupled if we decide to go down that road. @@ -254,11 +254,11 @@ YSZ: This conversion from string to temporal.duration is not a feature request, FYT: I believe this is related with spec alignment between DurationFormat and Temporal, the biggest issues IMHO we have similar but not an 1:1 alignment between proposals which make more confusing -SFC: There are two questions here , should we accept string and parse it as TemporalDuration and at moment throw the RangeError, should we accept a string or not ? +SFC: There are two questions here , should we accept string and parse it as TemporalDuration and at moment throw the RangeError, should we accept a string or not ? -USA: Past TG2 meeting we had consensus that in future we should expand the proposal to support strings +USA: Past TG2 meeting we had consensus that in future we should expand the proposal to support strings -SFC: I’m fine supporting strings +SFC: I’m fine supporting strings PFC: +1 for string. a design principle for Temporal was that any entry point taking a Duration would also accept a property bag, or a string, so I think it would be surprising if DurationFormat was the only entry point that deviated diff --git a/meetings/notes-2022-12-08.md b/meetings/notes-2022-12-08.md index 4f83bfeb..ff3f2409 100644 --- a/meetings/notes-2022-12-08.md +++ b/meetings/notes-2022-12-08.md @@ -16,7 +16,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) diff --git a/meetings/notes-2023-01-12.md b/meetings/notes-2023-01-12.md index 97574fe1..e053d2c4 100644 --- a/meetings/notes-2023-01-12.md +++ b/meetings/notes-2023-01-12.md @@ -20,7 +20,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -43,7 +43,7 @@ RCA: Addison Philips is the new chairperson of the group. I intend to continue t https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -FYT: Locale info: plan to provide an update to end of january meeting – too rushed to go to stage 4 in the coming year. To discuss today: changing getter to a method. +FYT: Locale info: plan to provide an update to end of january meeting – too rushed to go to stage 4 in the coming year. To discuss today: changing getter to a method. SFC: Interested in getting NumberFormat to stage 4 @@ -51,7 +51,7 @@ USA: reached consensus on biggest open questions. It would be great if over the EAO: working on some of the spec text / addressing issues that haven't been addressed, not sure when it'll be in the state to look like a stage 2 thing -FYT: another stage 1 proposal missing from table, which already advanced stage 1 in last meeting. Planning to give update in response to concern last time +FYT: another stage 1 proposal missing from table, which already advanced stage 1 in last meeting. Planning to give update in response to concern last time The issue was if we should do this within ECMA/TC39 or within Unicode CLDR. We went to CLDR and concluded that most of the work will move to CLDR with a thin addition to 402 including a reference to said CLDR documents. @@ -65,9 +65,9 @@ https://github.com/tc39/proposal-intl-era-monthcode/issues https://github.com/tc39/ecma402/pull/709 -SFC: several open Normative PRs. Request status on 709, last discussed Oct. 6. Review test262 impact. +SFC: several open Normative PRs. Request status on 709, last discussed Oct. 6. Review test262 impact. -RGN: working on it right now, threading of the Intl object in test262, will have a report by EOD to +RGN: working on it right now, threading of the Intl object in test262, will have a report by EOD to ### Normative: Updates on fractionalSecondDigits in preparation for Temporal @@ -95,7 +95,7 @@ https://github.com/tc39/ecma402/pull/716 SFC: 716 is actionable? -USA: yes, but I don’t think we should merge it right away +USA: yes, but I don’t think we should merge it right away SFC: Editors, please take a look. @@ -109,7 +109,7 @@ FYT: blocked, need to be addressed https://github.com/tc39/ecma402/pull/709 -SFC: need to review RGN modifications +SFC: need to review RGN modifications SFC: some older Normative requests @@ -127,23 +127,23 @@ USA: Would be nice to get confirmation from committee that we should use fractio SFC: framework: the two cases we have are minimumFractionDigits and fractionalSecondDigits. Proposed mental framework: “fractional” is an adjective describing seconds, fractionDigits is a different thing because fraction is a noun. “Fractional” here refers to seconds, not digits -USA: In this case, while we do not have a second now which fractional could describe, we still have an arbitrary unit, could be fractional[X]Digits. We are still editing the fractionalDigits of an arbitrary unit. +USA: In this case, while we do not have a second now which fractional could describe, we still have an arbitrary unit, could be fractional[X]Digits. We are still editing the fractionalDigits of an arbitrary unit. -SFC: does Temporal call the flag? Temporal has one too, right? fractionalSecondsDigits in Temporal. +SFC: does Temporal call the flag? Temporal has one too, right? fractionalSecondsDigits in Temporal. -USA: another thing to consider: within NumberFormat we’re trying to have an internal consistency: we have [...] is significant not an +USA: another thing to consider: within NumberFormat we’re trying to have an internal consistency: we have [...] is significant not an SFC: My inclination is that fractionalDigits in DurationFormat is more similar to fractionalSecondDigits in DateTimeFormat and the rest of Temporal. If we were designing NumberFormat from scratch, there are several changes I would have made if designing from scratch. USA : The question is anyone is opposed to have fractional digits in DurationFormat? -USA: A lot of this is mitigated by editors having autocomplete +USA: A lot of this is mitigated by editors having autocomplete ZB: Are there cases where we would want to have both at the same time? I think probably not. USA: don’t think it’s a possibility to have both in the near-term future -SFC: proposes we close this issue and keep fractionalDigits. +SFC: proposes we close this issue and keep fractionalDigits. #### Conclusion @@ -159,11 +159,11 @@ USA: approximate as an adjective sounds better – would support approximateSign SFC : The name of this option predates ECMA402 in ICU and CLDR. I think I probably proposed those names. The name seems more natural. Also, since this is a Stage 3 proposal and browsers already shipped I’m inclined to keep it . -ZB : I would stick with the current name +ZB : I would stick with the current name -DM: +1 +DM: +1 -RGN: I’m not objected to keep the approximatelySign just wanted us to make a conscious decision +RGN: I’m not objected to keep the approximatelySign just wanted us to make a conscious decision EAO: We could consider "aboutSign", in response to how one would read it in natural language. @@ -207,9 +207,9 @@ RGN: Exactly, the state isn’t great anymore. FYT: never intended to be alphabetical order, someone in the past introduced the idea that it should be alphabetic order, doesn’t believe there was consensus that this was the right thing to do -RGN: You can see the complexity that can stem from implementation and testing to ensure that the reads and assignments are in fact in the correct order. The order is itself observable +RGN: You can see the complexity that can stem from implementation and testing to ensure that the reads and assignments are in fact in the correct order. The order is itself observable -FYT: It was never a criterion before it reached Stage 3 that this had to be in order, was never on the table. It has to be in some sort of order, but alphabetic was never put on table. +FYT: It was never a criterion before it reached Stage 3 that this had to be in order, was never on the table. It has to be in some sort of order, but alphabetic was never put on table. FYT: Let me say this: assume we don’t have NFv3. Would we switch to alphabetical order? @@ -223,17 +223,17 @@ USA: I agree with RGN, NF as pointed out was standardized before some of those c SFC: Tend to agree with FYT that this issue is a ship that’s already sailed for NFv3. There is a little bit of sense to ordering right now, because we read the order in which we must because of dependencies. Doesn’t see opportunities to improve ordering – no way to make them alphabetical. Best we can do is add new options to the end, and put them in alphabetical order. Change: move trailingZeroDisplay down below roundingMode? About the best change we could make, not sure if high-impact. For new APIs we should try to do alphabetical order, for old APIs we have what we have and not worth trying to change it. -FYT: Still have questions about whether alphabetical order would be right thing. Would oppose. +FYT: Still have questions about whether alphabetical order would be right thing. Would oppose. RGN: Withdrawing alphabetical as a context. Most likely resolution isn’t alphabetical, force a copy that reads everything in insertion order / order reported. Alphabetical not particularly likely guideline. SFC: Question for RGN: raising issue, not clear on proposed alternative. Throw out current reads and read insertion order, or change order in NFv3 & change in stage 4? Normative change to switch order of reads, maybe web compatible and make it later. -RGN: Valid. What’s in scope is placement of green lines – not expecting NFv3 to include reordering whatever has already been published/stable as part of ECMA-402. What might change ise what those green lines look like: is it necessary to scatter the rounding related properties across this sequence or can they be clustered? Cannot impose alphabetical / enumeration across interface, proposal: keep this and change it across ECMA-402 in future. +RGN: Valid. What’s in scope is placement of green lines – not expecting NFv3 to include reordering whatever has already been published/stable as part of ECMA-402. What might change ise what those green lines look like: is it necessary to scatter the rounding related properties across this sequence or can they be clustered? Cannot impose alphabetical / enumeration across interface, proposal: keep this and change it across ECMA-402 in future. -SFC: clarification: only possible change is to move trailingZeroDisplay under roundingMode, other things have reason for being where they are / may not be possible to move them, would require much bigger refactor of spec to move them. Doesn’t see what we can do concretely to make it better in an impactful way. +SFC: clarification: only possible change is to move trailingZeroDisplay under roundingMode, other things have reason for being where they are / may not be possible to move them, would require much bigger refactor of spec to move them. Doesn’t see what we can do concretely to make it better in an impactful way. -FYT: asks RGN for clarification: where is insertion order coming from, +FYT: asks RGN for clarification: where is insertion order coming from, RGN: Property enumeration order, which for a plain object is insertion order @@ -241,7 +241,7 @@ SFC: insertion order coming from user objects FYT: how does object get created? By resultOptions or by user. No way to predict how user will create object -RGN: We don’t need to predict it. +RGN: We don’t need to predict it. FYT: will not be consistent @@ -265,15 +265,15 @@ No change in NFv3. Revisit the issue in the context of ECMA-402 at large indepen https://github.com/tc39/proposal-intl-numberformat-v3/pull/117 -RCA: PR reflects web reality. This PR is mostly to add limit on number of significant digits. Intention of PR is to reflect current reality that anything with more than 309 digits goes to Infinity. Not sure why 309 adopted +RCA: PR reflects web reality. This PR is mostly to add limit on number of significant digits. Intention of PR is to reflect current reality that anything with more than 309 digits goes to Infinity. Not sure why 309 adopted -USA: Always somewhat unsettled with rounding to 300, +USA: Always somewhat unsettled with rounding to 300, SFC: two things: web reality is currently a smaller number of digits, not sure how/why. Second is concerns for having unlimited value, cannot change w/o changing representation of decimals in NFv3. Two parts: # of sig digits, other is max exponent, more concerned about max exponent. If limit on number of digits, that would make it easier to implement. When it comes to ICU4X, the representation would have to be altered if we go ahead with the idea of Number.MAX_SAFE_VALUE. -USA: question, would it be unreasonable to ask AB to attend call? +USA: question, would it be unreasonable to ask AB to attend call? -SFC: AB on invitation, does not have contact with them directly +SFC: AB on invitation, does not have contact with them directly DLM: They are a volunteer so it is likely that they might not have the time or availability to attend. @@ -291,7 +291,7 @@ RCA: formatted different way FYT: these values could throw exception -SFC: never throw exception, not on table +SFC: never throw exception, not on table FYT: changing from something that’s possible to return Infinity, -Infinity, -0. If no exception @@ -299,15 +299,15 @@ SFC: currently spec requires unbounded mathematical values to be formatted SFC: suggesting Romulo change v8 to reflect spec, use Infinity for overflow from sufficiently large numbers -FYT: Either way formatting result, how to verify? +FYT: Either way formatting result, how to verify? USA: Clarifying question for SFC: idea that beyond the limit implementations can choose whether to fail over to Infinity. [...] -SFC: yes, but max value and min value way beyond what ICU4X supports, proposal to set to v8 value +SFC: yes, but max value and min value way beyond what ICU4X supports, proposal to set to v8 value USA: Even if we go ahead with something like that, ICU4X would not have to change representation, just need to bump up the size of data type it uses -SFC: another way to spec this out is we should say that if the value of the Intl mathematical value is > R(Number.MAX_VALUE), then that’s where we say implementations are permitted to use Infinity replacement character +SFC: another way to spec this out is we should say that if the value of the Intl mathematical value is > R(Number.MAX_VALUE), then that’s where we say implementations are permitted to use Infinity replacement character USA: Number.MAX_VALUE is a float. @@ -323,16 +323,16 @@ SFC: Implementations are permitted, but not required, to do this. There should b Use R(Number.MAX_VALUE) as the (optional) limit. Double check with Anba. -### Normative: alter formatToParts Output +### Normative: alter formatToParts Output https://github.com/tc39/proposal-intl-duration-format/pull/126 USA: #126 is one part bugfix, one part implementor feedback. Three issues: bugfix. Bug filed by FYT that pointed out result of formatToParts not great, especially digital as described in [#114](https://github.com/tc39/proposal-intl-duration-format/issues/114) . [...] Need to group Duration part together in one big unit and pass them together with no separators between them. Also recently had conclusion in last monthly meeting where we decided that [..] -Also, general feedback of shape of formatToParts, doesn’t allow enough flexibility to be useful for most developers. Example formatToParts output reached consensus. This is one of the biggest issues in DurationFormat, move on to stage 4? +Also, general feedback of shape of formatToParts, doesn’t allow enough flexibility to be useful for most developers. Example formatToParts output reached consensus. This is one of the biggest issues in DurationFormat, move on to stage 4? #### Conclusion -Ask for Stage 4 at the next TC39 +Ask for Stage 4 at the next TC39 ### Normative: Change the getters to methods @@ -344,13 +344,13 @@ SFC: Feels like the next step is TG1 decide it from us , so should be added on FYT to reach consensus at TG1 -### Should Intl APIs match Temporal interpretation of calendar and timeZone options? #741 +### Should Intl APIs match Temporal interpretation of calendar and timeZone options? #741 https://github.com/tc39/ecma402/issues/741 SFC: Currently time zone and calendar options we have on Intl methods take strings. Temporal take string and object that can be coerced to string, but also ISO string and object with calendar or timeZone property. When should Intl options named calendar and timeZones also accept these other two forms of input? Proposal: keep things way they are w/o changing them, revisit in year or so once Temporal lands at stage 4 -FYT : My position I would prefer no changes, but if changes are needed I would prefer to not change Intl constructor, mostly because that part of API is perf sensitive and I don't want to see many changes on that part and avoid any possible inconsistency with 402. So I support a path that those changes not originate inconsistency. +FYT : My position I would prefer no changes, but if changes are needed I would prefer to not change Intl constructor, mostly because that part of API is perf sensitive and I don't want to see many changes on that part and avoid any possible inconsistency with 402. So I support a path that those changes not originate inconsistency. SFC: Calendar and timeZone are special because Temporal makes them special. If some proposal to make currency an ECMA type, change to reflect. @@ -364,15 +364,15 @@ https://github.com/js-temporal/proposal-temporal-v2/issues/25 FYC: In Temporal they have a lot of toLocaleString, no reason Temporal.Calendar can’t have -USA: Make toLocaleString use display names? +USA: Make toLocaleString use display names? -FYC: All other Temporal objects have a toLocaleString. +FYC: All other Temporal objects have a toLocaleString. -SFC: If someone would put up proposal to add, is this something we’d support? +SFC: If someone would put up proposal to add, is this something we’d support? -USA: Strongly in support. +USA: Strongly in support. -FYC: Not for current Temporal proposal, ship something. Already very thick proposal. +FYC: Not for current Temporal proposal, ship something. Already very thick proposal. ### Intl.Segmenter with URLs, email addresses, and acronyms #656 #### diff --git a/meetings/notes-2023-02-09.md b/meetings/notes-2023-02-09.md index 22fdf312..70a0b0a1 100644 --- a/meetings/notes-2023-02-09.md +++ b/meetings/notes-2023-02-09.md @@ -20,7 +20,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -29,7 +29,7 @@ ### Editor's Update -USA : We got TG1 consensus on Normative PR, and few editorial improvements landing in the upcoming weeks, NFv3 going for Stage 4 and DurationFormat updates +USA : We got TG1 consensus on Normative PR, and few editorial improvements landing in the upcoming weeks, NFv3 going for Stage 4 and DurationFormat updates RGN: Additionally we've made changes about how we reference Unicode documents, our contribution guidelines, etc. And ideally before next meeting I'd like to see the locale handling land as well. @@ -65,13 +65,13 @@ YSZ: For stenography, as the Apple rep, I'd need to have a discussion with our t DLM: I'd like to voice general support for stenography. Having stenography support means that more people can participate. It also alleviates guilt from folks unable to take notes. -USA: What I conclude here is that we’re generally positive about stenography, we could continue to see as the stenographer continues to make progress/improvements over time at TC39 plenary. Over time we could form a more conclusive position, but I do concur with the general idea that we have less of a problem than plenary, in general it’s a better environment for notetakers. +USA: What I conclude here is that we’re generally positive about stenography, we could continue to see as the stenographer continues to make progress/improvements over time at TC39 plenary. Over time we could form a more conclusive position, but I do concur with the general idea that we have less of a problem than plenary, in general it’s a better environment for notetakers. DLM: A follow-up question. In TC39 we've discussed why making a recording of the meeting isn't an alternative. Do those same concerns apply here? USA: TC39 isn’t recorded because certain delegates have reservations. We might be in a similar situation where not everyone is at complete liberty to be recorded. Perhaps we could try to work out some way to do recordings in a way that doesn’t violate Apple guidelines. We might have to cross that bridge in the greater TC39 context, perhaps good idea to wait for that conversation to happen again there, then re-open it here -SFC: One of the primary use cases for recording notes for meetings here is that we can accommodate people who are unable to attend this meeting on a regular basis to make sure they stay in the loop, not practical to tell these people to go watch a long mpeg file. People do read and care about these notes, so I don’t necessarily want to change this medium. A recording in addition to notes is more of a policy question. +SFC: One of the primary use cases for recording notes for meetings here is that we can accommodate people who are unable to attend this meeting on a regular basis to make sure they stay in the loop, not practical to tell these people to go watch a long mpeg file. People do read and care about these notes, so I don’t necessarily want to change this medium. A recording in addition to notes is more of a policy question. USA: I want to first concur – we can go back and edit notes, we can summarize notes, we can search notes – so there’s definitely that aspect of notes. In favor of videos: argument from ECMA was that to take a secure recording of the meeting, using this recording to asynchronously make notes, not necessarily publishing the video / keeping it safely on ECMA servers or getting rid of them after two week mark. Complex discussion: more easy discussion is whether we’re happy with the notes / need help from stenographers. @@ -124,7 +124,7 @@ https://github.com/tc39/ecma402/issues/256 HJS: ECMA-402 doesn’t have a search API, has mechanism for loading search data, doesn’t have API to go with that. I don’t see anyone answering how we use the search data for searching. Assuming we don’t want to have quadratic behavior, with the API surface available what do you do with search data? Hypothesis: this is a historical document of how the spec was written before my time. I’m not advocating as a search API – very skeptical of using collator for search. -If there isn’t a use case for this search data in the context of the sorting-oriented API, the reasonable step would be to not have the search data in Firefox. What have I missed about the history and use cases, why is there this API surface for requesting search data to be loaded, is there a use case for it? +If there isn’t a use case for this search data in the context of the sorting-oriented API, the reasonable step would be to not have the search data in Firefox. What have I missed about the history and use cases, why is there this API surface for requesting search data to be loaded, is there a use case for it? FYT: I don't understand why you say there's no search API. But all the search is based on comparison. The collator has a compare function. You can't implement a search algorithm without comparing a string. @@ -138,7 +138,7 @@ FYT: The search is not searching inside the string; it's about searching of stri HJS: Is it known if this use case is common enough to be worth this much data? What happens if you use non-search data for this use case? What does the search data actually do? In the root, AFAICT, the main differences are in Hangul, where it allows an archaic Hangul haystack to be searched by a modern Hangul string. That sort of thing is very niche in itself. And as a phonebook, that seems unlikely to show up. There's also a performance optimization. If you just care about German, not Korean search for German locale, same as phonebook. Apple wanting to use old-school matching for search in Finnish and Swedish. Overall when you are matching the whole string, when would it make a difference that we have a search collation, except for German to have the phonebook collation and two very narrow Korean cases (search is archaic on the one hand, or phonebook-specific thing). For a WebAPI, how often do people write an app like a contacts app for a phone? -FYT: I think talking about probability is a very scary thing, the probability of a particular locale is relatively small – but if (for example) in Finland, people care about that locale. You have a concern about pre-existing ECMA-402 data, want to trim it out in order to have a smaller implementation. +FYT: I think talking about probability is a very scary thing, the probability of a particular locale is relatively small – but if (for example) in Finland, people care about that locale. You have a concern about pre-existing ECMA-402 data, want to trim it out in order to have a smaller implementation. In clause 9.1, it explicitly mentions that the sort and search locale data are implementation-dependent. It's also in 10.2.3. It has an explicit clause that the data are implementation-defined within the current constraints. Instead of saying “should we remove the ability from the standard,” the standard already provides an implementation to not use the whole thing. @@ -150,7 +150,7 @@ HJS: A couple things. First, for use cases, is it sufficiently niche? Regardless YSZ: If you think this data is not used, the appropriate venue is CLDR not ECMA-402 -HJS: ICU4C does have API surface that makes use of that data, doesn’t make sense to ask for it to be dropped from CLDR, question is does it make sense for us in Firefox (when we are not using it for substring search) and there is no web API that uses that data for substring search, is there a use case that justifies that data being around when the API is a sorting API rather than a searching API. Although, as noted, it can be used for searching list items if the needle is a full match rather than a substring. +HJS: ICU4C does have API surface that makes use of that data, doesn’t make sense to ask for it to be dropped from CLDR, question is does it make sense for us in Firefox (when we are not using it for substring search) and there is no web API that uses that data for substring search, is there a use case that justifies that data being around when the API is a sorting API rather than a searching API. Although, as noted, it can be used for searching list items if the needle is a full match rather than a substring. SFC: I think the main issue here is that when collator was added into ECMA-402 we included that the source collations variants would be accessible via the API, is it worth the extra payload to not just use the regular collations rather than the search collations – is that fine, or is that going to break anything? @@ -162,21 +162,21 @@ HJS: Both Chrome and Safari use collator-based ctrl-F, they have reasons to have MWS: So in terms of use case for this API, I would tend to agree with HJS in that it's a little weak to say you need the dat when the API only meaningfully lets you do a whole-string match, not a substring match. -SFC: Followup question: is it reasonable behavior for an implementation like Firefox to just return the regular collations when the search collations are requested. If it’s the case that the search isn’t that useful, is it a reasonable idea (and appears to be spec-compliant) to just return the same rules and ignore that option +SFC: Followup question: is it reasonable behavior for an implementation like Firefox to just return the regular collations when the search collations are requested. If it’s the case that the search isn’t that useful, is it a reasonable idea (and appears to be spec-compliant) to just return the same rules and ignore that option -MWS: It would be a fallback that would be functional, in a lot of cases the difference for testing equality for strings will be relatively small except for cases where there are special search tailorings that are a little bit different. For a lot of languages the difference would be insignificant. If someone does care about that difference, it may be reasonable to get an error, but on average that would be unfriendly +MWS: It would be a fallback that would be functional, in a lot of cases the difference for testing equality for strings will be relatively small except for cases where there are special search tailorings that are a little bit different. For a lot of languages the difference would be insignificant. If someone does care about that difference, it may be reasonable to get an error, but on average that would be unfriendly -HJS: If I can imagine cases where someone would misuse the search collations for search, it may be when someone requests search when they should be using phonebook. Only languages where the difference is meaningful are Finnish, Swedish, Korean (archaic Hangul), Catalan… In Catalan, it's about how "l." behaves. In German it's about "ue". Sort collation (except for German) returns the phonebook. From what it sounds like, if we put this in Firefox the chances are that people aren’t going to notice. I have not seen uses of this thing so far. The most obvious thing that people do know is the German thing, but I have a hack for that that seems like it could work. +HJS: If I can imagine cases where someone would misuse the search collations for search, it may be when someone requests search when they should be using phonebook. Only languages where the difference is meaningful are Finnish, Swedish, Korean (archaic Hangul), Catalan… In Catalan, it's about how "l." behaves. In German it's about "ue". Sort collation (except for German) returns the phonebook. From what it sounds like, if we put this in Firefox the chances are that people aren’t going to notice. I have not seen uses of this thing so far. The most obvious thing that people do know is the German thing, but I have a hack for that that seems like it could work. MWS: One thing is to point out that since the search collations are designed for equality, not order, if someone creates a search collator and expects a certain order, the results could be different, but that would be an abuse of asking for the search collator and then expecting a certain order out of it. -HJS: That’s the webcompat risk here, if it’s actually used for sorting. This discussion gave me a use case that I didn’t think about, the thing when you use it for searching for a list of full matches rather than substring, but it sounds like overall there isn’t a clear use case that I’ve missed. +HJS: That’s the webcompat risk here, if it’s actually used for sorting. This discussion gave me a use case that I didn’t think about, the thing when you use it for searching for a list of full matches rather than substring, but it sounds like overall there isn’t a clear use case that I’ve missed. -SFC: We have issue 256 open here, we want to make sure we understand what the action here – is there any change that we need to make to the ECMA-402 specification. If so, we should list exactly what should be done, otherwise we should resolve it. +SFC: We have issue 256 open here, we want to make sure we understand what the action here – is there any change that we need to make to the ECMA-402 specification. If so, we should list exactly what should be done, otherwise we should resolve it. HJS: So far what I’ve seen is that people notice that there is an API surface for search vs. sort, they find out what it does makes German different, they make a test case for it, can’t say what use case that serves other than “test that the API does what it does” without a use case. -SFC: As a group can we establish that we don’t care if there’s a difference in behavior and that therefore there does not need to be any testing added for it? In which case I can close 256 with that conclusion and refer to the meeting notes for today. +SFC: As a group can we establish that we don’t care if there’s a difference in behavior and that therefore there does not need to be any testing added for it? In which case I can close 256 with that conclusion and refer to the meeting notes for today. FYT: Question: should we add an isEqual API to collator that only returns a boolean to make the search meaningful @@ -187,12 +187,12 @@ FYT: Returns 3 possible values, could be abused MWS: Using a convenience wrapper doesn’t prevent misuse FYT: Currently no correct one to call - + MWS: Different options for if you can expand/shrink a substring [...] don’t know if people want an ECMAScript API for that HJS: I think we shouldn't add more API. I don't want to provoke this question because I don't want that API. I would rather drop the data than add a new API for it. I'm concerned about the data because of how Ctrl-F works in Firefox, which is faster than Chrome or Safari. If there were an API to do locale-aware accent-ignoring search, where it normalizes some diacritics but not others, how much data would you need, assuming you have the UCD and normalization data, I think it would be possible to have it with less data, than starting from the observation that we could start with collator. Would like to avoid the conclusion that because there is data we should add API. Instead: do people have actual requests for the API / demand for the API, and if so what should it be backed by? -SFC: I’d like to record a conclusion. 1: we expect that it’s okay for implementations to differ. 2: Ideally we should document this in prose (either in the spec or MDN) on what this is used for. Currently on MDN: usage: “search” and “sort” are two options, maybe add a few sentences documenting this. +SFC: I’d like to record a conclusion. 1: we expect that it’s okay for implementations to differ. 2: Ideally we should document this in prose (either in the spec or MDN) on what this is used for. Currently on MDN: usage: “search” and “sort” are two options, maybe add a few sentences documenting this. BAN: +1 @@ -212,23 +212,23 @@ Proceed as SFC suggested above. ### User Preferences #580 and #409 -RCA: Two main issues identified in last meeting: 1: sequence of what we’re doing – we’re trying to just return explicitly the values that were changed by the user, decided to 1st check all values that user has on the system, check if there’s privacy settings, return values to user. 2: Research possibilities of having separate buckets of information. We identified two clear buckets based on the preferences that we had on the initial proposal. We decided to have Date/Time and Language/Region as separate buckets, have client hints for Locale-Preferences-LanguageRegion. Something similar in JavaScript API, but most important part of discussion is what the room feels about these buckets – start with this division? Does this to some extent remove fingerprinting vectors? +RCA: Two main issues identified in last meeting: 1: sequence of what we’re doing – we’re trying to just return explicitly the values that were changed by the user, decided to 1st check all values that user has on the system, check if there’s privacy settings, return values to user. 2: Research possibilities of having separate buckets of information. We identified two clear buckets based on the preferences that we had on the initial proposal. We decided to have Date/Time and Language/Region as separate buckets, have client hints for Locale-Preferences-LanguageRegion. Something similar in JavaScript API, but most important part of discussion is what the room feels about these buckets – start with this division? Does this to some extent remove fingerprinting vectors? -FYT: Sec-CH is part of which spec? +FYT: Sec-CH is part of which spec? -RCA: Started with user-locale-client-hints proposal, it’s a work in progress. +RCA: Started with user-locale-client-hints proposal, it’s a work in progress. -FYT: Is client hint WICG or IETF? +FYT: Is client hint WICG or IETF? USA: WICG -RCA: We’ve also opened the issue there. The main discussion we should have is if we are in a good direction (preferences in two buckets). Is this something implementable / sort out the main contention with fingerprinting. +RCA: We’ve also opened the issue there. The main discussion we should have is if we are in a good direction (preferences in two buckets). Is this something implementable / sort out the main contention with fingerprinting. HJS: Would there be some kind of browser level preference (“check this box to honor system-level preferences”), otherwise action at a distance: could this allow for fingerprinting even if the user preference doesn’t directly refer to the web. RCA: Depends on each browser. The browsers that have Client-Hints… the mechanism is already implicit in how it works. For other browsers, it depends on how they choose to expose these preferences or not. -HJS: If it’s not a preference, would it be part of the Chrome concept of high-entropy values for client hints? Chrome has does a reduction of user-preferred languages. Historically logic was that since it was exposed over HTTP that it was therefore acceptable to expose via JavaScript. Chrome is now only using most-preferred language rather than complete list of language preferences in order to reduce fingerprinting possibility. Tradeoff: internationalization vs. privacy. +HJS: If it’s not a preference, would it be part of the Chrome concept of high-entropy values for client hints? Chrome has does a reduction of user-preferred languages. Historically logic was that since it was exposed over HTTP that it was therefore acceptable to expose via JavaScript. Chrome is now only using most-preferred language rather than complete list of language preferences in order to reduce fingerprinting possibility. Tradeoff: internationalization vs. privacy. USA: To address that, I think that since the beginning of this work we’ve put in a number of countermeasures that would limit the usefulness of this for fingerprinting. Make them client hints so that they’re all fully optional, possible discussion of what the user consent flow should be. One extreme: allow all implementations to choose what is their threat vector / what mechanism makes the most sense for them to get user consent. Alternately, dictate a standard. Another thing that was put in directly as a mitigation: bifurcation into buckets. Personal feeling: DateTime bucket contains preferences that are not as sensitive, more difficult to fingerprint a user from them, and also having it significantly improves UX. Having the ability to operate differently for either bucket / give user consent for one bucket but not the only, purely because the (for example) the measurementSystem I have in place makes it much easier to fingerprint me than the hourCycle. @@ -236,11 +236,11 @@ YSZ: I have one question. I think that we do not want to increase the fingerprin RCA: It's the same as user agent client hints. The mechanism is the same, or very similar. -YSZ: If you open a website, do we send this information? +YSZ: If you open a website, do we send this information? RCA: Aside from in Client-Hints, the headers, yes they do. -YSZ: When do we get consent? +YSZ: When do we get consent? RCA: There are low-entropy and high-entropy client hints. I'm not sure about the flow at the level of the UI. But I can confirm that and come back to you. @@ -256,31 +256,31 @@ YSZ: I'm thinking that the buckets will work to avoid getting a lot of permissio HJS: I think it’s a bit problematic to build this feature on the assumption that the get high-entropy features value API. In Chrome, a “privacy budget” which getting high-entropy values exhausts, it’s not explicit consent but if you ask for too many of these, they get blocked. In terms of user experience, this is different from explicit consent. And then, if the assumption is that there is user consent, the question is what kinds of sites are the ones that drive the demand for the feature? On Google Calendar, for example, the calendar app itself has settings like first-day-of-week within itself. And the user is typically logged-in. So would the vision be that Google Calendar would invoke a constant API at some point in the user account lifecycle to import the settings? That's quite significant for whether it's okay to prompt. -RCA: There are two parts of this answer. Use cases as shared on previous presentation – use cases that are already applied when you use native applications. The mechanism itself and user workflow / experience, I’m not sure if we’re in a real place to discuss that, but understand your concern and the importance of protecting this data in a way such that the user knows precisely what is going on. +RCA: There are two parts of this answer. Use cases as shared on previous presentation – use cases that are already applied when you use native applications. The mechanism itself and user workflow / experience, I’m not sure if we’re in a real place to discuss that, but understand your concern and the importance of protecting this data in a way such that the user knows precisely what is going on. -SFC: Two things: The question Romulo originally proposed: are these good buckets? Does the way that we’ve split them make sense. For example: first day of week and calendar, which bucket should they be in. Second comment: it seems like the overall sentiment of this group is that we want to think about the end user experience rather than the mechanism. We’re unclear on what this means for the end result: does this come out of a privacy budget, is it a consent bubble? Need more clarity – that might be a good next step. To answer HJS question re: what is the use case, the goal here is to improve the multilingual web. These are settings that native apps can already access, but that web apps do not necessarily have / can’t use to customize experience. They can only guess based on the Accept-Language header, results in lower-quality experience for users on web platform. Goal is to be fairly broad, in the sense that websites can automatically use (for example) the correct hour cycle if user has hour cycle preferences that differ. +SFC: Two things: The question Romulo originally proposed: are these good buckets? Does the way that we’ve split them make sense. For example: first day of week and calendar, which bucket should they be in. Second comment: it seems like the overall sentiment of this group is that we want to think about the end user experience rather than the mechanism. We’re unclear on what this means for the end result: does this come out of a privacy budget, is it a consent bubble? Need more clarity – that might be a good next step. To answer HJS question re: what is the use case, the goal here is to improve the multilingual web. These are settings that native apps can already access, but that web apps do not necessarily have / can’t use to customize experience. They can only guess based on the Accept-Language header, results in lower-quality experience for users on web platform. Goal is to be fairly broad, in the sense that websites can automatically use (for example) the correct hour cycle if user has hour cycle preferences that differ. RCA: How do you feel about these preferences? Do you feel comfortable with these two buckets, should we have more? -SFC: Let’s take this discussion offline. +SFC: Let’s take this discussion offline. -USA: Regarding the delivery / use of Client-Hints, that decision was taken collaboratively within this group because of concerns raised. Listening to points made by YSZ, if implementers would think it’s safer to have a getter on the navigator object (as in geolocation) that’s a path to go down. Final goal is to give this information that already exists in all modern operating systems to a web developer to actually use the Intl APIs without exposing that to fingerprinters/bad actors. We could certainly redesign this to better fit privacy concerns. +USA: Regarding the delivery / use of Client-Hints, that decision was taken collaboratively within this group because of concerns raised. Listening to points made by YSZ, if implementers would think it’s safer to have a getter on the navigator object (as in geolocation) that’s a path to go down. Final goal is to give this information that already exists in all modern operating systems to a web developer to actually use the Intl APIs without exposing that to fingerprinters/bad actors. We could certainly redesign this to better fit privacy concerns. HJS: At the risk of bringing another point about what's common and what's not, from bug reports I've seen, it seems that a driving use case for overriding this stuff comes from US English being the untranslated language for much of the software business, so if you run nightly builds with the strings that software developers check-in to the repo, en-US is the untranslated thing. This is acceptable language-wise, but it's not acceptable for formatting conventions. The US region is unusual for pretty much all of these preferences being discussed here. Metric units, Celsius, Hour Cycle, etc. That raises a question of, is it known the extent to which people change these settings with all base locales, and the extent to which the desire is driven by changing settings away from the US region? If there was just 1 bit of entropy, like let's flip all of the settings to the international settings, how far would that go? USA: That is something that comes up a lot. However, it doesn’t quite encapsulate a majority of the users we’re thinking about here. Example: the defaults en-US locale can be rather odd, but at the same time it is something that a lot of people in the US are quite comfortable with, that they use for minimal changes. However, en-IN is an awkward mix of everything: spellings, first day of week, and so forth are different than you’d expect, and the numbering system, etc. The idea is how many people have to work around their locale in order to get an i18n experience that they feel works for them. For instance, many people using en-IN would change the numbering system. Does the extant system allow us to express things in this way? -SFC: I have an answer, but it’s longer, can bring this discussion offline. +SFC: I have an answer, but it’s longer, can bring this discussion offline. RCA: We will consider the buckets & experience points mentioned here. SFC: We should bring this up for discussion every month so that we can continue to iterate on it. Good goal by next month is assembling well-documented answers to HJS and YSZ’s questions. -### Temporal issues: #2479 prevent loss of TimeZone information +### Temporal issues: #2479 prevent loss of TimeZone information https://github.com/tc39/proposal-temporal/pull/2479 -PFC: Temporal has a type, ZoneDateTime, that’s an exact time that carries a time zone along with it, it provides time-zone-aware conversion of exact times into wall-clock time, what the intention of this type was that when you format it you get the information presented in the time zone that belongs to the type. For example, what happens if you call toString() on an instance of that type. +PFC: Temporal has a type, ZoneDateTime, that’s an exact time that carries a time zone along with it, it provides time-zone-aware conversion of exact times into wall-clock time, what the intention of this type was that when you format it you get the information presented in the time zone that belongs to the type. For example, what happens if you call toString() on an instance of that type. If I have the exact time (0 seconds since the epoch) and I have the timezone of (say) New York, what I’ll get is Dec. 31st, 1969 at 5 hours before midnight. What we discovered that because of an oversight in the spec text is that it would always ignore the time zone that the object carries with it. In the example given before, you might get 7:00 PM Dec. 31st from toString(), but you’d get whatever it was in the user’s local time zone because that is what would be created when you create a DateTimeFormat without a time zone argument. Focusing discussion on three questions via Justin: @@ -298,13 +298,13 @@ JGT: Could we constrain the discussion to question 1 from the list above? Does a USA: I think clearly ZDT.p.toLocaleString should use ZDT's time zone. I think optionless Intl.DTF should use the ZDT's time zone. -SFC: I think this issue is closely related to issue #750 – what do you do with the time zone change events? ZDT has long had the invariant that the timezone used to construct is used for formatting. There is cost to doing a time zone lookup – it’s not free. One reason we have a constructor is so that we can frontload that lookup cost. It still has to do lookup cost for month name or era name, but doesn’t have to do lookup cost for time zone name. To answer the questions on the board: Clearly option #1 should use time zone. Question #2 is the one where we have to think carefully about what happens here. One proposal that I posted on issue #750 is that we could start by having a strict behavior and having it more lenient over time. Most strict behavior: if you want to format, use toLocaleString. Another option, a little less severe: allow the ZDT but the time zones have to match. Certainly we could say that ZDT is special and we’re going to change how Intl.DateTimeFormat works – follow ZDT? If we think it’s useful for users, we should do it, but it does require work on the implementation side. +SFC: I think this issue is closely related to issue #750 – what do you do with the time zone change events? ZDT has long had the invariant that the timezone used to construct is used for formatting. There is cost to doing a time zone lookup – it’s not free. One reason we have a constructor is so that we can frontload that lookup cost. It still has to do lookup cost for month name or era name, but doesn’t have to do lookup cost for time zone name. To answer the questions on the board: Clearly option #1 should use time zone. Question #2 is the one where we have to think carefully about what happens here. One proposal that I posted on issue #750 is that we could start by having a strict behavior and having it more lenient over time. Most strict behavior: if you want to format, use toLocaleString. Another option, a little less severe: allow the ZDT but the time zones have to match. Certainly we could say that ZDT is special and we’re going to change how Intl.DateTimeFormat works – follow ZDT? If we think it’s useful for users, we should do it, but it does require work on the implementation side. PFC: There are concerns, we’re trying to get to the bottom and find a solution that everyone can agree on, not blocking in TG1. Note that toLocaleString is always equivalent to creating a DateTimeFormat with the options that you pass to toLocaleString call. If we strictly wanted to keep that the case for ZDT we’d have to require that you pass the timezone option in the toLocaleString call – would probably be least useful for users. If we consider question 1 non-controversial, we may have inconsistencies. -FYT: What inconsistencies? +FYT: What inconsistencies? -PCO: What I mean by inconsistencies: An invariant of DateTimeFormat and Date.p.toLocaleString, up until now, is that if you call Date.p.toLocaleString with a locale and options format, it constructs a DTF with that same local and options format. If we want to modify toLocaleString w/ ZDT providing its ZDT, that introduces an inconsistency where the options object you pass to toLocaleString doesn’t match the options passed to DTF +PCO: What I mean by inconsistencies: An invariant of DateTimeFormat and Date.p.toLocaleString, up until now, is that if you call Date.p.toLocaleString with a locale and options format, it constructs a DTF with that same local and options format. If we want to modify toLocaleString w/ ZDT providing its ZDT, that introduces an inconsistency where the options object you pass to toLocaleString doesn’t match the options passed to DTF FYT: I want to clarify, this is not true. Date.p.toLocaleString is not passing the exact options bag into the constructor, so it was consistent. It’s a special case because there’s multiple variants to the toLocaleString and the options bag is always processed before passing in the values. @@ -312,15 +312,15 @@ JGT: Do we have consensus on question #1 FYT: +1 from me -JGT: A plain month/day will ignore all the other options, etc., because there’s no time zone in plain month/day. [other similar examples] We should have a reason/justification for why the time zone is different than all these other options. +JGT: A plain month/day will ignore all the other options, etc., because there’s no time zone in plain month/day. [other similar examples] We should have a reason/justification for why the time zone is different than all these other options. SFC: Great question, the line is clear in my mind. All these adjustments can be precomputed. When I use a PlainMonthDay, I can precompute it in the constructor but with ZonedDateTime, we need to do it in the format function. This is the problem here, that we need to resolve it in the format function instead. -JGT: To clarify, your point here is that this is an implementation issue rather than a consistency issue. FYT objection based on consistency, SFC objection is that it will make things slower/bigger +JGT: To clarify, your point here is that this is an implementation issue rather than a consistency issue. FYT objection based on consistency, SFC objection is that it will make things slower/bigger -FYT: I do have implementation concern, but first level concern is consistency. I do think SFC’s right that the timing of the decision is different. Also, time zone has no conflict – don’t have another object conflicting with you. +FYT: I do have implementation concern, but first level concern is consistency. I do think SFC’s right that the timing of the decision is different. Also, time zone has no conflict – don’t have another object conflicting with you. -RGN: All options make sense from different perspectives, so long as there’s consensus I’ll be satisfied. +RGN: All options make sense from different perspectives, so long as there’s consensus I’ll be satisfied. SFC: There nobody on the queue. I did list some concrete options in one of my posts somewhere, but there are multiple threads. The high level question is: what should the format function do with respect to ZDT. @@ -332,7 +332,7 @@ SFC: There nobody on the queue. I did list some concrete options in one of my po 6. Add some option to the DTF constructor that tweaks this behavior 7. Add Intl.ZonedDateTimeFormat -FYT: I think there’s one additional parameter to take a look into: what would happen if you have a ZDT, call toLocaleString, and we have an option bag which itself has different a time zone – a third time zone now. What should we do? +FYT: I think there’s one additional parameter to take a look into: what would happen if you have a ZDT, call toLocaleString, and we have an option bag which itself has different a time zone – a third time zone now. What should we do? JGT: Explain the three cases you’re talking about – I only see two. @@ -342,7 +342,7 @@ JGT: That’s my question 3: how do we handle conflicts? FYT: There are two different options – Intl.DateTimeFormat and toLocaleString, have to distinguish these two. In the code itself it’s probably glued together in one way to resolve it, but from the calling point of view it’s in two places . -SFC: Generally strongly in favor of making them work the same. In this case it’s probably warranted to do special handling of the time zone format. I think we can isolate that in the toLocaleString function. This question should be answered separate from the more general case. On the toLocaleString, what the behavior should be, there are a few options. +SFC: Generally strongly in favor of making them work the same. In this case it’s probably warranted to do special handling of the time zone format. I think we can isolate that in the toLocaleString function. This question should be answered separate from the more general case. On the toLocaleString, what the behavior should be, there are a few options. 1. Do not read the timeZone option in ZDT.p.tLS (use the ZDT's time zone) 2. Error if timeZone option is in conflict with ZDT's time zone @@ -351,13 +351,13 @@ SFC: Generally strongly in favor of making them work the same. In this case it JGT: My opinion is that #2 is the right behavior, we already have an API for changing the tz of a ZDT, doesn’t seem to be particularly valuable to have another way – if you want to change the timezone, use the Temporal API. -JGT: My vote’s for #2 +JGT: My vote’s for #2 USA: I see the point, but unless the time zone is provided explicitly erroring is not great – feels a bit unexpected. When it is provided, I am happy with either way (if it errors or if it doesnt) JGT: we’re only talking about the case where options are provided, correct? Let’s defer the question of when there’s no timeZone option. -SFC: Option 3. I was thinking option 1 would be best, but we should be strict. Don’t pass a time zone into toLocaleString function – error even if it matches so long as it’s not undefined (which just means inherit from ZDT) +SFC: Option 3. I was thinking option 1 would be best, but we should be strict. Don’t pass a time zone into toLocaleString function – error even if it matches so long as it’s not undefined (which just means inherit from ZDT) JGT: What do we do with timeStyle? @@ -374,7 +374,7 @@ JGT: Fine with #3 PFC: I think this part could be designed offline – doesn’t really have to do with the concern about the PR. I’m fine with option #3, though. -SFC: We resolved this little mini-question. Let’s go back to the big question. If someone creates a DTF from the constructor and passes in a ZDT, what do we do? 1: never accept it, 2: only accept it if they match, 3: use timezone from ZDT but only if constructor had an undefined time zone, 4: always use ZDT’s time zone and ignore DTF time zone. Options 3 and 4 require us to change the format function. +SFC: We resolved this little mini-question. Let’s go back to the big question. If someone creates a DTF from the constructor and passes in a ZDT, what do we do? 1: never accept it, 2: only accept it if they match, 3: use timezone from ZDT but only if constructor had an undefined time zone, 4: always use ZDT’s time zone and ignore DTF time zone. Options 3 and 4 require us to change the format function. FYT: Option 3, when you say use its time zone, which are you talking about? @@ -384,21 +384,21 @@ JGT: The question about when the system time zone changes is in these cases when SFC: that’s 750, we don’t need to decide that right now. -FYT: Are we talking about only the format function? +FYT: Are we talking about only the format function? SFC: The format function of DTF. Not talking about toLocaleString -FYT: In that case, implicit time zone change has no impact, the only thing that changes is the DTF constructed after that, we can remove that part of implicit system timezone change. +FYT: In that case, implicit time zone change has no impact, the only thing that changes is the DTF constructed after that, we can remove that part of implicit system timezone change. JGT: Probably another option: add an option to the DTF constructor, an auto option for time zone. Not saying we should do that, just saying it’s another option. SFC, to answer questions about what I’d prefer: I don’t like #1, because we should be able to format these things, #2 is fine because it matches the behavior we were talking about from toLocaleString, #3 also okay, and I do not like 1, 4, 5, and I haven’t given 6 enough thought. SFC: My opinion: [ ] consider option 3, not happy with option 2 because it’s a footgun: I don’t like throwing exceptions in cases where you just didn’t test it, option 2 seems like a case where that would happen. If we’re not going to be re-architecting anything, safest to start with option 1. Option 7: add Intl.ZonedDateTimeFormatter, add new class w/ this custom behavior. If we did option 1, we can move to another later. Option 5 might be surprising – ZDT should be, conceptually, the one that wins. -PFC: Preference; I don’t like 1, 5, 6, or 7. The PR that’s up for discussion, the current state of it, does something similar to 3, but not quite. +PFC: Preference; I don’t like 1, 5, 6, or 7. The PR that’s up for discussion, the current state of it, does something similar to 3, but not quite. FYT: That’s 4, right? -PFC: Yes, you’re right. +PFC: Yes, you’re right. FYT: I object to 3 and 4. Both impacts design and also implementation. 3 impacts performance, impact all things about date benchmark for toLocaleString(), big impact on memory usage. @@ -414,11 +414,11 @@ FYT: In order to do 2, you have to make a spec change. In order to do #3, your s JGT: Intl.DateTimeFormat.Format could get slower -FYT: The toLocaleString of the date _is_ calling that one. +FYT: The toLocaleString of the date _is_ calling that one. SFC: Note that #4 is best from user perspetive -FYT: how can it be good for the user to have two different time zones? Totally against use case. +FYT: how can it be good for the user to have two different time zones? Totally against use case. SFC: Most of the time the DTF is constructed with undefined tz. If you construct it with an explicit timezone the ZDT also has an explicit timezone, and that one is more explicit. @@ -428,9 +428,9 @@ SFC: If you don’t care about the time zone, you should use Temporal.Instant or JGT: I think my preference now is for 3, because if you specify an explicit time zone that’s part of the options, and ZDT has a different time zone, for the same reason we decided to not allow that in toLocaleString, that holds true here – it’s unclear which should win. If it’s undefined in DTF, support pulling it from ZDT -USA: The rationale that you gave does make sense, but for the sake of consensus I concur that 3 sounds like a good way forward, consistent with the way we deal with things. Also something we can get consensus on – realistically, why not? +USA: The rationale that you gave does make sense, but for the sake of consensus I concur that 3 sounds like a good way forward, consistent with the way we deal with things. Also something we can get consensus on – realistically, why not? -SFC: I’ve heard concrete concerns about all options – my understanding is that the concern with option 1 is that we should be able to format these, weird that we cant in DTF, concern with 2 is that it’s unlikely to be caught before deployed, option 3, changes data model of DTF, increases memory usage, impacts formatting of other types of objects, option 4, it doesn’t retain the memory of the DTF timeZone which is an explicit option, concern with 5 same but the other way around, concern with 6 and 7 we haven’t discussed. I don’t see any of these as near consensus +SFC: I’ve heard concrete concerns about all options – my understanding is that the concern with option 1 is that we should be able to format these, weird that we cant in DTF, concern with 2 is that it’s unlikely to be caught before deployed, option 3, changes data model of DTF, increases memory usage, impacts formatting of other types of objects, option 4, it doesn’t retain the memory of the DTF timeZone which is an explicit option, concern with 5 same but the other way around, concern with 6 and 7 we haven’t discussed. I don’t see any of these as near consensus PFC: When evaluating these competing priorities, I like to use the w3c priority of constituencies argument. For me the concern with 3 (change of data model) weighs less than concerns with 2 (people might get exceptions in production that go unfound in testing). Different levels of concern, framework like priority of consistencies helpful here. @@ -442,12 +442,12 @@ FYT: In that case both DTF and now would return the same result, would not throw PFC: If you get ZDT from a string (from a database, etc.) it might differ -JGT: SFC, your argument is pretty compelling. The vast majority of DTF generated will have no timeZone option, we should optimize for that case, if people start using ZDT and pass into an existing DTF (create without parameters, which most are) it could cause problems. +JGT: SFC, your argument is pretty compelling. The vast majority of DTF generated will have no timeZone option, we should optimize for that case, if people start using ZDT and pass into an existing DTF (create without parameters, which most are) it could cause problems. -FYT: The argument of “majority don’t pass time zone” is unreasonable. Discussion of how many of them don’t have a time zone shouldn’t be considered – 100% of them are not passing Temporal. +FYT: The argument of “majority don’t pass time zone” is unreasonable. Discussion of how many of them don’t have a time zone shouldn’t be considered – 100% of them are not passing Temporal. -SFC: One thing we’ve achieved is that we more clearly understand everyone’s concerns – maybe we can follow up on PR and find something we can agree on. +SFC: One thing we’ve achieved is that we more clearly understand everyone’s concerns – maybe we can follow up on PR and find something we can agree on. -JGT: Maybe remove the ones no one likes? +JGT: Maybe remove the ones no one likes? SFC: Will include the list in the post I make. diff --git a/meetings/notes-2023-03-09.md b/meetings/notes-2023-03-09.md index 52053ba7..241fc173 100644 --- a/meetings/notes-2023-03-09.md +++ b/meetings/notes-2023-03-09.md @@ -18,7 +18,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -29,7 +29,7 @@ https://github.com/tc39/proposal-temporal/pull/2516 -JGT: Canonicalization of time zone names is a bit of a mess. There is a fork of the TZDB with different behaviors; one of the latest behaviors involves merging time zones across countries. For example, Atlantic/Rekjavic would be merged into Africa/Abidjan. For the purposes of Temporal, that’s really not going to work. Say you have a meeting scheduled in Iceland but there’s some timezone changes, it would break the calendar. No implementations accept this fortunately. There are 2 ways to determine the canonical IDs, though. Firefox uses the TZDB and removes the region merging. But V8 and WebKit use ICU/CLDR, which uses its own canonicalization format, maintained separately from TZDB. The biggest difference, the net result for users is that the difference here is mostly down to city name changes in the recent past, like Saigon / Ho Chi Minh City. Those renames have not caught up in V8 and WebKit and that has led to a lot of user complaints that I’ve linked to. CLDR is aware of the problem but one of the current behaviors of ICU is to never change canonical tz identifiers. There’s a lot of complaints about these but Temporal would make most of these issues more visible to users and JavaScript developers. Saving to a database and reloading would expose these inconsistencies. As soon as Temporal is adopted, it’ll greatly increase the amount of user complaints. Here’s some possible goals as outlined in the thread. +JGT: Canonicalization of time zone names is a bit of a mess. There is a fork of the TZDB with different behaviors; one of the latest behaviors involves merging time zones across countries. For example, Atlantic/Rekjavic would be merged into Africa/Abidjan. For the purposes of Temporal, that’s really not going to work. Say you have a meeting scheduled in Iceland but there’s some timezone changes, it would break the calendar. No implementations accept this fortunately. There are 2 ways to determine the canonical IDs, though. Firefox uses the TZDB and removes the region merging. But V8 and WebKit use ICU/CLDR, which uses its own canonicalization format, maintained separately from TZDB. The biggest difference, the net result for users is that the difference here is mostly down to city name changes in the recent past, like Saigon / Ho Chi Minh City. Those renames have not caught up in V8 and WebKit and that has led to a lot of user complaints that I’ve linked to. CLDR is aware of the problem but one of the current behaviors of ICU is to never change canonical tz identifiers. There’s a lot of complaints about these but Temporal would make most of these issues more visible to users and JavaScript developers. Saving to a database and reloading would expose these inconsistencies. As soon as Temporal is adopted, it’ll greatly increase the amount of user complaints. Here’s some possible goals as outlined in the thread. 1. Enable us to make changes, both to the names already missing, reflecting the backlog. 2. There’s the case of future name changes and coming up with a strategy on how to do this. @@ -43,33 +43,33 @@ I have outlined a few proposals for solving this problem. 2. We would expose this identifier everywhere necessary in Temporal. I don’t mind how we choose to deal with resolvedOptions().timeZone, we could really go either way. 3. … -If I’ve called it Kiev, and I refer to it as Kiev, that still works even though the spelling has changed to Kyiv. Overriding concern: if we don’t do this, it would make it so difficult to change these canonicalizations in the future that we’d be stuck with whatever canonicalizations we had when Temporal shipped, with no way to change it later. +If I’ve called it Kiev, and I refer to it as Kiev, that still works even though the spelling has changed to Kyiv. Overriding concern: if we don’t do this, it would make it so difficult to change these canonicalizations in the future that we’d be stuck with whatever canonicalizations we had when Temporal shipped, with no way to change it later. -Options: +Options: 1. Everyone could switch to CLDR, but that doesn’t change the core problem that we have these very populous regions (India, Vietnam…) that are colonial and probably offensive to a large number of people. -2. Do it like Firefox: It does update with name changes, the challenge is that if we update everything whenever something changes, that does mean that it runs the risk of breaking the web when canonicalization changes. +2. Do it like Firefox: It does update with name changes, the challenge is that if we update everything whenever something changes, that does mean that it runs the risk of breaking the web when canonicalization changes. 3. There’s a fork of Java that behaves very similar to the Firefox implementation -4. Leave Firefox as-is, Chrome and WebKit can hardcode these thirteen names +4. Leave Firefox as-is, Chrome and WebKit can hardcode these thirteen names 5. Status quo: do nothing -JGT comfortable with any option but 5. +JGT comfortable with any option but 5. -SFC: Option #5 – the status quo is that things are not consistent across the web platform, and this leaves open the option that we continue to discuss, and converge on a good solution over time. That is okay to do. Option 5 just means “we’re not going solve it now, we’ll solve it later.” +SFC: Option #5 – the status quo is that things are not consistent across the web platform, and this leaves open the option that we continue to discuss, and converge on a good solution over time. That is okay to do. Option 5 just means “we’re not going solve it now, we’ll solve it later.” -JGT: Main concern is that once Temporal is released, changing canonicalization behavior could be much more disruptive than it is now. While it’s true that we can change things work in the future, the cost of making those changes later is a lot higher than the cost of making it now. +JGT: Main concern is that once Temporal is released, changing canonicalization behavior could be much more disruptive than it is now. While it’s true that we can change things work in the future, the cost of making those changes later is a lot higher than the cost of making it now. USA: Every other timezone name-change would keep increasing the stakes as well SFC: Reiterate concern with “option 0” (proposed behavior). Temporal should not be in the business of creating its own scheme, for example case-mapping names to reflect IANA IDs. ECMAScript should not be in the business of describing this – if we could point to another specification and say “here’s how you do weak canonicalization, here’s how you do heavier canonicalization”, and say “those are defined in UTS-35.” Here we’re going out on a limb and saying “here’s what weak canonicalization is for identifiers.” We could try to get that in UTS-35 and use that in Temporal – that’s not something that’s going to happen overnight, but if we were to go in this direction it’s how we should do it. We should not in ECMA-402 invent canonicalization schemes. -Options 2, 3, and 4 look similar except for how they’re implemented in browsers. +Options 2, 3, and 4 look similar except for how they’re implemented in browsers. So I see the choices as being option 1, use CLDR names, option 2, use IANA names, skip to 5, leave it for now and investigate. I understand JGT’s concern that Temporal makes this more front and center, but I don’t think we’re going to have a specification written tonight. I see this as something we can start to work on, and it will be fixed maybe in a year. This will likely align with when Temporal is going to be available anyway. I agree this is a problem we should fix, but I don’t see that it needs to block Temporal right now – these can be done in parallel. Leave it as a Stage 1 proposal. Say "here’s a standalone proposal, it doesn’t block on Temporal and Temporal doesn’t block on it." RGN: It is inaccurate to call this as a new canonicalization scheme, since IANA has zones and links. There are multiple spellings for Kolkata for example. What we have right now is a specification which no implementation follows except probably Firefox. The question is if we should bring them together or if we need to make some adjustments to the spec. -YSZ: Unlike Firefox and Chrome, Safari, specifically Safari, is using the system ICU. This means that Firefox/Chrome are shipping [...] basically, at browser level they are shipping ICU aligned with their version, so when ICU is updated or engine is updated, there are no problems. We are having a different mechanism to update timezone separate from ICU. It is very hard to encode the hardcoded code into the Safari side. In Safari side, we are not well-aligned to the specific ICU version, so if we need +YSZ: Unlike Firefox and Chrome, Safari, specifically Safari, is using the system ICU. This means that Firefox/Chrome are shipping [...] basically, at browser level they are shipping ICU aligned with their version, so when ICU is updated or engine is updated, there are no problems. We are having a different mechanism to update timezone separate from ICU. It is very hard to encode the hardcoded code into the Safari side. In Safari side, we are not well-aligned to the specific ICU version, so if we need JGT: A few things. On process, I agree with SFC that this could be a separate independent proposal focused on 402. I would be happy to help champion this, but I'd like to partner with someone more familiar with the proposal process. And SFC mentioned that we would be inventing our own casing canonicalization. My understanding is that the semantics of an ASCII-case-insensitive database are well understood. I don't see that as us inventing a scheme, but looking up something in TZDB and reporting what we find. That's better than browsers making their own decisions. I don't understand deeply the limitations of ICU and what that means for the choices in this proposal. For timing, I agree that it may take a while. But I think we shouldn't wait to start in a year. @@ -77,19 +77,19 @@ SFC: It doesn’t seem to be an elegant solution to store both a partially canon YSZ: Sounds reasonable to me. -RGT: Regarding the canonicalization of case, it is trivial. “Use the form that appears in the database.” It’s all ASCII, case insensitive, use the form that’s in the database. +RGT: Regarding the canonicalization of case, it is trivial. “Use the form that appears in the database.” It’s all ASCII, case insensitive, use the form that’s in the database. SFC: So we’re still looking up the timezone in the timezone database RGT: You can’t canonicalize invalid input. It has to be in the database. Also, though, canonicalization may not be the right term. It’s just “do you follow links or not” The policy of the timezone database has made this more awkward, since the links can vaporize at any time. -HJS: Ideally the way forward is ICU having an API for acquiring the IANA canonical name, but I’m doubting the level of problem until that API appears that Safari would hardcode stuff. Some of these names are 30 years old, so it doesn’t look like they come up very often. It seems feasible to me to have a hard-coded list until such time as you can assume that whatever ICU version is going to have the future ICU API. This doesn’t look to me like a hard reason to block the IANA names. For BCP47, whenever a new timezone appears, there is a need to mint a BCP47 identifier for it, and that does not seem to materialize in the IANA data. Is the story for that that ICU provides that mapping and that therefore it doesn’t need to be hard-coded on the application side? +HJS: Ideally the way forward is ICU having an API for acquiring the IANA canonical name, but I’m doubting the level of problem until that API appears that Safari would hardcode stuff. Some of these names are 30 years old, so it doesn’t look like they come up very often. It seems feasible to me to have a hard-coded list until such time as you can assume that whatever ICU version is going to have the future ICU API. This doesn’t look to me like a hard reason to block the IANA names. For BCP47, whenever a new timezone appears, there is a need to mint a BCP47 identifier for it, and that does not seem to materialize in the IANA data. Is the story for that that ICU provides that mapping and that therefore it doesn’t need to be hard-coded on the application side? JGT: HJS, you are correct that these are really rare. The last one I can think of is Kiev -> Kyiv. I would estimate that one of these gets renamed every year or so, so not very frequent, and some of these renames are very small jurisdictions that won’t see much use at all. One note: I would assume that if we do a proposal for this, it’s really a proposal for the spec text rather than a proposal for the ICU API – I’m not really qualified to make a proposal for ICU, but will need someone else to drive that. I’m happy to drive the spec text. I agree with RGT about how canonicalization works: it really is “take the tz database, convert it to database, take the user’s identifier and convert it to lowercase, see if there’s a map.” Very straightforward. Agree with RGT: the spec says we should follow links, but no one follows links, and the spec is not clear on which links should be followed and which parts of ECMAScript should follow links and which should not follow linked. -SFC: Does the decision we make here affect timezone equality? +SFC: Does the decision we make here affect timezone equality? -JGT: My instinct is that the only thing that this decision should impact is the user-viewable identifiers, everything else ECMAScript does should be the same, including the equality of ZoneDateTime objects. Changing the name from Kiev to Kyiv should not cause two to be unequal. We could, though, add an API that allows users to check if two time zone identifiers resolve to current value. Ways to do this in current spec, but we could add more ergonomic ways to do it. If the goal of the proposal is to make ECMAScript code less brittle in terms of changes in time zone names, it would be a mistake to not have equality “canonicalize both values, and if they’re the same then they’re equal.” +JGT: My instinct is that the only thing that this decision should impact is the user-viewable identifiers, everything else ECMAScript does should be the same, including the equality of ZoneDateTime objects. Changing the name from Kiev to Kyiv should not cause two to be unequal. We could, though, add an API that allows users to check if two time zone identifiers resolve to current value. Ways to do this in current spec, but we could add more ergonomic ways to do it. If the goal of the proposal is to make ECMAScript code less brittle in terms of changes in time zone names, it would be a mistake to not have equality “canonicalize both values, and if they’re the same then they’re equal.” #### Conclusion @@ -101,13 +101,13 @@ https://docs.google.com/presentation/d/1b74GI-zHrG0wDzmwFs_yPWRli24KyVUNx3GeZt8J https://github.com/tc39/proposal-temporal/pull/2479 -JGT: Today in ECMAScript no ECMAScript object that can be formatted by `Intl.DateTimeFormat` carries a timezone with it. With Temporal.ZonedDateTime, this object carries a timezone, and there’s a potential conflict. The goal for solving this is to recognize that a very large percentage of Intl.DateTimeFormat objects were not created with an explicit `timeZone` option. Assumption is that we can create a DateTimeFormat object and format it with at ZoneDateTime timezone and have it give the ZoneDateTime time zone. +JGT: Today in ECMAScript no ECMAScript object that can be formatted by `Intl.DateTimeFormat` carries a timezone with it. With Temporal.ZonedDateTime, this object carries a timezone, and there’s a potential conflict. The goal for solving this is to recognize that a very large percentage of Intl.DateTimeFormat objects were not created with an explicit `timeZone` option. Assumption is that we can create a DateTimeFormat object and format it with at ZoneDateTime timezone and have it give the ZoneDateTime time zone. What we’re considering is: what happens if the DateTimeFormat object has a time zone as well? There’s a potential conflict between DateTimeFormat and ZoneDateTime. Option: if the DateTimeFormat object has a timezone, throw. We try not to have data-driven exceptions in Temporal, we try to throw based on the shapes of the inputs rather than the data in those inputs. SFC: This isn’t my first-choice approach, but it seems to be closest to a consensus response among Temporal champions. The proposed change is that DateTimeFormat objects would have two states: one where there is an explicit timezone, and one where there isn’t, and recording this state somewhere. Requires a one-bit change to Intl.DateTimeFormat data model. -JGT: Note that Date.toLocaleString() cannot use ZoneDateTime, so it’s possible to have no additional data stored when calling Date.toLocaleString(), but one additional bit of data stored with DateTimeFormat. Note that DateTimeFormat’s entire purpose is a more performant version of toLocaleString(), at least that’s my understanding. So if we're concerned about toLocaleString performance, then it'd be possible to specify and implement this change to have no impact at all on toLocaleString. (Not saying we must do this because it'd be extra work, but it's possible if perf is a problem for toLocaleString after this change.) +JGT: Note that Date.toLocaleString() cannot use ZoneDateTime, so it’s possible to have no additional data stored when calling Date.toLocaleString(), but one additional bit of data stored with DateTimeFormat. Note that DateTimeFormat’s entire purpose is a more performant version of toLocaleString(), at least that’s my understanding. So if we're concerned about toLocaleString performance, then it'd be possible to specify and implement this change to have no impact at all on toLocaleString. (Not saying we must do this because it'd be extra work, but it's possible if perf is a problem for toLocaleString after this change.) Also, because DateTimeFormat objects are intended to be re-used, users won't be creating many of these objects. Adding a little bit of memory when there are few created in order to get performance over time, this seems like an OK tradeoff. Users shouldn’t be creating millions of these anyway, since that would be a very bad performance idea. @@ -123,43 +123,43 @@ SFC: Talking of restriction to sets here, it puts the onus on us to define what HJS: Talking about the region overrides, what level of overlap exists. How many combinations exist ignoring currencies. Maldives for example is a strong edge case. The question is how many of those region overrides cluster up? -SFC: I can answer in terms of measurement units and such. In most regions, hour cycles fall in one of two categories. In terms of unit measurements, there’s a big common metric group but there are known deviations from that in particular instances. So probably measurement units could be brought down to ten major categories. Measurement units, however, are not a monolith. It’s usually much more nuanced in some instances. A fairly common case is folks who use Celsius for temperature but for example stick to Imperial for road measurements/distances. +SFC: I can answer in terms of measurement units and such. In most regions, hour cycles fall in one of two categories. In terms of unit measurements, there’s a big common metric group but there are known deviations from that in particular instances. So probably measurement units could be brought down to ten major categories. Measurement units, however, are not a monolith. It’s usually much more nuanced in some instances. A fairly common case is folks who use Celsius for temperature but for example stick to Imperial for road measurements/distances. AVK: I don’t think we need to globally broadcast these highly specific preferences to the world. -SFC: In the Intl APIs, when you use them they should be able to infer the user’s preferences. Take hour cycle for example. Right now there’s no way for a user to specify which hour cycle to use for displaying dates on a website. If a user visits 20-30 domains on a day-to-day basis, it allows you to communicate these preferences. There is currently no way for us to find user’s unit preferences on the web which means unit formatting is blocked on that. The status quo is exactly what Anne describes. All websites that do this currently have to develop individualized solutions, which goes against the ideal of the multilingual web. +SFC: In the Intl APIs, when you use them they should be able to infer the user’s preferences. Take hour cycle for example. Right now there’s no way for a user to specify which hour cycle to use for displaying dates on a website. If a user visits 20-30 domains on a day-to-day basis, it allows you to communicate these preferences. There is currently no way for us to find user’s unit preferences on the web which means unit formatting is blocked on that. The status quo is exactly what Anne describes. All websites that do this currently have to develop individualized solutions, which goes against the ideal of the multilingual web. HJS: If you browse the web in multiple languages, the general idea is that the text of those sites doesn’t auto translate under this proposal, it just changes certain things like how certain elements are formatted. The user might expect those elements to conform to the surrounding context of the site, and it may be confusing to change them to the user’s locale in the context of foreign text. I had to once check a website on multiple browsers to check exactly when a certain event happened. For instance, interpreting the 12 hour hour-cycle is pretty universally understood by English readers. Considering how the C stdlib has pretty much failed in Intl means that everyone uses ICU instead of the standard library, given how it reacts to changes in the underlying locale. … There aren’t objections but skepticism arising from other contexts regarding how we should fundamentally approach this issue. -YSZ: At the moment, we have the following mental model: <>, some of the users cannot understand the Arabic numbering system. Some systems have capacity to explicitly specify the change in this numbering system in the same locale. Internationalized numbers cannot be understood by the users. THis is represented as a Unicode extension, but we’re thinking that this is the part of the locale, and this should be exposed without asking things. Needs to be super carefully bucketed inside the system. Example case: hourCycle, Celcius/Fahrenheit, kilometers/miles, this does not prevent the user from understanding the content. I don’t have an idea immediately – if you see Arabic numbers, I can’t see if these are even numbers. We need to have a way to get user consent, current thinking is that we’d prefer offering the HTML form element and showing a picker, so that the user explicitly sets the set of preferences. In this case we don’t need to show any prompt, because the user is explicitly pushing the form, we can use this Unicode extension data and pass it to existing i18n API. I think that we are not agreeing much about exposing the user preference by default implicitly. We could like to explore a way to get this information from the user explicitly. For the super-critical things, we’d like to implicitly include it as part of the locale. +YSZ: At the moment, we have the following mental model: <>, some of the users cannot understand the Arabic numbering system. Some systems have capacity to explicitly specify the change in this numbering system in the same locale. Internationalized numbers cannot be understood by the users. THis is represented as a Unicode extension, but we’re thinking that this is the part of the locale, and this should be exposed without asking things. Needs to be super carefully bucketed inside the system. Example case: hourCycle, Celcius/Fahrenheit, kilometers/miles, this does not prevent the user from understanding the content. I don’t have an idea immediately – if you see Arabic numbers, I can’t see if these are even numbers. We need to have a way to get user consent, current thinking is that we’d prefer offering the HTML form element and showing a picker, so that the user explicitly sets the set of preferences. In this case we don’t need to show any prompt, because the user is explicitly pushing the form, we can use this Unicode extension data and pass it to existing i18n API. I think that we are not agreeing much about exposing the user preference by default implicitly. We could like to explore a way to get this information from the user explicitly. For the super-critical things, we’d like to implicitly include it as part of the locale. -USA: I think +USA: I think BAN: I love the distinction made by Yusuke between UI-critical and non-critical things. That said, there’s a grey area here. For example, a ticketing app having minor misunderstandings can cause a lot of problems. Regarding the translation question, I would prefer the elements to be translated. EAO: Two things: firstly, what Henri mentioned about the list of use cases. It would be nice to hear about that list of use cases. Secondly, what I was really thinking about, when talking about user preferences where the user doesn’t set the preferences, for example in a public computer. These user preferences would be telling the website the wrong information. Is there a way to get this toggling mechanism, or would a website be able to integrate it? And if so, will they have to forgo user preferences completely? -RCA: Thank you for the explainer. In my experience we have different problems to solve: first, what data do we want to expose, but also and maybe more important, the mechanism we use to avoid users exposing information in a non-informed way. Traditional popups not the best UX, taking the data directly from the OS to pick preferences for the website is not optimal, but there is a middle ground here where browsers on their settings can set that these preferences are not exposed, and users must opt in to exposing that information. The host should make accessing this information as difficult as possible. -No clear idea how the buckets would work in reality. +RCA: Thank you for the explainer. In my experience we have different problems to solve: first, what data do we want to expose, but also and maybe more important, the mechanism we use to avoid users exposing information in a non-informed way. Traditional popups not the best UX, taking the data directly from the OS to pick preferences for the website is not optimal, but there is a middle ground here where browsers on their settings can set that these preferences are not exposed, and users must opt in to exposing that information. The host should make accessing this information as difficult as possible. +No clear idea how the buckets would work in reality. -HJS: Some of the thoughts from earlier were the same as the webkit standards position comment. There was the idea in there that there could be buckets for these options. There was a mention that webkit does something like this, but it’s an undocumented setting on NSLocale – is that mechanism documented somewhere in public so that other vendors can see what’s being referred to as a precedent. +HJS: Some of the thoughts from earlier were the same as the webkit standards position comment. There was the idea in there that there could be buckets for these options. There was a mention that webkit does something like this, but it’s an undocumented setting on NSLocale – is that mechanism documented somewhere in public so that other vendors can see what’s being referred to as a precedent. -YSZ: Quick comment, are these things public or not. +YSZ: Quick comment, are these things public or not. SFC: Two general things here: first, regarding the idea of ambient preferences. We can conclude that the best solution would be for all Intl APIs to use a selected locale. That said, there’s also the thing regarding the default locale. It is a limitation of the current web platform to not use the full set of locale options that are specified in the Unicode spec. The second question is, can there be a line between essential and non-essential preferences? That’s a gray area. Numbering systems for example is well supported. In terms of measurement units, it’s harder to draw this line. It’s true that people in the world can do a conversion inside their head, but it would be bad for accessibility to mandate that. For hour cycles, it’s easier to accept but it’s a bit harder for people to read the time with the opposite hour cycle so it gets to a situation where we have to judge which sets of preferences are more important than the others. Maybe it’s possible, but I’m skeptical when I hear this. -BAN: There’s two ways to think about getting the most coverage. One is to find the sets of preferences which covers the most individual users, which we can determine with user research, and the other is to find the set of overlapping preferences that cover the widest range of users, even if this doesn’t necessarily cover the maximum number of users. +BAN: There’s two ways to think about getting the most coverage. One is to find the sets of preferences which covers the most individual users, which we can determine with user research, and the other is to find the set of overlapping preferences that cover the widest range of users, even if this doesn’t necessarily cover the maximum number of users. USA: Raises the question of fairness: I don’t want to be in the position of answering these questions. Although I do like the idea of restricting user choice, I’m not certain that the end result will be equitable. -AVK: The things that aren’t mentioned here are privacy, and preventing minority groups from being identified. The more bits you expose, the more potentially dangerous it is. We can’t just trust websites to do the right thing. +AVK: The things that aren’t mentioned here are privacy, and preventing minority groups from being identified. The more bits you expose, the more potentially dangerous it is. We can’t just trust websites to do the right thing. EAO: I think your characterization is in general right, but for me the main concern is what happens when things don’t go quite completely right. Let’s say that my user preferences would be that I want to experience the web in German, but I want to use miles for distance measurements. What happens if I instead end up in a page that’s not available in English, and I’m seeing some distance measurements without explicit statement of users. What I have here, I have only given the language locale preference, German wasn’t available so we fell back to English, so it’s in miles. Here we’re introducing more dimensions in which things can go not as expected. My sense is that this is likely to lead to more confusion and less benefit than solving the problem of making sure that numbers can easily be formatted, providing an API that allows for easy formatting, so that a website that wants to make things more configurable can in this context ask the user for that data, and to use that to generate content. SFC: The way I look at that we have i18n goals and we have privacy goals. It’s important for us to align on what are acceptable outcomes in terms of an i18n perspective, and then find a way to meet these goals that also reflects the concerns from the privacy perspective. Acknowledge that we do have these two competing group of stakeholders, and as the i18n groups we need to be clear on what the acceptable outcomes are from the i18n perspective. -HSJ: First of all to highlight again that some of these problems have existing solutions that are acceptable i18n-wise and don’t have the associated privacy problems. Going again with the example of a formatted date on a website, in such cases it’s very unhelpful to render something in the context of the user instead of the context of the website. When I used a Danish website to buy train tickets, choosing the English language, the JavaScript datepicker used the date in the American format. There is no US involved here: Denmark uses ISO weeks, I use ISO weeks. If the site used HTML date pickers, it could have come from the browser settings without the privacy issue. There are solutions to some of these that already resolve the tension between i18n concerns and privacy concerns. It could be the case that looking at use cases enough there are use cases that expose this, but there’s still the question of the user not being able to tell if their preferences are being honored or not. And then there’s the question of are there alternative designs that solve both i18n and privacy problems. +HSJ: First of all to highlight again that some of these problems have existing solutions that are acceptable i18n-wise and don’t have the associated privacy problems. Going again with the example of a formatted date on a website, in such cases it’s very unhelpful to render something in the context of the user instead of the context of the website. When I used a Danish website to buy train tickets, choosing the English language, the JavaScript datepicker used the date in the American format. There is no US involved here: Denmark uses ISO weeks, I use ISO weeks. If the site used HTML date pickers, it could have come from the browser settings without the privacy issue. There are solutions to some of these that already resolve the tension between i18n concerns and privacy concerns. It could be the case that looking at use cases enough there are use cases that expose this, but there’s still the question of the user not being able to tell if their preferences are being honored or not. And then there’s the question of are there alternative designs that solve both i18n and privacy problems. DM: I am sympathetic to this proposal living in Canada. That being said, I want to echo some points made. For example, the privacy concerns are very important. If we develop a great solution i18n-wise, but the privacy tradeoffs don’t work, it would be difficult to put it to work. To do user research for picking up the major buckets we’d need to cater to a large majority. From those points of view, I have serious reservations about how well it’d do in the larger committee. For now, I’d say that the UX benefits don’t clearly outweigh the privacy costs here while being more sympathetic that average to Intl benefits. @@ -169,7 +169,7 @@ EAO: How much is this a problem for the English locale? Since it’s so widespre HSJ: There has already been the suggestion to drop something like currency since it’s much more likely to cause fingerprinting. Collation for example also seems to me to be a very locale-specific problem. Since it’s a very relevant one for Taiwan, it’s definitely important. -Conceivably someone could pick some of the other ones, but the other ones potentially the traditional collation is a thing. CLDR has it for Finnish and Swedish. For Finnish I can say confidently that users don’t care about it, for Arabic I’m not certain it matters for the Web that CLDR ships what’s old for ICU. For CLDR, they don’t want to unship a thing that has been shipped. For the collation one, Taiwan and maybe Spain are ones where there are two different choices. +Conceivably someone could pick some of the other ones, but the other ones potentially the traditional collation is a thing. CLDR has it for Finnish and Swedish. For Finnish I can say confidently that users don’t care about it, for Arabic I’m not certain it matters for the Web that CLDR ships what’s old for ICU. For CLDR, they don’t want to unship a thing that has been shipped. For the collation one, Taiwan and maybe Spain are ones where there are two different choices. BAN: Something I’ve been thinking about is that some amount of this data is necessary to be exposed for localization and is there a case to be made that we need to design mechanisms to ensure that when that information is exposed, it’s exposed in as responsible a way as possible. @@ -177,13 +177,13 @@ USA: Related to what EAO mentioned, from my understanding there’s at least a n SFC: In response to what HJS said, that seems like another path. We support zh-TW and zh-TW with Pinyin collation, if that’s a common use case. We could support en-US and en-US with celsius – variations on existing locales. That’s an interesting direction to explore. We currently support any variation of language, script, and region. We could take this set of 250 of the most major language-script pairs and increase it to 275, we’re increasing the combinations that users can specify. -EAO: Voicing my support for that idea: talking about or considering a set of individual locales or sub-locales for which we would be solving actual real-world problems within these groupings, so the question of Taiwan, American English with Celcius, would be much easier to start verifying that these populations are sufficiently large that we could get some utility for something like this with fewer privacy concerns. +EAO: Voicing my support for that idea: talking about or considering a set of individual locales or sub-locales for which we would be solving actual real-world problems within these groupings, so the question of Taiwan, American English with Celcius, would be much easier to start verifying that these populations are sufficiently large that we could get some utility for something like this with fewer privacy concerns. BAN: I have enough info to proceed. It seems like the group consensus is to focus on selecting commonly used sets and also pinpoint the most popular ones. SFC: That’s certainly a proposal that was raised. -AVK: I think you need to first come up with a set in order to perform a proper privacy analysis. I feel that most popular places to see things like temperatures and distances come with individual toggles to choose the appropriate units. Things certainly get more complicated but you need to find out which problems that bothers users most. +AVK: I think you need to first come up with a set in order to perform a proper privacy analysis. I feel that most popular places to see things like temperatures and distances come with individual toggles to choose the appropriate units. Things certainly get more complicated but you need to find out which problems that bothers users most. BAN: It seems like the numbering system is the higher priority thing here since that’s one of the bigger things when it comes to making a website unintelligible. @@ -195,4 +195,4 @@ SFC: Pushing back on the idea that all of these websites should have these toggl HJS: I think it would be useful to document the numbering system use case for people who only use one numbering system, in order to understand it better. Specifically, how does it correlate with the language of the page. Is it context-sensitive which digits should be used, and in general we should document which of these are general-purpose and which are dependent on contexts. For temperature it seems to me that it is not contextual – as long as the site says it’s C or F, it’s not ambiguous what it is. Earlier I gave the example of month abbreviations being context-dependent. Some of these are attached to a language – if we decide that it’s a use case that someone would prefer traditional Spanish collation, that doesn’t mean that they want traditional Finnish collation, or traditional Bangla collation. I don’t know if numbering system is something you want to see in the context of the language you’re reading, or if it’s ambiguous. If there’s no way to see whether or not the site is using your preferences, it would be useful to go through these categories and figure out which ones are not context-sensitive / always unambiguous, like temperature, which ones attach to a language, like traditional collation, and which ones are confusing if you read multiple languages and it’s actually less helpful if there’s a mismatch between the language you’re reading and the formatting. -YSZ: I’d like to mention I’m not disagreeing with the thought that user preferences significantly improve the experience, but what we’re seeing is that this does damage to privacy, which is why we’d like to care about these things very carefully. We see that both privacy and i18n are super appropriate. +YSZ: I’d like to mention I’m not disagreeing with the thought that user preferences significantly improve the experience, but what we’re seeing is that this does damage to privacy, which is why we’d like to care about these things very carefully. We see that both privacy and i18n are super appropriate. diff --git a/meetings/notes-2023-04-06.md b/meetings/notes-2023-04-06.md index 2b245c48..3beaccc8 100644 --- a/meetings/notes-2023-04-06.md +++ b/meetings/notes-2023-04-06.md @@ -19,7 +19,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -28,7 +28,7 @@ ### Editor's Update -USA: (shows issue tracker for 402.) #753, essentially incorporating NumberFormatV2 into 402, hoping to merge this in today / today-ish. #758 is rather important: I half-accidentally presented this to plenary without getting it through this group. +USA: (shows issue tracker for 402.) #753, essentially incorporating NumberFormatV2 into 402, hoping to merge this in today / today-ish. #758 is rather important: I half-accidentally presented this to plenary without getting it through this group. SFC: Normative changes are on the agenda, but I’d like to get normative changes later in the agenda. @@ -56,17 +56,17 @@ EAO: Resolved choice of selector, if multiple selectors what to do, we’ve had https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -SFC: Any other questions re: MessageFormat Working Group? Let’s take a quick look at PR tracking spreadsheet. Still some red crosses on normative PRs, lot of green checks, though. Is nothing missing? +SFC: Any other questions re: MessageFormat Working Group? Let’s take a quick look at PR tracking spreadsheet. Still some red crosses on normative PRs, lot of green checks, though. Is nothing missing? FYT: Question: Wanted to double-check status of spec. Have (several issues) been merged? -SFC: #758 needs to be added to the spreadsheet. +SFC: #758 needs to be added to the spreadsheet. FYT: Enumeration hasn’t merged? -SFC: Need to discuss normative change that RGN brought up. +SFC: Need to discuss normative change that RGN brought up. -YSZ: JSC will be first implementation of proposal. Thank you for proposing this – it’s a huge improvement. +YSZ: JSC will be first implementation of proposal. Thank you for proposing this – it’s a huge improvement. ## Pull Requests @@ -74,7 +74,7 @@ YSZ: JSC will be first implementation of proposal. Thank you for proposing this https://github.com/tc39/ecma402/pull/753#discussion_r1157703687 -SFC: 1st, change that RGN suggested on NFv3. Section of spec in question is regarding resolvedOptions. The way this work is we read from Table 1 for everything but rounding type, because rounding priority needs to be calculated later. +SFC: 1st, change that RGN suggested on NFv3. Section of spec in question is regarding resolvedOptions. The way this work is we read from Table 1 for everything but rounding type, because rounding priority needs to be calculated later. RGN: Proposed change: store it in a slot, read it from the table. @@ -82,7 +82,7 @@ SFC: There are cases where if the rounding priority isn’t specified, compact n RGN: No, I’m saying introduce a new slot, `[[RoundingPriority]]`, which only the table in resolvedOption would use. Take these special steps and move them into initialization. -FYT: I feel this should be approached post-ship in NFv4. What RGN suggests may work, but because of the deadline and consensus is stage 4, whatever you suggest has a risk of exposing some additional bug that under the pressure of the schedule may cause problems. Suggestion: merge as-is and look at this carefully post-merge. +FYT: I feel this should be approached post-ship in NFv4. What RGN suggests may work, but because of the deadline and consensus is stage 4, whatever you suggest has a risk of exposing some additional bug that under the pressure of the schedule may cause problems. Suggestion: merge as-is and look at this carefully post-merge. RGN: Let me clarify: I don’t like it, but I can live with it. I approved the PR. @@ -112,15 +112,15 @@ SFC: Would like to go back to the ask: I think this discussion is not something USA: Couple of points: 1st, I do agree with RGN that this is awkward. It would be slightly nicer, at least, to have all the related options together. Easier to read, easier to process. But, this is not the most common way to access resolvedOptions, the more common is for people to either destructure some properties or to do object access, situations where order doesn’t come into play. Third, the fact that this is a stage 4 proposal then irrespectively we’ll have to go through the same process pre-merge or post-merge, even though it’s not part of the spec yet. If we merge as-is, then I’d be very much in support of this normative change. -SFC: Concrete request: land the PR and then follow up very shortly after with another PR. RGN, if you make that PR by the end of the call, we could even discuss it in this call. +SFC: Concrete request: land the PR and then follow up very shortly after with another PR. RGN, if you make that PR by the end of the call, we could even discuss it in this call. -RGN: Minor issue, PR has my approval. +RGN: Minor issue, PR has my approval. -SFC: Let’s push the merge button. +SFC: Let’s push the merge button. USA: We should squash first… -SFC: I’ll let editors do the editor job. +SFC: I’ll let editors do the editor job. #### Conclusion @@ -134,21 +134,21 @@ SFC: #709, we previously discussed this in October. Conclusion in October was we FYT: only day and time-related options. -SFC: Let’s bring this back up for discussion and see if we can reach consensus. +SFC: Let’s bring this back up for discussion and see if we can reach consensus. RGN: Should be good for us, but it has not been raised to TG1. -USA: I wanted that to be the case, went through all the presentations I’ve given in the last year or so. Seems that for better or for worse it hasn’t been presented to TG1 in recent pass. I think the best thing would be to present it at next plenary. +USA: I wanted that to be the case, went through all the presentations I’ve given in the last year or so. Seems that for better or for worse it hasn’t been presented to TG1 in recent pass. I think the best thing would be to present it at next plenary. FYT: Years ago we had an issue with the test and had to read it twice. In support of changing it, implemented in V8, I support the proposal but I oppose including it in ES 2023. To agree on that we need to go to plenary, and in the meantime I’ll update V8 to do thi, we don’t have time for ES23. -USA: Seconding what FYT said. We’ve only really unconditionally approved it as TG2 today, technically this was blocked already from being approved by TG1. +USA: Seconding what FYT said. We’ve only really unconditionally approved it as TG2 today, technically this was blocked already from being approved by TG1. -SFC: It was an oversight – it could have been included in either January or March. +SFC: It was an oversight – it could have been included in either January or March. FYT: I don’t think the PR was ready by that time. -RGN: I think it was just ready for March, but we didn’t get it on the agenda. Definitely not ready for January. +RGN: I think it was just ready for March, but we didn’t get it on the agenda. Definitely not ready for January. Do we have TG2 “consensus”, where consensus is in quotes. Do we have the agreement of everyone in call that we want to send this to TG1 with TG2’s understanding that this is a good change? @@ -164,13 +164,13 @@ YSZ: +1 #### Conclusion -TG2 agreement. +TG2 agreement. ### Normative: Change the hourCycle default logic #758 https://github.com/tc39/ecma402/pull/758 -FYT: Issue we’ve had for a long time: we have h11, h12, h23, h24, but no one’s using h24. Our algorithm is weird/behavior is weird, I propose we change it. Handling by adding two internal slot for localeData to remember the preference, and based on that derive the default hourCycle on whether h12 is turned off, doesn’t change when h12 is absent, only when it’s true/false. Data-driven, rather than decided by logic inside ECMA-402. US is h11, in Europe, mostly h23, in Japan h12. No one really using h24. +FYT: Issue we’ve had for a long time: we have h11, h12, h23, h24, but no one’s using h24. Our algorithm is weird/behavior is weird, I propose we change it. Handling by adding two internal slot for localeData to remember the preference, and based on that derive the default hourCycle on whether h12 is turned off, doesn’t change when h12 is absent, only when it’s true/false. Data-driven, rather than decided by logic inside ECMA-402. US is h11, in Europe, mostly h23, in Japan h12. No one really using h24. SFC: I think that Frank’s most recent proposal gives the most flexibility, because data-driven. The current spec is too algorithmic, in that it tries to match the hourCycle – doesn’t make sense to say “if h23, prefer h11.” New algorithm is much better. Good from my perspective. @@ -204,7 +204,7 @@ FYT: I thought test262 was only accepting tests against merged-in rather than PR RGN: Sequence: normative PR is opened, test262 PR is opened, normative merges, test262 merges. -FYT: Ah, that makes sense. As long as people agree, I can work on adding tests. +FYT: Ah, that makes sense. As long as people agree, I can work on adding tests. RGN: You have agreement. @@ -214,7 +214,7 @@ RGN: Feel free to reach out to matrix channel for test262. I18n ones are always FYT: Action item: add test. Consensus that we’ll present at TG1 in May? -SFC: I think for both of these. +SFC: I think for both of these. #### Conclusion @@ -228,17 +228,17 @@ https://github.com/FrankYFTang/intl-zoneddatetimeformat SFC: I sent out an email with a large list of topics. We already did #753. We have several DurationFormat things to discuss, take break, then after break see what time we have for other things. Agenda sound good? -JGT: I need to leave early today, could we talk about ZonedDateTime first? +JGT: I need to leave early today, could we talk about ZonedDateTime first? SFC: With a timebox of 15 minute -FYT: I have a stage 0 proposal that I’d like to go to stage 1 in May. The basic idea is that three weeks, four weeks ago we had discussion in the Temporal working group that concluded that it’s way too hard to pass in the ZonedDateTime because of conflict with time zone. Conclusion: ZonedDateTime will work in Temporal, but DTF is not going to take ZonedDateTime from Temporal, which I believe is the right thing to do because it’s way too complicated to make DTF into ZDT, because it has additional info that Date never has (time zone). This means we have two issues: is there no way you can have an object and use it consistently to format a ZDT? Second thing: no way to format a range or parts of ZDT. No object, no range, no part. Therefore, the stage 0 proposal is to add a new Intl object very similar to DTF which can only handle formatting ZDT. Stage 1 proposal, so we don’t need a lot of detail. What the spec text does is similar to DTF. Into ZonedDateTimeFormat constructor, pass in options. Lot of detail not filled in, similar to DateTimeFormat object, doesn’t take time zone. Cannot return a time zone. +FYT: I have a stage 0 proposal that I’d like to go to stage 1 in May. The basic idea is that three weeks, four weeks ago we had discussion in the Temporal working group that concluded that it’s way too hard to pass in the ZonedDateTime because of conflict with time zone. Conclusion: ZonedDateTime will work in Temporal, but DTF is not going to take ZonedDateTime from Temporal, which I believe is the right thing to do because it’s way too complicated to make DTF into ZDT, because it has additional info that Date never has (time zone). This means we have two issues: is there no way you can have an object and use it consistently to format a ZDT? Second thing: no way to format a range or parts of ZDT. No object, no range, no part. Therefore, the stage 0 proposal is to add a new Intl object very similar to DTF which can only handle formatting ZDT. Stage 1 proposal, so we don’t need a lot of detail. What the spec text does is similar to DTF. Into ZonedDateTimeFormat constructor, pass in options. Lot of detail not filled in, similar to DateTimeFormat object, doesn’t take time zone. Cannot return a time zone. Look at properties of ZDT, you have something similar to Temporal, because you have a ZDT you can create a DTF. DTF is different from ZDT in that it internally has ZDT, similar to Temporal you can create an object by passing a tz in, because of that we also add additional function to DTF to have toZDT, this one creates the new object from what’s in it but without a tz. Either try to make it very close to Temporal framework, but in order to advance to stage 1 those details don’t need to be discussed, the key thing is whether to have a new object. The scope still needs to be discussed. SFC: Thanks for putting this proposal together. I think for the purposes of stage 1 this is a worthy problem space to explore. How do we have a configurable object to format ZDT that come from Temporal. I won’t give an opinion on the shape of the proposal, will let others speak first. -EAO: Much the same as Shane I think this is an entirely valid problem space to find a solution in, not convinced that Int.ZonedDateTimeFormatter is the right solution, but we should find a solution. +EAO: Much the same as Shane I think this is an entirely valid problem space to find a solution in, not convinced that Int.ZonedDateTimeFormatter is the right solution, but we should find a solution. USA: I wanted to comment about the shape of the proposal. Before I reduced actively working on spec side of Temporal I remember working through some of this design for DTF, most of it predates the existence of ZDT to begin with. Even then it was a complex problem space, to take an object that has been designed keeping in mind Date and all the trappings of it, and extending it to all of the differently shaped Temporal objects. We did our best to make sure it worked, but I agree that the introduction of an attached tz with it complicates thing to the extent that it’s probably better to design something from scratch. The DTF to ZDT formatter is a new concept, I’m not against the idea in principle, but we don’t necessarily have to do it. For example: just do .resolvedOptions() and throwing that into the new constructor. If we do this, we have to make sure we do it well. @@ -248,11 +248,11 @@ USA: There is precedent in Temporal but not Intl for converting one formatter to SFC: Weighing in on design direction: one thig that’s a little weird is the naming, because ZDTF doesn’t actually have a time zone. It formats, but no time zone. DTF is the opposite. In terms of having separate objects, one regret I have with Temporal is that we didn’t have a thorough discussion of the whole mosaic of exactly how we make formatters for Temporal objects. We had a discussion with a small group of Temporal champions where we made the proposal, but didn’t have a full discussion with this group. This got to stage 3 without thorough review from TG2 people, which is one regret I have. One option was have separate formatters for each Temporal type. We have a special formatter for one Temporal type but not others. This is an acceptable end-state, but we should discuss this more thoroughly. Since already shipped in some browsers, not sure there’s room to take a bigger-picture look on this, PlainMonthDay, and other things – do we need an Intl.PlainFormat? Maybe FYT has ideas at stage 1 to address that side of the picture. Good for stage 1, though. -USA: Everything that SFC said, +1. Commented in pass that the 402 part of Temporal was bigger than median 402 proposal, oversight that we didn’t have. Something I thought: everything can be done with DTF except for ZDT because it has the problem in that it includes a time zone, which the formatter does as well. Clarifying question for FYT: does this problem not exist for calendars? +USA: Everything that SFC said, +1. Commented in pass that the 402 part of Temporal was bigger than median 402 proposal, oversight that we didn’t have. Something I thought: everything can be done with DTF except for ZDT because it has the problem in that it includes a time zone, which the formatter does as well. Clarifying question for FYT: does this problem not exist for calendars? -FYT: It is a problem. I prefer we take everything everything out of Temporal, out of DTF, but that’s already stage 3, Temporal went to stage 3 too early. Don’t have a strong reason to go to Temporal to say “get those things out of DTF.” +FYT: It is a problem. I prefer we take everything everything out of Temporal, out of DTF, but that’s already stage 3, Temporal went to stage 3 too early. Don’t have a strong reason to go to Temporal to say “get those things out of DTF.” -USA: If we’re going to do a second DateTimeFormatter, why not do a second formatter that works for all Temporal objects instead? A new DTF (different name of course) that works on all Temporal objects, we can do away with old API choices. Big ergonomic cost to having separate formatter. +USA: If we’re going to do a second DateTimeFormatter, why not do a second formatter that works for all Temporal objects instead? A new DTF (different name of course) that works on all Temporal objects, we can do away with old API choices. Big ergonomic cost to having separate formatter. FYT: Yes, but I don’t want to go to Temporal and start a fight about that. @@ -264,19 +264,19 @@ SFC: Regarding calendars vs time zones, this was thoroughly discussed among Temp SFC: I would be open to someone opening a PR to do what we did with ZDT to the other objects: don't allow them as arguments to DTF.prototype.format, but still allow toLocaleString. Remove things and add them later. If everything starts with .toLocaleString at least they’re formattable day-1. Not saying anything binding, but postulating that if someone wants to make a PR it would be something worth discussing, since it’s purely subtractive. -USA: I would not consider it totally subtractive in that we’re breaking, to some extent, the Temporal proposal into the formatters part and the data model / arithmetic. +USA: I would not consider it totally subtractive in that we’re breaking, to some extent, the Temporal proposal into the formatters part and the data model / arithmetic. FYT: It’s subtractive because we can accept some Temporal objects, we’re now saying we won’t accept them in stage 3 spec. I’d love for it to happen, but. -USA: I can volunteer to assist with doing the work of talking with everyone. +USA: I can volunteer to assist with doing the work of talking with everyone. SFC: Separate discussion than proposal, we’re at end of timebox. -JGT: I think it’s a good discussion to have, my original opinion is still the same (using DTF for everything isn’t bad). I wouldn’t necessarily throw the baby out of the bathwater for that kind of simple solution. Good to discuss, lots of interesting options. +JGT: I think it’s a good discussion to have, my original opinion is still the same (using DTF for everything isn’t bad). I wouldn’t necessarily throw the baby out of the bathwater for that kind of simple solution. Good to discuss, lots of interesting options. -YSZ: +1 +YSZ: +1 -SFC: +1, I’ve seen some other +1s. +SFC: +1, I’ve seen some other +1s. #### Conclusion @@ -286,7 +286,7 @@ Stage 1 approval from TG2 https://github.com/tc39/proposal-intl-duration-format/issues/139 -USA: First, #139. FYT opened this issue recently. The problem is that digital is an outlier in everything. There were a number of previous designs that hit this flaw and couldn’t handle it. FYT has noted that for sub-second units, in the digital style the display is controlled by fractionalDigits. The amount of information displayed /granularity of output is controlled by fractionalDigits. There are other options that (microsecondDisplay, millisecondDisplay) that control whether it’s always displayed or only when not 0. As it turns out, these don’t go well together. As fractionalDigits needs to exist for the three units, for the style these options that already exist because of making sense for other underlying styles don’t make sense. The simplest solution is to not accept explicitly setting these options. +USA: First, #139. FYT opened this issue recently. The problem is that digital is an outlier in everything. There were a number of previous designs that hit this flaw and couldn’t handle it. FYT has noted that for sub-second units, in the digital style the display is controlled by fractionalDigits. The amount of information displayed /granularity of output is controlled by fractionalDigits. There are other options that (microsecondDisplay, millisecondDisplay) that control whether it’s always displayed or only when not 0. As it turns out, these don’t go well together. As fractionalDigits needs to exist for the three units, for the style these options that already exist because of making sense for other underlying styles don’t make sense. The simplest solution is to not accept explicitly setting these options. FYT: I don’t think that’s the right way to phrase it. It is only a problem if it is "always". "auto" is not a problem. There's no conflict if it is "auto". @@ -294,7 +294,7 @@ USA: Not a problem if it doesn’t say anything. FYT: If you say “auto” and fractionalDigits, it won’t be a problem. When set to “always”, it’s conflicting. -USA: Setting “auto” doesn’t do anything either, but not unexpected what the final output. Setting one of these three to “always” when style is digital is problematic, precisely why fractionalDigits exists, proposal is to disallow this set of options. So basically if you set millli, micro, or nano to “always”, it will throw a RangeError. Change that produces least user confusion, rather than failing silently. +USA: Setting “auto” doesn’t do anything either, but not unexpected what the final output. Setting one of these three to “always” when style is digital is problematic, precisely why fractionalDigits exists, proposal is to disallow this set of options. So basically if you set millli, micro, or nano to “always”, it will throw a RangeError. Change that produces least user confusion, rather than failing silently. SFC: Clarifying: the ill-defined condition is when there’s a field whose style is numeric and a parent in the fractional part. Numeric used in seconds and above, totally valid to have display “always”, only ill-defined in fractional part. @@ -302,29 +302,29 @@ USA: By default set to “always” in seconds, minutes, hour. FYT: Repeat again? -USA: That has nothing to do with sub-second units. +USA: That has nothing to do with sub-second units. FYT: The issue is that’s why it’s not set to default. USA: If style is undefined and base time is digital, displayDefault is set to “auto”. Otherwise… -SFC: There’s a separate issue that FYT has a PR open on, that this section of the spec is very confusing. +SFC: There’s a separate issue that FYT has a PR open on, that this section of the spec is very confusing. -FYT: I find this issue when we try to look at output when style is digital, but really it’s about whether that particular field is numeric or not. +FYT: I find this issue when we try to look at output when style is digital, but really it’s about whether that particular field is numeric or not. USA: That is still the fraction. When you’re displaying the subseconds as a fraction is when you get this issue. FYT: As long as in that 3 field, they are set to "always", we have this problem. style: "digital" is one way to lead to this, but it is not the only way. -USA: To clarify, for milliseconds, microseconds, nanoseconds, if any of them both have the style as numeric and the display as always, we should throw. +USA: To clarify, for milliseconds, microseconds, nanoseconds, if any of them both have the style as numeric and the display as always, we should throw. SFC: Is there a reviewable PR for this? What we should ask the group right now is do we like the PR? Can we get agreement in TG2? -USA: This is GetDurationUnitOptions, where we pass in the units and we do the final resolving of them. Before they’re resolved, if the resolved options were style: “numeric” and display “always” and the unit is sub-seconds, we should throw. +USA: This is GetDurationUnitOptions, where we pass in the units and we do the final resolving of them. Before they’re resolved, if the resolved options were style: “numeric” and display “always” and the unit is sub-seconds, we should throw. SFC: Want to get feedback, especially from YSZ as first implementor for all DurationFormat proposals today. -YSZ: I’d like to compare the implementation and other things, explore and construct my feedback. +YSZ: I’d like to compare the implementation and other things, explore and construct my feedback. SFC: Any other feedback on whether this change is good from an ergonomics POV? Explicit voices of support for this proposal? I’m personally okay with it – I think it’s a positive change overall. Given that the proposal is stage 3, any change we make needs to make a high bar. Not sure if this change meets that bar, but it’s a pretty harmless one. I defer to YSZ on this as someone who’s actually implemented it. On the edge w/r/t whether this is justifiable as stage 3. @@ -340,7 +340,7 @@ YSZ: I think it makes sense, and I support this change. +1. FYT: Not trying to influence people: let me explain why I proposed PR. If we do not do this, the consequence is that the user will scratch their heads about what the formatting means – if we don’t throw, we go into this mode that would always display nanosecond and always not display nanosecond. -SFC: Justified – corner case, but justifiable one that has a papercut for ergonomics/usability of the API. I think that’s 5 +1s, which seems to be TG2 agreement. +SFC: Justified – corner case, but justifiable one that has a papercut for ergonomics/usability of the API. I think that’s 5 +1s, which seems to be TG2 agreement. USA: We have time before next plenary to discuss async. @@ -368,9 +368,9 @@ USA: Current output is 0:00:01 USA: To add context to the problem, DF as designed has one option for controlling fractions. Originally default was undefined. Effect was that when fed into the NumberFormat this would pass in undefined as both minimum and maximum fractional digits. So it did work, but we uncovered that and changed the default value to 0 without realizing that this would be a side effect. This is what Anba talks about in other issue: we should change the output. One way to deal with that is to split fractionalDigits into minimum and maximum to get more clarity. -SFC: I want to establish the problem side before discussing the solution part. Don’t want to get held up in solution before we establish there’s a problem. +SFC: I want to establish the problem side before discussing the solution part. Don’t want to get held up in solution before we establish there’s a problem. -FYT: We should also consider the condition that if you have the exact same thing, but then you have not millisecond but microsecond 230. +FYT: We should also consider the condition that if you have the exact same thing, but then you have not millisecond but microsecond 230. SFC: Output will be correct, but with additional 0s on fractional part. Output would be 0:00:01.0023. @@ -382,9 +382,9 @@ FYT: Should not be more than 3 digits? SFC: Correct. Exact integer arithmetic going on here. -FYT: I support it – it doesn’t make sense to have 0:00:01. It’s an issue we need to solve. +FYT: I support it – it doesn’t make sense to have 0:00:01. It’s an issue we need to solve. -SFC: Anyone else want to voice support/opposition to this being a problem we need to solve. If so, we have two potential solutions, one smaller, one larger. +SFC: Anyone else want to voice support/opposition to this being a problem we need to solve. If so, we have two potential solutions, one smaller, one larger. SFC: Let’s look at the proposed solutions, then. One is don’t change anything, but if there’s a problem we need to change something and it will be normative. Option 2, all we do is change default maximumFractionDigits to 9, but it behaves the same way if maximumFractionDigits specified. Since it’s stage 3 I’m loathe to make big changes – this is a small change that can be made with a scalpel. Larger change is #3, currently we have fractionalDigits in options bag for Intl.DurationFormats. Remove option bag and add setters as in Intl.NumberFormat. A little more user flexibility on how numbers are displayed, the downside is that it’s stage 3. The other reason we have fractionalDigits as the name is that it’s more consistent with toString() on Temporal. It may be the case that we decide that fractionalDigits is something we want and it’s stage 3, so we go with option 2 instead of option 3. I’m not going to advocate for option 3, but if the group prefers it we should go with it. @@ -396,7 +396,7 @@ USA: fractionalDigits FYT: Current option only return fractionalDigits to 0. In option 2, what happens? -SFC: Rephrasing what USA said: If we went with 2 or 3, resolvedOptions would still have fractionalDigits set to 0, which is just wrong. Option 4 is a good approach – we try our best to maintain the invariant that resolvedOptions can create an object with the same behavior. If fractionalDigits is undefined we get min 0 max 9, if defined we set min and max to that value. +SFC: Rephrasing what USA said: If we went with 2 or 3, resolvedOptions would still have fractionalDigits set to 0, which is just wrong. Option 4 is a good approach – we try our best to maintain the invariant that resolvedOptions can create an object with the same behavior. If fractionalDigits is undefined we get min 0 max 9, if defined we set min and max to that value. USA: Basically my concern is that 2, we are resolving fractionalDigits but essentially what fractionalDigits represents is minimumFractionDigits. maximumFractionDigits resolved from 9, but you can’t see it in options. @@ -422,21 +422,21 @@ USA: Let’s change undefined to auto, that’s maybe option 5. We include a str FYT: User cannot know minimum or maximum? -USA: Yes, because they didn’t set anything. It’s just whatever’s necessary to display the entire information. It is quite valid, since as SFC pointed out that’s the behavior in general of DurationFormat – it shows you all the info it can, and goes to great length to avoid hiding information unless that info is at the end in fractional seconds. It’s the same here, except if you don’t set anything. +USA: Yes, because they didn’t set anything. It’s just whatever’s necessary to display the entire information. It is quite valid, since as SFC pointed out that’s the behavior in general of DurationFormat – it shows you all the info it can, and goes to great length to avoid hiding information unless that info is at the end in fractional seconds. It’s the same here, except if you don’t set anything. -SFC: Interrupt: we still have more DurationFormat issues to discuss. Resolve: did we agree that it’s a problem, and if we do agree, can we express a preference between 4 and 5? I would like to go with 4 because I want to solve this with a scalpel, not a hammer. Easy to implement – thinking of YSZ here, because I don’t want to make a big disruption to implementations. Option 4 is a concrete way to move forward. +SFC: Interrupt: we still have more DurationFormat issues to discuss. Resolve: did we agree that it’s a problem, and if we do agree, can we express a preference between 4 and 5? I would like to go with 4 because I want to solve this with a scalpel, not a hammer. Easy to implement – thinking of YSZ here, because I don’t want to make a big disruption to implementations. Option 4 is a concrete way to move forward. EAO: 4 is fine. -USA: Can I add? I’m not sure exactly which version YSZ has implemented, but from this comment it’s clear that 4 is the more convenient option because it was the status quo until recently. +USA: Can I add? I’m not sure exactly which version YSZ has implemented, but from this comment it’s clear that 4 is the more convenient option because it was the status quo until recently. SFC: Clarification: earlier version had undefined which inherited min/max of 3 from NF. min/max of 9 is what we need – slightly different from old version of proposal. Better version of old version of proposal. YSZ: temperature check? YSZ: I’m looking into the implementation: I’ll comment once I find something. I think that it makes sense (option 4), but I’ll need some time. -SFC: Pending YSZ and FYT feedback, +SFC: Pending YSZ and FYT feedback, -FYT: I’m positive for 4, but will need to look at proposed PR carefully. I think the chance there will be problems is small. I support it, but would like to see PR. +FYT: I’m positive for 4, but will need to look at proposed PR carefully. I think the chance there will be problems is small. I support it, but would like to see PR. SFC: Good conclusion: group is generally positive toward 4, but we should see a PR before formal agreement. We have one more meeting before next TG1. @@ -458,23 +458,23 @@ USA: It’s a duplicate. FYT: We don’t need to discuss this, right? -USA: If we solve the other issue, it’s solved. +USA: If we solve the other issue, it’s solved. -SFC: PR #146 is the last one we need to discuss. +SFC: PR #146 is the last one we need to discuss. ### Normative: Set rounding mode to "trunc" #146 https://github.com/tc39/proposal-intl-duration-format/pull/146 -USA: This is another kind of problem in the same vein, when talking about roundingMode of NumberFormat. When we’re creating a NumberFormat for the fraction, we should always truncate, but this is not explicitly set. This is a bug or oversight in the same vein. I support it. +USA: This is another kind of problem in the same vein, when talking about roundingMode of NumberFormat. When we’re creating a NumberFormat for the fraction, we should always truncate, but this is not explicitly set. This is a bug or oversight in the same vein. I support it. -SFC: Another normative change that may impact YSZ’s implementation, but it’s a small change. +SFC: Another normative change that may impact YSZ’s implementation, but it’s a small change. YSZ: LGTM. SFC: Additional feed back from someone like EAO? -EAO: No real opinion on this one. +EAO: No real opinion on this one. SFC: Issue here is that if you have a duration like 1 second and 550 milliseconds, but you have fractionDigits = 0, should we round to 1 second or 2 seconds? I would say normally when dealing with time we truncate. This might be something that JGT might have an opinion in? @@ -488,7 +488,7 @@ JGT: Not rounding up is appropriate for time units. You don’t get to say “10 FYT: The big problem is 1 second 999 ms. If you round it won’t be 2 seconds, it’ll be 1. -USA: Correct. If fractionalDigits is set in a way such that the actual value isn’t included, we might accidentally round up. +USA: Correct. If fractionalDigits is set in a way such that the actual value isn’t included, we might accidentally round up. SFC: 59 sec 999 ms – we’ve consistently avoided in NF rounding that up. The case that RGN brought up is stronger. @@ -506,9 +506,9 @@ SFC +1 from JGT, SFC, USA, FYT – agreement on this one? FYT: #145? -SFC: That’s a duplicate. +SFC: That’s a duplicate. -FYT: Anything that landed we need consensus to go to TG1? +FYT: Anything that landed we need consensus to go to TG1? USA: Before TG1 we should get consensus on all these things. As Shane pointed out, this table cleanup is editorial, has two competing PRs, same for partitionDurationFormatToParts. @@ -526,11 +526,11 @@ SFC: I see what you mean, but it still seems like a typo in the spec. USA: Behavior was still the same, some parts have units, some don’t. -SFC: We don’t have time for slides, will present next time, would appreciate people review those slides, will include them in summary email, you can give comments in the slide deck. Out of time but will leave meeting open if FYT/USA/ others want to talk about editorial issues. +SFC: We don’t have time for slides, will present next time, would appreciate people review those slides, will include them in summary email, you can give comments in the slide deck. Out of time but will leave meeting open if FYT/USA/ others want to talk about editorial issues. -FYT: I want to make sure that anything we have merged into spec but don’t have clear consensus in TG1 or here so that we can present in May to have official consensus. +FYT: I want to make sure that anything we have merged into spec but don’t have clear consensus in TG1 or here so that we can present in May to have official consensus. -SFC: Hopefully we haven’t merged in anything normative that we don’t have consensus in. USA/BAN, can we review these to make sure we have them right from a process POV? +SFC: Hopefully we haven’t merged in anything normative that we don’t have consensus in. USA/BAN, can we review these to make sure we have them right from a process POV? #### Conclusion diff --git a/meetings/notes-2023-05-04.md b/meetings/notes-2023-05-04.md index 759f4988..383feb20 100644 --- a/meetings/notes-2023-05-04.md +++ b/meetings/notes-2023-05-04.md @@ -15,7 +15,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -67,9 +67,9 @@ RGN: Yes SFC: This is something that could have been in the NumberFormat v3 proposal itself, we decided to hold it until we merged the PR. This is a very new section of 402, so I think that it’s appropriate to make this change, and to make it sooner rather than later. This is a very small bugfix from the v3 proposal, I support both the editorial and normative parts. -FYT: I’m okay with this, but we should list all the past test262 tests will be impacted. +FYT: I’m okay with this, but we should list all the past test262 tests will be impacted. -SFC: We can record that we have agreement from the group that we want to ask TG1 for consensus on this PR. +SFC: We can record that we have agreement from the group that we want to ask TG1 for consensus on this PR. FYT: Suggestion for title: we should say “swap” instead of “reorder”, since we’re really just swapping two things. @@ -83,13 +83,13 @@ FYT: It’s not a big deal, I just thought looking at the tag might make it seem JGT: Quick reminder and overview of the time zone canonicalization issue, particularly with regard to three open issues. One of the things I’m planning to do if this meeting goes well is to ask for Stage 2 in upcoming TG1 meeting, and will talk about what exactly the changes in the spec would involve. Summary and reminder - Problems we’re solving: implementations diverge. For example, Europe/Kiev in Chrome, Safari vs. Europe/Kyiv in Firefox. When canonical IDs change, you could have existing code that breaks. For example, automated tests that expect Europe/Kiev in output. In 2022 that test in firefox would work, in 2023 that test would break. Tests should be resilient, but knowing the real world, it’s an issue. If we don’t change, users complain about us showing obsolete names for where they live. Final problem, which is an umbrella problem, is that using === to compare time zone identifiers is a bad idea. One of the goals is to encourage developers to not use === to compare time zone identifiers. Temporal makes this worse, since IDs are going to show up everywhere you serialize a ZoneDateTime. My guess is that it will be one to two more orders of magnitude more discoverable to developers. + Problems we’re solving: implementations diverge. For example, Europe/Kiev in Chrome, Safari vs. Europe/Kyiv in Firefox. When canonical IDs change, you could have existing code that breaks. For example, automated tests that expect Europe/Kiev in output. In 2022 that test in firefox would work, in 2023 that test would break. Tests should be resilient, but knowing the real world, it’s an issue. If we don’t change, users complain about us showing obsolete names for where they live. Final problem, which is an umbrella problem, is that using === to compare time zone identifiers is a bad idea. One of the goals is to encourage developers to not use === to compare time zone identifiers. Temporal makes this worse, since IDs are going to show up everywhere you serialize a ZoneDateTime. My guess is that it will be one to two more orders of magnitude more discoverable to developers. -Proposed solutions: +Proposed solutions: - Clarify for implementors how TZDB work. If we can get that data out of CLDR, we can still expose the same set of canonical IDs. The next Kyiv that gets renamed, developers will have a sense of what to do - Reduce observable impact: - - Stop returning canonical IDs whenever we can. If users provide non-canonical IDs, give that non-canonical ID back. + - Stop returning canonical IDs whenever we can. If users provide non-canonical IDs, give that non-canonical ID back. - If we were to do the first part, how can developers know that time zones are equivalent (kiev and kyiv the same). Add new Temporal.TimeZone.p.equals to compare IDs, replacing === How do time zone IDs get into ECMAScript? @@ -102,36 +102,36 @@ I’ve split it into four cases, the first ones being user input split into two. Second case: you can add your own time zone and get it back from .resolvedOptions(), I believe this is more rare than not specifying a time zone and wanting to know what the time zone is. We’ll have a discussion slide about this. -Similarly, is forgetting the system time zone. Third, if you have an enumeration of a time zone list, choose the one that’s canonical. +Similarly, is forgetting the system time zone. Third, if you have an enumeration of a time zone list, choose the one that’s canonical. First discussion item: Should we canonicalize resolvedOptions().timeZone? Bunch of reasons for, bunch against. -Reasons for: +Reasons for: -Retains backwards compatibility. There’s an asterisk, since we don’t have current compatibility – if I ran the same code in Firefox vs. Chrome, I’d get a different result. Compatibility is less of a concern now, because we don’t have it now. +Retains backwards compatibility. There’s an asterisk, since we don’t have current compatibility – if I ran the same code in Firefox vs. Chrome, I’d get a different result. Compatibility is less of a concern now, because we don’t have it now. Provides appropriately non-discoverable canonicalization API. We don’t want to make it easy for people to get to the canonicalized ID because of dependency it introduces. -Reasons not: +Reasons not: Same reasons as in Temporal. Ensures code behaves the same across engines Prevents browser/Node updates from changing how ES code behaves Doesn’t unexpectedly change user input or break automated tests. -Minimizes disruption if V8/JSC start using IANA’s canonical IDs (like FF) +Minimizes disruption if V8/JSC start using IANA’s canonical IDs (like FF) Respects user choices: e.g. Russian vs. Ukrainian developers. Reduces differences in parse/serialize round trips -Aligns with Temporal, though alignment with Temporal isn’t necessarily important since resolvedOptions() is about the time zone used to create localized test. +Aligns with Temporal, though alignment with Temporal isn’t necessarily important since resolvedOptions() is about the time zone used to create localized test. SFC: Clarifying question. There’s canonicalization and normalization (i.e. normalized case, make it the form in the IANA database), and when you say not canonicalize are you saying we should at least normalize? -JGT: Yes. It would be inefficient to store direct string input, normalize the case so you can store an index into the list of strings. +JGT: Yes. It would be inefficient to store direct string input, normalize the case so you can store an index into the list of strings. RGN: We should add an intro slide describing terms for the presentation, since canonicalize means different things in different contexts. SFC: One question I’d have to follow up is that IANA does add aliases and time zones regularly, so what’s the existing behavior and what’s the proposed behavior for when the user-provided time zone is not yet known by the engine. -RGN: There’s a discussion of that a little forward. When this happens you get an error: it breaks. This happened with Kyiv – if you have an updated server or updated client, the one that’s never heard of it would complain. On Android, they add the new entry as soon as possible, but don’t make it canonical for two years. +RGN: There’s a discussion of that a little forward. When this happens you get an error: it breaks. This happened with Kyiv – if you have an updated server or updated client, the one that’s never heard of it would complain. On Android, they add the new entry as soon as possible, but don’t make it canonical for two years. FYT: You list here why and why not, but I’m not quite (as RGN mentioned) sure I’m understanding about where the boundary line drawn here? Are we talking about why change time zone from user input, or are we saying we have to make it a canonicalized form following a specific spec. A consideration is runtime memory for the object. In our implementation we don’t remember the exact string the user puts in. On the system you only have one of the singleton. That means if you have 30 different Intl.DateTimeFormat, we only need one pointer for each. The memory cost of that per object will be helping to reduce the footprint with that process. The memory usage needs to be listed on the slide. @@ -143,7 +143,7 @@ RGN: No. If an implementation, dependent on how they want to prioritize their wo FYT: Reasonable, but should be mentioned that there will be an increase of 10 bits per object? -JGT: No. THere’s already a time zone slot, and the minimum memory requirement for that is 10 bits. The built-in time zone slots. +JGT: No. THere’s already a time zone slot, and the minimum memory requirement for that is 10 bits. The built-in time zone slots. RGN: So that’s an existing cost. @@ -155,13 +155,13 @@ JGT: Richard and I have gone back and forth on the right names, we don’t have EAO: The word “name” came to mind first, but I’m not attached to anything. Happy to file an issue. -JGT: One thing with “id” vs “name” is that we originally called them “name” but changed to “id” later on, because “name” might imply that they’re not computer-readable. “Code” could be another choice, but we didn’t want to imply that it’s a localized name that would change across locales, but instead that it’s an identifier that’s computer readable. +JGT: One thing with “id” vs “name” is that we originally called them “name” but changed to “id” later on, because “name” might imply that they’re not computer-readable. “Code” could be another choice, but we didn’t want to imply that it’s a localized name that would change across locales, but instead that it’s an identifier that’s computer readable. -RGN: There’s only a small degree to which change is possible. ID has been exposed to consumers of ECMA-402 for quite some time and cannot be reverted. Internally the language could be changed, but external interfaces are pretty much set. +RGN: There’s only a small degree to which change is possible. ID has been exposed to consumers of ECMA-402 for quite some time and cannot be reverted. Internally the language could be changed, but external interfaces are pretty much set. FYT: My undersatnding is that that means that if this proposal goes forward, you would need to mention how to case-normalize this thing. That will still be needed. -JGT: Correct. +JGT: Correct. FYT: Case-normalization is tricky @@ -171,15 +171,15 @@ JGT: Every implementation ships with a hard-coded list of 600 strings, and you d FYT: And that’s not canonicalization? -JGT: The term we’re using is case normalization. Any term is fine as long as we have a clear distinction between case-normalization and changing the actual words. +JGT: The term we’re using is case normalization. Any term is fine as long as we have a clear distinction between case-normalization and changing the actual words. RGN: But even things like Kiev/Kyiv don’t have a conversion algorithm: it’s just a case-normalized list defining the possible outputs. The spec at least will say that it’s a lookup table, and implementers are free to implement it however. JGT: So what are opinions on what to do? -FYT: Another question: my understanding is that in the past, about two years ago ZB proposed that anything going to stage 2 has to pass three tests, and for process reason I ask that your slides include those three criteria. +FYT: Another question: my understanding is that in the past, about two years ago ZB proposed that anything going to stage 2 has to pass three tests, and for process reason I ask that your slides include those three criteria. -SFC: I’ll pull those up, but this is not just a 402 proposal even though we’re discussing it in this body. I think this proposal likely satisfies these three. +SFC: I’ll pull those up, but this is not just a 402 proposal even though we’re discussing it in this body. I think this proposal likely satisfies these three. FYT: We should mention it. @@ -205,7 +205,7 @@ RGN: that is also ours. SFC: I’m convinced. I think this is the position we should take at stage 2 -FYT: I’m okay with that. Let me put it this way, though: I’m okay with this, but I have some doubts that the difference between case-normalization and true canonicalization is small. The advantage of saying “people aren’t going to use this for an API,” I think that part is not that strong. Unless you hit the cases where case-normalization and canonicalization, people will think it does canonicalization. +FYT: I’m okay with that. Let me put it this way, though: I’m okay with this, but I have some doubts that the difference between case-normalization and true canonicalization is small. The advantage of saying “people aren’t going to use this for an API,” I think that part is not that strong. Unless you hit the cases where case-normalization and canonicalization, people will think it does canonicalization. JGT: I think that today everything is canonicalized and it produces many complains from the affected countries. “Why are you calling it Calcutta instead of Kolkatta when the name changed a long time ago?” We have the ability to set user expectations, and this proposal the idea is to reset these expectations to something more in line of what Ukrainian, Indian, and Vietnamese developers expect. @@ -220,12 +220,12 @@ SFC: It sounds like we have agreement that this is a good direction, we’ll get JGT: Next issue: what should DefaultTimeZone return when OS time zone ID differs from ECMAScript canonical ID. THere are three cases today: 1. The OS adds a new canonical ID, but ECMAScript doesn’t recognize it. - 1. Kiev/Kyiv. If I’m in Ukraine and I have a local server, and I want to set it to Europe/Kyiv and then I run a node.js app that doesn’t know about it, that would result in an unknown time zone in ECMAScript. Rare in browsers, but it is a problem in server apps. + 1. Kiev/Kyiv. If I’m in Ukraine and I have a local server, and I want to set it to Europe/Kyiv and then I run a node.js app that doesn’t know about it, that would result in an unknown time zone in ECMAScript. Rare in browsers, but it is a problem in server apps. 1. Not sure there’s a great solution – Android solution, to very quickly add new aliases when they show up but not change the canonical ID for a while so that everyone can catch up seems like a reasonable approach. But if you’re still running node 12 and will be running it for a decade, there’s nothing we can do to make sure the new TZID is recognized. This is not a problem we solve, but it’s a problem to solve separately. 1. Case 2: OS has new canonical ID, but ECMAScript considers it non-canonical. 1. E.g. OS: Asia/Kolkata, ECMAScript: Asia/Calcutta 1. ECMAScript has new canonical ID, but un-updated OS still uses old one. - 1. Variation: sysadmins keep old OS ID for compatibility or political reasons (i.e. Russian and Ukrainian developers disagreeing on what the time zone should be called). + 1. Variation: sysadmins keep old OS ID for compatibility or political reasons (i.e. Russian and Ukrainian developers disagreeing on what the time zone should be called). Discussion: in cases 2 and 3, should DefaultTimeZone return OS ID or ECMAScript canonical ID. One more pro/con: there are some libraries on mobile devices where ECMAScript has the ability to call into native code, which in turn calls into the OS to get OS ID. Even in browser ECMAScript is self-contained, that’s not true in all ECMAScript environments, particularly in mobile devices or servers. This is one argument for not canonicalizing OS ID. @@ -240,9 +240,9 @@ JGT: We can’t solve case 1. If we don’t know what the ID is from the OS, we RGN: but “throw up your hands” is necessary to specify -JGT: I agree. The spec should describe what we do in case 1, even if we can’t solve it. +JGT: I agree. The spec should describe what we do in case 1, even if we can’t solve it. -RGN: Sets up constraints that are recognized to abide by. +RGN: Sets up constraints that are recognized to abide by. SFC: Question about case 2: I don’t understand case 2. Why would ECMAScript consider it non-canonical? What I’m thinking is that under what condition, assuming there is no version skew, under what condition would case 2 occur? @@ -250,9 +250,9 @@ JGT: In browsers everyone updates quickly, but if we were to change V8 and JSC t SFC: I think so. Let’s focus on case 3. ECMAScript makes the engine figure out what to do on each host. -JGT: Let me take back what I had to say about case 2. If we decide that changing the canonical ID as soon as IANA change it is problematic when ECMAScript programs are sending IDs that no one has seen, then the Android solution (add, but don’t canonicalize right away), that’s where we get case 2. Case 2 would be what happens in the middle. +JGT: Let me take back what I had to say about case 2. If we decide that changing the canonical ID as soon as IANA change it is problematic when ECMAScript programs are sending IDs that no one has seen, then the Android solution (add, but don’t canonicalize right away), that’s where we get case 2. Case 2 would be what happens in the middle. -SFC: That makes sense. Case 2 and 3, what happens here is the ECMAScript engine should paper over what’s on the OS level, my code shouldn’t care, it should just pick a canonical ID and return it, if it maps from old to new it should return ECMAScript canonical ID. If we wait two years before updating the canonical one, that’s great, but we should not specify what happens. +SFC: That makes sense. Case 2 and 3, what happens here is the ECMAScript engine should paper over what’s on the OS level, my code shouldn’t care, it should just pick a canonical ID and return it, if it maps from old to new it should return ECMAScript canonical ID. If we wait two years before updating the canonical one, that’s great, but we should not specify what happens. JGT: What that does mean is that you can, if your code, dumbly, has a hard-coded dependency on a particular ID and uses === to see if it’s the ID you want, if that changes (ECMAScript or OS), your code is going to break. For people who write code that way, do we want the OS updates to break them or the ECMAScript engine updates to break them? @@ -260,13 +260,13 @@ SFC: ECMAScript? RGN: Or does ECMAScript not have an opinion on this, at least not a normative one. -SFC: If I’m running node 18, I want it to have the same behavior regardless of OS. I think that would be good. I think it would be good to reduce that variance as much as possible. It’s a job of the ECMAScript specification – the only one – is to provide a platform that you can build apps against and then run them in any environment where ECMAScript is supported. In terms of code that relies on === for TZID, we solve most of those problems by doing case-normalization. Every user is going to have a different default time zone, it’s easy to change, that’s not something that apps can/should rely on. Also locale IDs. There’s also cases where locales change (Hebrew, changed the name, Norwegian…). The matter is that it’s not really something that I see as a, it’s an expectation that DefaultTimeZone can change at any time. Sometimes it’s hard to avoid people relying on the wrong invariants. +SFC: If I’m running node 18, I want it to have the same behavior regardless of OS. I think that would be good. I think it would be good to reduce that variance as much as possible. It’s a job of the ECMAScript specification – the only one – is to provide a platform that you can build apps against and then run them in any environment where ECMAScript is supported. In terms of code that relies on === for TZID, we solve most of those problems by doing case-normalization. Every user is going to have a different default time zone, it’s easy to change, that’s not something that apps can/should rely on. Also locale IDs. There’s also cases where locales change (Hebrew, changed the name, Norwegian…). The matter is that it’s not really something that I see as a, it’s an expectation that DefaultTimeZone can change at any time. Sometimes it’s hard to avoid people relying on the wrong invariants. -JGT: What do you think of idea from Android of react native app that can call into native libraries that in turn give the OS value. ECMAScript vs. the native libraries could give different answer as to what the ID of the system is. +JGT: What do you think of idea from Android of react native app that can call into native libraries that in turn give the OS value. ECMAScript vs. the native libraries could give different answer as to what the ID of the system is. SFC: I would rather have ECMAScript version give same results in all environments. Others can disagree, I’m nimble on that position, but that’s my position coming into this. -YSZ: Probably to say I have a different stance than SFC, because we’re focusing on smooth integration into rest of OS, so we’d rather see consistent result in one platform rather than one ECMAScript version. In terms of implementation, JSC doesn’t have case 1 or case 2 problem. If we go to implementing a hard-coded list of strings, case 1 and case 2 in JSC would be broken. iOS also gets very frequent updates of time zones, so time zone information in OS is more frequently updated than in JSC. In terms of this problem this would be a regression. The problem is, this is my opinion, is that these things can happen in various OSes, is that JSC not using same values as V8 or system. I wonder if we should more strongly prevent this === thing, since we don’t have much control of the version of the OS. Updating frequently doesn’t help much. +YSZ: Probably to say I have a different stance than SFC, because we’re focusing on smooth integration into rest of OS, so we’d rather see consistent result in one platform rather than one ECMAScript version. In terms of implementation, JSC doesn’t have case 1 or case 2 problem. If we go to implementing a hard-coded list of strings, case 1 and case 2 in JSC would be broken. iOS also gets very frequent updates of time zones, so time zone information in OS is more frequently updated than in JSC. In terms of this problem this would be a regression. The problem is, this is my opinion, is that these things can happen in various OSes, is that JSC not using same values as V8 or system. I wonder if we should more strongly prevent this === thing, since we don’t have much control of the version of the OS. Updating frequently doesn’t help much. EAO: To reiterate, I think making any reference to the host’s opinion about the time zone or other facts should be beyond the scope of the ECMAScript spec. It’s a real problem, but it shouldn’t be solved at this level. I really like making explicit the requirement that if returning a DefaultTimeZone ID that we should also be able to accept it. That’s a valid restriction, but I wouldn’t go any farther than that – allow implementation to keep allowing new canonicalizations as they see fit. I don’t see that this would lead to real problems, because the issue of changing the canonical name before others are likely to accept it would lead to the same problems that Android is working around. It’ll be fine, and we don’t need to fix everything at this level. @@ -286,9 +286,9 @@ EAO: If there’s a specific time frame recommended, we should go to the Android JGT: WIth that caveat, does that sound like what we’re agreeing to? -EAO: Sure! +EAO: Sure! -SFC: No one else on the queue. +SFC: No one else on the queue. SFC: Getting started with discussion slide 3. @@ -300,13 +300,13 @@ JGT: If the answer coming out of this slide is that engines should introduce new EAO: My only concern is that given that all these IDs are originally coming from IANA, the spec-level matter, how I’d phrase it, is that everything’s valid so long as it’s coming from IANA, and in the prose around it a recommendation to keep it up to date, maybe with a delay. -JGT: I would be very happy if that were the conclusion. +JGT: I would be very happy if that were the conclusion. SFC: One possible timeline: three phases in terms of adopting new canonical IDs. First phase is that the canonical is the old form but we know what the alias is, phase 2 is OS and other environments return different things, phase 3 is new ID is canonical form now. We can give recommendations, but each engine can use slightly different timelines, under the expectation that we’ll eventually get to phase 3, and that engines start in phase 1. No strict normative requirement of exactly how long these phases last. JGT: That sounds great. Do we have consensus? -EAO: +1 +EAO: +1 SFC: How do you feel, FYT/YSZ @@ -314,23 +314,23 @@ FYT: Let’s say I have a calendar app, and let’s say I make an appointment to JGT: That problem exists today in firefox. The way to resolve it is to not use === in logic, but instead .equals() method to ensure that what’s in the database reflects the time zone. -FYT: But what if the list does not have the item you store. +FYT: But what if the list does not have the item you store. -JGT: That’s already a problem today. Consider the case of Kyiv – if I rebuild today, Europe/Kyiv is not in the list. You do the matching by the API telling you whether Europe/Kiev and Europe/Kyiv are the same time zone. The proposal on the table is that the guideline we’d have in the spec is that engines should add new IDs as aliases as soon as available, and then eventually in phase 3 switch from the old one to the new one. Today, that amount of time (between phase 1 and phase 3) is zero for Firefox and infinite for V8. +JGT: That’s already a problem today. Consider the case of Kyiv – if I rebuild today, Europe/Kyiv is not in the list. You do the matching by the API telling you whether Europe/Kiev and Europe/Kyiv are the same time zone. The proposal on the table is that the guideline we’d have in the spec is that engines should add new IDs as aliases as soon as available, and then eventually in phase 3 switch from the old one to the new one. Today, that amount of time (between phase 1 and phase 3) is zero for Firefox and infinite for V8. FYT: Why doesn’t Firefox have the issue of breaking things? -JGT: It does, people run around dealing with it. The only time you break anything is when using ===. The goal of this proposal is to give developers in places that have been renamed that we will eventually catch up to the current modern ID for those time zones. In order to do that, we need to provide a method to compare time zones for equality. +JGT: It does, people run around dealing with it. The only time you break anything is when using ===. The goal of this proposal is to give developers in places that have been renamed that we will eventually catch up to the current modern ID for those time zones. In order to do that, we need to provide a method to compare time zones for equality. FYT: How could we ever say “you have to migrate to the new one?” Not sure that’s enforceable. JGT: Do you mean engines or ECMAScript -FYT: Engines. If I only see risk of breaking things by changing, I don’t see a strong benefit. +FYT: Engines. If I only see risk of breaking things by changing, I don’t see a strong benefit. -JGT: The benefit is that we’re no longer offending developers in some of the most populous places in the world by telling them that the name of cities in their country is a name that they haven’t chosen in a long time. Every other system (OS, Java, anything that’s not ES), I’ll get a different answer. The longer we wait to switch over, the more it’s a problem of different answers between ES and everyone else. +JGT: The benefit is that we’re no longer offending developers in some of the most populous places in the world by telling them that the name of cities in their country is a name that they haven’t chosen in a long time. Every other system (OS, Java, anything that’s not ES), I’ll get a different answer. The longer we wait to switch over, the more it’s a problem of different answers between ES and everyone else. -SFC: Here’s what I think you should do, JGT. Agenda deadline is tomorrow, I think you should make the proposal we discussed on the agenda before the deadline, which will give everyone a chance to evaluate it and we can get actual formal feedback about whether this is a good approach. We need to have the proposed timeline well-motivated, and for it to be clear what the motivation is. +SFC: Here’s what I think you should do, JGT. Agenda deadline is tomorrow, I think you should make the proposal we discussed on the agenda before the deadline, which will give everyone a chance to evaluate it and we can get actual formal feedback about whether this is a good approach. We need to have the proposed timeline well-motivated, and for it to be clear what the motivation is. YSZ: Can we separate out ID and actual string representation? The problem I’m seeing is showing is the program using the string as an ID. Could just check if ID is equal, and it’s not necessary for it to be a string form shown to users? @@ -351,10 +351,10 @@ EAO: Yes, we could have a new global symbol registry, but that means we still re JGT: Status: planning to ask for stage 2 in May, Normative changes: Temporal.TimeZone.p.equals API: true if canonical IDs match, false otherwise. Simlar to ZoneDateTime.p.equals, PlainDate.p.equals. -Don’t canonicalize IDs (But do case-normalize) before storing internal slots. +Don’t canonicalize IDs (But do case-normalize) before storing internal slots. TimeZoneEquals will change (canonicalize first, then compare) Also canonicalize in resolvedOptions().timeZone -Remove canonicalization requirement from DefaultTimeZone. Agreement is to leave it up to the engines what happens there. +Remove canonicalization requirement from DefaultTimeZone. Agreement is to leave it up to the engines what happens there. Canonicalization in FormatDateTimePattern, or implementation-defined? SFC: That’s an internal editorial detail, don’t think that matters. @@ -369,15 +369,15 @@ FYC: My concern is – I want to see other peoples’ feelings – is that this SFC: This could be a change after we land, similar to the one we made from RGN earlier in the call (ordering of fields in resolveOptions). If you want to do it that way we can, but I do think we should write down the guidelines about extension keywords in the style guide itself. The problem is that the style guide states (or will state) that all extension keywords that are relevant to the APIs should be accepted by the APIs. Inconsistent with the style guide that we don’t have this – I see this as a spec bug. We should fix – I don’t feel too strongly if we do it now or wait until it lands at stage 4 and then fix it. No strong opinion so long as it’s in for ES2024. -FYT: We are very early in the timeline for 2024, might not be a good idea to put this in the proposal. Would like to hear that other people support it. +FYT: We are very early in the timeline for 2024, might not be a good idea to put this in the proposal. Would like to hear that other people support it. SFC: When do you plan to bring it? -FYT: I think Q4, not soon. +FYT: I think Q4, not soon. -SFC: If you were asking in May or July, I’d say wait for this to land, if it’s November, get normative PR on agenda for May meeting. In terms of timeline, I’d like to fix this. +SFC: If you were asking in May or July, I’d say wait for this to land, if it’s November, get normative PR on agenda for May meeting. In terms of timeline, I’d like to fix this. -FYT: I may not be able to make it to May as a PR, but July is manageable. +FYT: I may not be able to make it to May as a PR, but July is manageable. SFC: Perhaps at the live meeting in Bergen in July. @@ -387,7 +387,7 @@ YSZ: To me, it’s fine to have it integrated in June or July, probably we’ll Conclusion: Plan to propose it as normative PR in July. -### Add “Properties of Intl.Locale Instances” section. +### Add “Properties of Intl.Locale Instances” section. https://github.com/tc39/issues/574 @@ -409,7 +409,7 @@ JGT: Currently only canonical. Main use case for this API is to show dropdown of SFC: Clarifying question, what are these…? -JGT: FIrefox has a weird way of getting its values, assume they’re coming from IANA and marked as canonical in IANA. +JGT: FIrefox has a weird way of getting its values, assume they’re coming from IANA and marked as canonical in IANA. EAO: If you’re asking what time zones those are, they look like Eastern European Time, Central European Time… @@ -421,8 +421,8 @@ JGT: One piece of logic would be: UTC is already special cased, if it’s Etc/GM FYT: One problem with Etc/GMT* is that we see 24 of these here, but they don’t have the half-hour ones. Once we open this, should we have GMT +5,30. That was used in India. -JGT: That doesn’t matter, the half-hour ones don’t exist. The purpose of these time zones is to support areas (for example) in the middle of the ocean. It’s not to substitute for offsets, but rather these are IANA time zones that are not under the jurisdiction of any county. +JGT: That doesn’t matter, the half-hour ones don’t exist. The purpose of these time zones is to support areas (for example) in the middle of the ocean. It’s not to substitute for offsets, but rather these are IANA time zones that are not under the jurisdiction of any county. RGN: The IANA database does not contain any name that doesn’t look like Ect/GMT- followed by a number. -SFC: This comes up a lot in these type of discussion where I see the job of the specification is to encode invariants that developers can rely on. If this is an invariant that we can agree on, we should put it in the spec. We’re out of time, though. +SFC: This comes up a lot in these type of discussion where I see the job of the specification is to encode invariants that developers can rely on. If this is an invariant that we can agree on, we should put it in the spec. We’re out of time, though. diff --git a/meetings/notes-2023-06-01.md b/meetings/notes-2023-06-01.md index 38cbf790..f36e4912 100644 --- a/meetings/notes-2023-06-01.md +++ b/meetings/notes-2023-06-01.md @@ -20,7 +20,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -45,7 +45,7 @@ FYT: The latest spec change improved a lot; just need to find time to implement. DLM: Anba was waiting on spec updates; I can follow up to check the status. -USA: Small TG1 backlog with DurationFormat, presented last TG1, optimistic tone. Need to go back to TG1 for approval on one normative revert related to fractionalDigits defaults. +USA: Small TG1 backlog with DurationFormat, presented last TG1, optimistic tone. Need to go back to TG1 for approval on one normative revert related to fractionalDigits defaults. SFC: There's no core ICU4C implementation of DurationFormat. We could get this expedited in ICU4X if there's an implementation onboard with taking that approach. @@ -95,27 +95,27 @@ JGT: There's also an interop in that it's valid according to the spec to have an RGN: It’s not necessary to store what the ECMAScript code provided -FYT: Up until this point, we’ve had a fixed number of timezones – less than 600. With this change we have a much larger number of timezones, in particular 99.999% are useless. Who cares about one minute from UTC? In Temporal, I can use a very small number to point to the index of a supported timezone. Now I can not. +FYT: Up until this point, we’ve had a fixed number of timezones – less than 600. With this change we have a much larger number of timezones, in particular 99.999% are useless. Who cares about one minute from UTC? In Temporal, I can use a very small number to point to the index of a supported timezone. Now I can not. RGN: There’s a different code-path for offset time zones. FYT: But is this really necessary? Who are using it? We’re opening a can of worms that no one intends to consume. It’s overengineered – it’s flexible for nobody. -SFC: UTS 35 does have a well-defined way to format arbitrary offset strings, usually with a format like GMT+7. It’s not like we’re adding a large set of things that we couldn’t do before – there is a specific algorithm that requires no locale data. +SFC: UTS 35 does have a well-defined way to format arbitrary offset strings, usually with a format like GMT+7. It’s not like we’re adding a large set of things that we couldn’t do before – there is a specific algorithm that requires no locale data. -RGN: This can only store a named offset from the IANA database. At format time it looks for that offset value. This doesn’t get changed by the pull request +RGN: This can only store a named offset from the IANA database. At format time it looks for that offset value. This doesn’t get changed by the pull request ... -JGT: To respond to Shane, is it acceptable to use the colons and dots in the localized string? Can we say GMT+7:30.001? +JGT: To respond to Shane, is it acceptable to use the colons and dots in the localized string? Can we say GMT+7:30.001? -EAO: I’m with Shane in that I’m having a hard time figuring out why this has popular appeal – who is really going to use this, and for what? Maybe there is a use, but I haven’t heard it yet. +EAO: I’m with Shane in that I’m having a hard time figuring out why this has popular appeal – who is really going to use this, and for what? Maybe there is a use, but I haven’t heard it yet. SFC: The display is up to the locale data, and I believe there is locale data on what separators to use, and there is a well-defined algorithm. In Temporal, we discussed offsetNanoseconds and decided to go to a lower level of precision than that. Are we still using nanoseconds, or could we stop at just regular seconds? JGT: I agree that I am not sure that nanoseconds are the necessary precision here. We could raise that in Temporal to see if it can be relaxed. In IANA the most granular offset is in the hundredths of a second. If we could limit it to this, it might not save us storage to go below that, but it’s a reasonable thing to go into at the next Temporal champions meeting, particularly if it’s an implementation issue that could cause pain for implementors. We had discussed the possibility of use cases where it would be necessary, but we didn’t determine what those use cases were. -FYT: I don’t believe this has anything to do with IANA – people using IANA would use this thing. The question is whoever can’t use IANA, what thing do they need? I can understand people wanting it down to the hour, or even minute, but anything below seconds for non-IANA case doesn’t seem useful. Show me a use case for anything below minutes. +FYT: I don’t believe this has anything to do with IANA – people using IANA would use this thing. The question is whoever can’t use IANA, what thing do they need? I can understand people wanting it down to the hour, or even minute, but anything below seconds for non-IANA case doesn’t seem useful. Show me a use case for anything below minutes. RGN: The use case is interoperability. It’s supported by IETF format, it’s supported by ECMA-262. @@ -133,13 +133,13 @@ RGN: Yes, but the system is currently allowed to return it. FYT: We could change there instead of here. -RGN: Yes, but we cannot change the IETF format. +RGN: Yes, but we cannot change the IETF format. FYT: So IETF can say the timezone down to the nanosecond. -RGN: I believe yes +RGN: I believe yes -SFC: Looks like we currently support second precision. We could extend that to hundredth of a second. Nanosecond, though, would mean making our storage bigger, which isn’t likely something we want to do for such a fundamental type. +SFC: Looks like we currently support second precision. We could extend that to hundredth of a second. Nanosecond, though, would mean making our storage bigger, which isn’t likely something we want to do for such a fundamental type. JGT: One thing I recommend is splitting the feedback. There are concerns around resolution, and then concerns around should we provide this capability at all. It would be great if we could give a thumbs-up thumbs-down on the thing itself, with a caveat on the needs of implementors. Note: a lot of data sources for IANA don’t go back to past dates. For example, there has been a lot of merging happening in the database. I believe ICU merges the names, but not the data. ICU does not pull in the pre-1970 offset data for time zones, which is a case where it might be needed. There are odd use cases for this but they do exist. It is interoperable, it’s supported by Java, which in turn drove the IETF spec for backwards compatibility. Those things exist, and it would be a good thing to be interoperable here. @@ -151,33 +151,33 @@ JGT: But is the overall idea a good one? SFC: I support the pull request. It’s a useful feature, there are real use cases for GMT style timezones and renderings of them, and this seems to be a big gap in what Intl supports. For both of those reasons I think it should land once we answer the precision question. -RGN: I’m willing to tweak precision as necessary. The biggest thing for me is getting this in so that we don’t have the inconsistency between 262 and 402. +RGN: I’m willing to tweak precision as necessary. The biggest thing for me is getting this in so that we don’t have the inconsistency between 262 and 402. SFC: Any questions about the spirit of the proposal, putting aside questions of precision? LAF: +1 -EAO: I continue to agree with FYT – minutes makes sense, but I have a hard time understanding why we need more than that. I don’t believe that anyone uses the historical ones with higher-precision offsets. +EAO: I continue to agree with FYT – minutes makes sense, but I have a hard time understanding why we need more than that. I don’t believe that anyone uses the historical ones with higher-precision offsets. RGN: Comment on interoperability point: IETF draft has essentially arbitrary precision. It’s up to TC39 to pick a cutoff. Currently nanoseconds in 262, but that is subject to change. If we decided we wanted seconds, we could do that. -SFC: Sounds like the conclusion here is that we’re not convinced as a group on the precision we should be using, but assuming that we have an appropriately agreeable precision – maybe minutes, maybe lower, not as low as nanoseconds – we can agree on the pull request? +SFC: Sounds like the conclusion here is that we’re not convinced as a group on the precision we should be using, but assuming that we have an appropriately agreeable precision – maybe minutes, maybe lower, not as low as nanoseconds – we can agree on the pull request? ### Editorial: Added note about sets of locales for web browser implementations needing to not change as a result of user behaviour #780 https://github.com/tc39/ecma402/pull/780 -DLM: I’m not familiar with this issue, but I can get feedback from people on our team. +DLM: I’m not familiar with this issue, but I can get feedback from people on our team. -YSZ: I have a question… we're not doing this right now but we may choose to behave differently based on the options. For example, Apple has a lockdown mode for enhanced security. Some of the features are explicitly disabled, which is a fingerprinting vector. My question is, for this statement, is it considering explicit option of the browser or engine as an allowance of this paragraph? Right now, it’s saying the same version of the same version of the same host on the same platform, but my understanding is that it is not including something like lockdown mode. +YSZ: I have a question… we're not doing this right now but we may choose to behave differently based on the options. For example, Apple has a lockdown mode for enhanced security. Some of the features are explicitly disabled, which is a fingerprinting vector. My question is, for this statement, is it considering explicit option of the browser or engine as an allowance of this paragraph? Right now, it’s saying the same version of the same version of the same host on the same platform, but my understanding is that it is not including something like lockdown mode. -EAO: I think it’s arguable that in that case the platform has changed. +EAO: I think it’s arguable that in that case the platform has changed. -YSZ: Right now lockdown mode is system-wide – it changes basically everything. So as you said, we can say that this is a different platform. +YSZ: Right now lockdown mode is system-wide – it changes basically everything. So as you said, we can say that this is a different platform. -SFC: Let’s get another round of feedback from the Apple and Mozilla side on this pull request, and any changes we can make to it in response to Addison’s feedback. It would be good to follow up on this. BAN has made this PR based on feedback from Apple and Mozilla. +SFC: Let’s get another round of feedback from the Apple and Mozilla side on this pull request, and any changes we can make to it in response to Addison’s feedback. It would be good to follow up on this. BAN has made this PR based on feedback from Apple and Mozilla. Conclusions: @@ -190,25 +190,25 @@ https://github.com/tc39/ecma402/pull/788 FYT: In the IETF spec, the time zone precision is to the minute, not even to the second. We figured out that there are hours and minutes, but nothing below seconds. That is not, though, the case in 262 – only in IETF. -RGN: I am going to open a normative PR against 262 on this today. +RGN: I am going to open a normative PR against 262 on this today. SFC: Does that require changes to Temporal? -RGN: It won’t, because Temporal is going to leave that part of 262 unaltered. We’ll discuss in Temporal, though. +RGN: It won’t, because Temporal is going to leave that part of 262 unaltered. We’ll discuss in Temporal, though. SFC: Seems like we’ll be able to get this into 16 bits, which is nice. RGN: The question was whether it supports offset timezones beyond the limitations of IETF, but that decision will be made inside the Temporal group. -SBE: I’m kind of wondering if – this is related – iCalendar allows for UTC offsets down to the second, but iCalendar also provides display names for time zones. Basically, trying to figure out the extent of defining a timezone that may not necessarily be part of default IANA timezone set. +SBE: I’m kind of wondering if – this is related – iCalendar allows for UTC offsets down to the second, but iCalendar also provides display names for time zones. Basically, trying to figure out the extent of defining a timezone that may not necessarily be part of default IANA timezone set. -RGN: Not sure I understand the question, but: the offset timezones are disjoint from the IANA timezones +RGN: Not sure I understand the question, but: the offset timezones are disjoint from the IANA timezones -FYT: Could you open a new issue and we could put it on the agenda? We’ll need to look into the details. +FYT: Could you open a new issue and we could put it on the agenda? We’ll need to look into the details. -RGN: If iCalendar has a use case for offset precision below minutes, we wouldn’t want the needs of iCalendar to be unsatisfied by the new format. +RGN: If iCalendar has a use case for offset precision below minutes, we wouldn’t want the needs of iCalendar to be unsatisfied by the new format. -EAO: It might be nice to include any available indications of using such offsets with seconds other than 00. Although the standard supports it, I doubt whether it’s actually being used. +EAO: It might be nice to include any available indications of using such offsets with seconds other than 00. Although the standard supports it, I doubt whether it’s actually being used. FYT: I think previously SBE is talking about "4.3.14 UTC Offset" in https://www.ietf.org/rfc/rfc2445.html#section-4.3.14 @@ -238,47 +238,47 @@ SFC: My conclusion here is twofold. First, as stewards of i18n on the Web platfo SFC: homedepot.com had some issues last year with CLDR updates. They had code that, for example, did conversions by searching by regexes and manually changing the strings to 24 hour format. JS lets developers do this, but several things go wrong here: Parsing localized strings is wrong -Should have been using a library like moment.js +Should have been using a library like moment.js We have formatToParts(), and if they really wanted to do this themselves they could have avoided parsing. If they *must* write this code, choose “und” as the locale. -What made this case different? It’s important to be very clear here that we update CLDR data every six months. The behavior of the web platform changes every six months, which has been an understanding since the original version of the Intl spec that this happens and should be expected. Why did this change break things? The crucial difference is that this code is based on English data, and a lot of websites use English data as the canonical thing, and make assumptions that are much less likely to be true in other languages. There are major changes that happen more often in other locales. “Misuse” means using localized strings and then doing additional processing on them. If you use the format() function to get these strings, you should display them to the user and do nothing else with them. This causes problems for us, and it also causes problems for downstream users who aren’t getting the right result, and they also cause problems with libraries that aren’t using the tips of CLDR. +What made this case different? It’s important to be very clear here that we update CLDR data every six months. The behavior of the web platform changes every six months, which has been an understanding since the original version of the Intl spec that this happens and should be expected. Why did this change break things? The crucial difference is that this code is based on English data, and a lot of websites use English data as the canonical thing, and make assumptions that are much less likely to be true in other languages. There are major changes that happen more often in other locales. “Misuse” means using localized strings and then doing additional processing on them. If you use the format() function to get these strings, you should display them to the user and do nothing else with them. This causes problems for us, and it also causes problems for downstream users who aren’t getting the right result, and they also cause problems with libraries that aren’t using the tips of CLDR. Given this evidence, the main thing I want to present to you is “how do we prevent misuse?” 1. This is a motivation for Temporal – if we had a better standard library, this case – taking localized strings and doing things to them to do things that are otherwise unsupported. A robust library would prevent this. - 2. The other is better documentation. Very bad advice comes out of (for example) stackoverflow, bad advice motivated by not understanding that locales can change on a regular basis. + 2. The other is better documentation. Very bad advice comes out of (for example) stackoverflow, bad advice motivated by not understanding that locales can change on a regular basis. 3. Public relations push? Get articles on Hacker News? 4. Fuzz testing – this is similar to how the Home Depot issue was discovered. Encourage broader testing with canary. -Can we get more developers to use canary, and roll out CLDR updates only after incubating in canary for N months. This gives developers opportunities to find problems that result from misuse of localized strings. +Can we get more developers to use canary, and roll out CLDR updates only after incubating in canary for N months. This gives developers opportunities to find problems that result from misuse of localized strings. How should the ecosystem fix this issue? What is the long-term solution? -Keep this hack in perpetuity? +Keep this hack in perpetuity? This is what happens if we don’t do anything. Remove the hack in an upcoming release? Update to CLDR data. I think Home Depot fixed this problem, but there are likely others we haven’t seen. Is this risk sufficiently mitigated? -Make the change only in en/en-US and not change elsewhere. CLDR is considering this. As the web platform this is a direction we could go – it could solve the Home Depot problem, it could solve other problems. Even en-CA isnt as misused as en and en-US. If we make the change just there, it can limit the scope of the problem. +Make the change only in en/en-US and not change elsewhere. CLDR is considering this. As the web platform this is a direction we could go – it could solve the Home Depot problem, it could solve other problems. Even en-CA isnt as misused as en and en-US. If we make the change just there, it can limit the scope of the problem. DLM: First, I 100% agree that people shouldn’t do this, so I’m sympathetic to trying to educate people away from doing this sort of thing. I’m a little skeptical, though, since people are always going to make these types of mistakes or misuses. We see this coming up even in Mozilla from developers not familiar with i18n. This is partially a question and partially a comment: how does the CLDR committee make these decisions? Sure, to prevent this mistake in the future. I was wondering if someone could give a quick update on how the decision-making process works on the CLDR side. I’ve reviewed the ICU update that brought this into Firefox, and there was frustration from our web compatibility folks about why it changed. But for en-US locale we can’t be 100% certain that people aren’t going to rely on it. There have been other sites with problems like the Home Depot issue. In TC39 we stress web compatibility and are willing to tolerate suboptimal things to maintain compatibility, and I’m wondering if CLDR might make similar decisions. EAO: Two thoughts. First I’m reminded of a proposal that Addison Philips brought a while back about localizable strings. Is it possible to start migrating to something that looks a little bit like a string, but with information about directionality, script, and so forth, but is really just a blob. From the outside, make it more difficult to just parse the string you get out of it. Second part is that I wonder if ther’s space for us to implicity find a different locale than en-US to act as a default, and that we could get CLDR to be more strict about making changes like this. A locale – something like International English – that could be very specifically defined and could be reliable for the case where people still would do [garbled] -SBE: Part of what EAO was saying does provide a solution to what I was going to say, which is: there’s Hiram’s law, which is that any observable part of your API is going to be depended upon by users. I think that there are two directions that this takes us: one is that if we try to ensure that nobody every breaks because of a CLDR update, that’s going to be nearly impossible as long as they have insight into those particular details, or CLDR stops changing. Long-term, trying to maintain differences from the standard in order to prevent breakages is not a tenable position. I do think, though, that what EAO was saying about making that less observable goes some distance toward improving that situation. +SBE: Part of what EAO was saying does provide a solution to what I was going to say, which is: there’s Hiram’s law, which is that any observable part of your API is going to be depended upon by users. I think that there are two directions that this takes us: one is that if we try to ensure that nobody every breaks because of a CLDR update, that’s going to be nearly impossible as long as they have insight into those particular details, or CLDR stops changing. Long-term, trying to maintain differences from the standard in order to prevent breakages is not a tenable position. I do think, though, that what EAO was saying about making that less observable goes some distance toward improving that situation. -DLM: I would be willing to remove it, for the middle ground you propose, and ideally for everything. +DLM: I would be willing to remove it, for the middle ground you propose, and ideally for everything. -JGT: I think in some ways this is a little bit of a worst-case, because it affected English, it was about characters you couldn’t see – no one would catch it in development because a space and an nbsp look the same. I think, though, that we shouldn’t overreact to that, because this happens very rarely. Also, one of the problems was a communication problem from CLDR to ICU to node. Node did a minor release that in theory shouldn’t contain any breaking changes at all, and it would be nice if ICU would have a big loud note about changes so that consumers can be aware of that. +JGT: I think in some ways this is a little bit of a worst-case, because it affected English, it was about characters you couldn’t see – no one would catch it in development because a space and an nbsp look the same. I think, though, that we shouldn’t overreact to that, because this happens very rarely. Also, one of the problems was a communication problem from CLDR to ICU to node. Node did a minor release that in theory shouldn’t contain any breaking changes at all, and it would be nice if ICU would have a big loud note about changes so that consumers can be aware of that. -SFC: I like the meta-approach that we should coordinate with CLDR on that. I know Matias from the V8 team has started attending CLDR calls from time to time, largely in response to this issue. Hopefully that will make some steps toward preventing this in the future. I do think that as stewards of the web platform for internationalization, we have a responsibility to make this point, because we have a role in pushing the ecosystem in this direction. Whenever we talk about this, we should stress fuzz testing and not introspecting strings that come out of Intl APIs. Down the road we could use Addison Philips’s string API to actually prevent this, but until then encouraging testing should be a thing we do in this group. We’ll see if the change for en-US lands, and then hopefully that will get us closer to re-converging again on CLDR. +SFC: I like the meta-approach that we should coordinate with CLDR on that. I know Matias from the V8 team has started attending CLDR calls from time to time, largely in response to this issue. Hopefully that will make some steps toward preventing this in the future. I do think that as stewards of the web platform for internationalization, we have a responsibility to make this point, because we have a role in pushing the ecosystem in this direction. Whenever we talk about this, we should stress fuzz testing and not introspecting strings that come out of Intl APIs. Down the road we could use Addison Philips’s string API to actually prevent this, but until then encouraging testing should be a thing we do in this group. We’ll see if the change for en-US lands, and then hopefully that will get us closer to re-converging again on CLDR. ### Use Etc/Unknown (like ICU does) to handle the case when the OS's time zone is unrecognized by ECMAScript #25 @@ -290,7 +290,7 @@ SBE: #1 is not something that could be used in a calendar context, where you do JGT: I share the same concern. -YSK: I have some concerns about using Etc/Unknown. From the issue we already know that this timezone can not be used by other tools like python jabber and c++ chrono library. This is not a time zone id that is not stated in IANA database, so basically it’s an invalid ID. If we keep using UTC, from the user’s perspective keeping it working is at least better, because at any time a new ID can be added. It is not great if the system is carrying this new id and the the system starts doing something very wrong. Still working with UTC would be preferable for users. We do not have enough way to know that we are using an unknown timezone or not, and I wonder if we should have a different interface, or a different way, to know whether this is an unknown thing or not. +YSK: I have some concerns about using Etc/Unknown. From the issue we already know that this timezone can not be used by other tools like python jabber and c++ chrono library. This is not a time zone id that is not stated in IANA database, so basically it’s an invalid ID. If we keep using UTC, from the user’s perspective keeping it working is at least better, because at any time a new ID can be added. It is not great if the system is carrying this new id and the the system starts doing something very wrong. Still working with UTC would be preferable for users. We do not have enough way to know that we are using an unknown timezone or not, and I wonder if we should have a different interface, or a different way, to know whether this is an unknown thing or not. JGT: I’ve been thinking about this is that this is clearly – if you don’t know what the time zone is, and you call an API that needs the timezone, the output is guaranteed to be wrong (unless you happen to have a zero offset to UTC in your timezone), so for most of the world any result will be wrong. Whether we handle this wrongness by showing an invalid local time or throwing an exception. If you’re providing anything with Etc/Unknown, you’re already providing bad data. I agree with SBE’s concerns, though I’m worried about the complexity of providing another API. This feels like a case where falling loudly and obviously is the best thing we can do to help programmers figure out how to do. @@ -302,17 +302,17 @@ EAO: Doing it in a docker container might be possible? JGT: I think [Anba] has done that, and he might be the person to ask. I think it may be as easy as passing the TZ environment value. -SFC: My question is: I’m wondering, as another approach, if there’s a way for ECMAScript to require the platform to give us not only an IANA timezone but also the current offset. If we get a timezone that we don’t understand, we can fall back to the offset timezone. +SFC: My question is: I’m wondering, as another approach, if there’s a way for ECMAScript to require the platform to give us not only an IANA timezone but also the current offset. If we get a timezone that we don’t understand, we can fall back to the offset timezone. -JGT: interesting idea! My only concern is that might be much harder for people to understand what’s going wrong. I’ve looked at bug reports that people filed in 2022 when Europe/Kyiv showed up. That’s an easy string to search for on the web. If you show offset strings, it prevents programs from failing but also prevents people from finding out what the problem is and fixing it. Not sure which is better. +JGT: interesting idea! My only concern is that might be much harder for people to understand what’s going wrong. I’ve looked at bug reports that people filed in 2022 when Europe/Kyiv showed up. That’s an easy string to search for on the web. If you show offset strings, it prevents programs from failing but also prevents people from finding out what the problem is and fixing it. Not sure which is better. SFC: Clarifying question: if people google the string, what is the action they can take? Should they install the latest updates? -JGT: That’s the only sensible thing to recommend to users. Because browsers are evergreen, it’s a reminder to the user that the red dot in the corner in Chrome, you should pay attention to that. The other case is organizational users, so they can ping I.T.. Other is apps that bundle tz info, as in electron apps. +JGT: That’s the only sensible thing to recommend to users. Because browsers are evergreen, it’s a reminder to the user that the red dot in the corner in Chrome, you should pay attention to that. The other case is organizational users, so they can ping I.T.. Other is apps that bundle tz info, as in electron apps. -SFC: My main concern is that this is not something that developers can fix, unless they’re developers of an Electron app. Most users, if they see Etc/Unknown, they’re not going to know what it is and they’re going to ignore it. It’s not helpful information to users. Users will eventually update their browser, and then the problem is fixed. If it were a developer problem, I would be much more receptive to the idea that we should give something that’s easy to find and fix, but if this is a user problem I lean toward the side of making the best effort – getting the offset timezone and displaying that. +SFC: My main concern is that this is not something that developers can fix, unless they’re developers of an Electron app. Most users, if they see Etc/Unknown, they’re not going to know what it is and they’re going to ignore it. It’s not helpful information to users. Users will eventually update their browser, and then the problem is fixed. If it were a developer problem, I would be much more receptive to the idea that we should give something that’s easy to find and fix, but if this is a user problem I lean toward the side of making the best effort – getting the offset timezone and displaying that. -JGT: Because offsets changed because of DST, if you ask the OS what the offset is, the only way to know that is to know what date you’re looking for the offset for. +JGT: Because offsets changed because of DST, if you ask the OS what the offset is, the only way to know that is to know what date you’re looking for the offset for. SFC: Maybe “current offset” @@ -324,8 +324,8 @@ JGT: I think that the thing I would be a little concerned about is. Well, okay, EAO: The talk about whether it’s a developer problem or a user problem – isn’t this really an implementation problem? The browser or other environment that doesn’t understand what the system is saying – isn’t it on that instead of the JavaScript spec? -JGT: To YSK’s point, on Apple’s platforms this is no issue because the browser and OS share one ICU. The Chromium implementation embeds the ICU database, so with each version you get the same results. +JGT: To YSK’s point, on Apple’s platforms this is no issue because the browser and OS share one ICU. The Chromium implementation embeds the ICU database, so with each version you get the same results. -SFC: It doesn’t seem like we have a firm conclusion, but we have at least identified the people we need to follow up with. YSK, myself, EAO, SBE. +SFC: It doesn’t seem like we have a firm conclusion, but we have at least identified the people we need to follow up with. YSK, myself, EAO, SBE. JGT: This is useful, though it’s sad that we can’t figure out what to do yet. diff --git a/meetings/notes-2023-06-29.md b/meetings/notes-2023-06-29.md index 06263bff..e040a046 100644 --- a/meetings/notes-2023-06-29.md +++ b/meetings/notes-2023-06-29.md @@ -16,7 +16,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -35,11 +35,11 @@ N/A https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -FYT: One update on Intl.LocaleInfo. Planning to propose advance to stage 4 in November or January, but not now. Changes to come. +FYT: One update on Intl.LocaleInfo. Planning to propose advance to stage 4 in November or January, but not now. Changes to come. SFC: No update on Era Codes. Will try to get it on agenda for July or September TC39. -JGT: Asking for stage 3 on timezone canonicalization +JGT: Asking for stage 3 on timezone canonicalization ## Pull Requests @@ -49,11 +49,11 @@ https://github.com/tc39/ecma402/pull/786 USA: Has consensus from TG2 -### Normative: Reorder NF resolved option “roundingPriority” +### Normative: Reorder NF resolved option “roundingPriority” https://github.com/tc39/ecma402/pull/768 -USA: Needs Test262. I assume there is no Test262? This is conditionally approved by the committee +USA: Needs Test262. I assume there is no Test262? This is conditionally approved by the committee FYT: The thing about test262 is twofold. If there’s already tests asking for a particular order, those tests need to be changed. Second thing is that we should add a test to validate it if there is no such thing. There is no need to need additional tests – I believe there is already something, but we don’t know the input. That’s not sopmething that should be stopping this. @@ -67,11 +67,11 @@ USA: Removed “needs discussion” label, added “has consensus” https://github.com/tc39/ecma402/pull/786 -FYT: If we add this support, do we also need to change Intl.Locale? This is a bigger issue – all of the other things we have options for, we have a getter in Intl.Locale. +FYT: If we add this support, do we also need to change Intl.Locale? This is a bigger issue – all of the other things we have options for, we have a getter in Intl.Locale. -USA: So this needs to also make the corresponding changes to Intl.Locale. +USA: So this needs to also make the corresponding changes to Intl.Locale. -YSZ: I discussed internally about this sentence breaking feature, we are comfortable with this correction. +YSZ: I discussed internally about this sentence breaking feature, we are comfortable with this correction. FYT: I support adding it, but we need to discuss whether we should add it together with Intl.Locale support. I don’t think we discussed that part – we discussed the other part, but we didn’t discuss adding a getter for Intl.Locale @@ -81,9 +81,9 @@ YSZ: Are we having a getter for all these extensions in Intl.Locale right now? FYT: For whatever’s supported, yes. -YSZ: This sounds like we should add it. +YSZ: This sounds like we should add it. -USA: We can record conditional consensus, or just consensus on the behavior but not the PR, +USA: We can record conditional consensus, or just consensus on the behavior but not the PR, FYT: Did we already add it? I didn’t see it since BAN added the changes, I’ll need to review it. @@ -97,13 +97,13 @@ https://github.com/tc39/ecma402/pull/788 FYT: Temporal changed courses dramatically after the last time we discussed this. -JGT: We’re introducing a normative PR to move it to minutes. +JGT: We’re introducing a normative PR to move it to minutes. SFC: I think we were mostly happy with that last month – are there any updates to make to the PR to reflect that? JGT: I haven’t looked at this one yet. -SFC: Since RGN isn’t here, let’s hold it for the September TG1. +SFC: Since RGN isn’t here, let’s hold it for the September TG1. ## Proposals and Discussion Topics @@ -121,13 +121,13 @@ JGT: Your suggestion, if I’m reading it correctly, is that we should have some YSZ: Yes, correct -JGT: Since this is such a rare circumstance, I’m not too worried about passing it to other things, my perspective is that what you want to be able to do is let the ECMAScript developer know that something has gone wrong, so that they can prompt the user to solve the problem. +JGT: Since this is such a rare circumstance, I’m not too worried about passing it to other things, my perspective is that what you want to be able to do is let the ECMAScript developer know that something has gone wrong, so that they can prompt the user to solve the problem. YSZ: In this case we were already returning a UTC and making it work. A change breaking these tools would not be great right now. SFC: Refreshing my memory of where the conversation had been: One question, which I’m not sure if I asked, is that if we reach Etc/Unknown, how does that get rendered? [..] Another option is to display an offset timezone, but so long as the display name is Unknown, that’s fine -FYT: The source of this Etc/Unknown is coming from UTS 35. There’s a private use in. [...] The reason we have them returning from [...] Basically: it’s coming from that, and there are also localization for that zone ID, inside ICU. In the spec and the CLDR too. In CLDR they have localization for that zone name, for whatever we cannot recognize. +FYT: The source of this Etc/Unknown is coming from UTS 35. There’s a private use in. [...] The reason we have them returning from [...] Basically: it’s coming from that, and there are also localization for that zone ID, inside ICU. In the spec and the CLDR too. In CLDR they have localization for that zone name, for whatever we cannot recognize. FYT: Let’s look at a locale, `kw`, there are timezone names for that. So what are the English names? It just says “Unknown”. There are definitely localizations for this, but it’s not part of the name. So if it’s not in there, what do we do? @@ -137,7 +137,7 @@ YSZ: We’re fine if it’s included in the IANA database FYT: To clarify, that’s not my position, I was just showing where it comes from. The tricky thing is how can we represent something that is not representable? Once you put that in the IANA database, then it’s in the IANA database, and then we need another thing to represent what’s not in there. If you put the code to represent that something isn’t in set A in set A, that’s in set A so you need something new to represent things that aren’t in set A. -YSZ: We’re fine with it, this is kind of like an error condition propagated, user can pass something wrong, you can see Etc/Unknown at some poitn. This might be because UTC doesn’t understand the time zone code coming from somewhere, the error propagates, it’s fine. Same if user explicitly gives Etc/Unknown. I think it’s fine, so long that it’s not used as like an actually associated timezone to some reason. +YSZ: We’re fine with it, this is kind of like an error condition propagated, user can pass something wrong, you can see Etc/Unknown at some poitn. This might be because UTC doesn’t understand the time zone code coming from somewhere, the error propagates, it’s fine. Same if user explicitly gives Etc/Unknown. I think it’s fine, so long that it’s not used as like an actually associated timezone to some reason. [ JGT: Given that ICU in the links that we sent out, even though the spec talks about IANA, in reality ECMAScript depends on ICU for all major implementations. Since ICU already has this, are you okay with treating it as a first-class timezone? @@ -145,11 +145,11 @@ SFC: This reminds me of the question we were talking about in Temporal for some JGT: I agree with SFC and that UTS 35 is a good place to put it, because all ECMAScript implementations depend on CLDR and the string is already in there. This can avoid the complexity of getting IANA to do things, which as far as I can tell is pretty hard. -FYT: Two things for YSZ. Currently, if you look at IANA database it does not have a lot of things. It doesn’t have GMT+1,00. It has GMT+1, it does not have GMT+1 and after that, minutes. If we follow the mandate that it has to be in IANA, every single minute offset in the day would have to also be in IANA. We currently only have UTC from -14 to +12, all the hours are there. The second thing, it’s already UTS 35, we don’t need to add it, it already exists, is clarified, and is there. I think there are two places, and that other parts have it. +FYT: Two things for YSZ. Currently, if you look at IANA database it does not have a lot of things. It doesn’t have GMT+1,00. It has GMT+1, it does not have GMT+1 and after that, minutes. If we follow the mandate that it has to be in IANA, every single minute offset in the day would have to also be in IANA. We currently only have UTC from -14 to +12, all the hours are there. The second thing, it’s already UTS 35, we don’t need to add it, it already exists, is clarified, and is there. I think there are two places, and that other parts have it. YSZ: I have two things, basically. Onee is that if we’d like to use this thing, we should explicitly state in the spec that instead of IANA database, we will prefer this thing and that we don’t explicitly sync with IANA database. But why I’m having concerns about this thing is that it is already known that browsers don’t accept Etc/Unknown. The question is how to avoid these things. -JGT: YSZ, it’s an interesting question, because if the time zone is unrecognized then no matter what it’s broken. The question is should it be broken so that it throws, so that it displays differently so that users get a sense of what’s broken, or should it be masked so that the program and user could not know it was broken and send bad data. The choice I like the most is the middle one – we don’t crash, but we allow the programmer in the ID and the end user in the localized text that there’s something wrong, so that they can choose to fix it. I see this as better than the extremes. +JGT: YSZ, it’s an interesting question, because if the time zone is unrecognized then no matter what it’s broken. The question is should it be broken so that it throws, so that it displays differently so that users get a sense of what’s broken, or should it be masked so that the program and user could not know it was broken and send bad data. The choice I like the most is the middle one – we don’t crash, but we allow the programmer in the ID and the end user in the localized text that there’s something wrong, so that they can choose to fix it. I see this as better than the extremes. YSZ: If there’s a solution which doesn’t break things, which is just add an API to tell whether this is accepted or not, I don’t see why we don’t do that. That avoids crashes in currently working implementations, and it’s also a good way to know what is happening. @@ -159,17 +159,17 @@ SFC: My comment is that I’m trying to understand YSZ’s concern about breakag YSZ: Browsers, if not throwing right now for any unknown string, it is nice if we could make the spec say as input we accept broader things, and for output we let out specific things. Anything adjacent with timezone string from the browser or JS engine and feeding it to C++ or something, it is already known that this Etc/Unknown is not accepted by these tools, but UTC can be just accepted. The question is as JGT said, if it’s possible that a programmer will not change or fix something, this is showing the difference. Right now, JGT says that if we add a new API and a programmer doesn’t notice and doesn’t fix it, well, that’s because it is working. In terms of breakage, there’s a severe difference – it’s kind of strange introducing a new crash that doesn’t happen to force a programmer to do some work. -JGT: It doesn’t look like we’re heading toward consensus today, and so I think I’ll leave it here. The only thing I’d say is that crashing is not the only kind of breakage. Today, if your tz is unrecognized and you get UTC back as an identifier, you care going to be sending bad data to everyone. If you live in Ukraine and you’re using UTC, all your times are going to be off by an hour or two. I don’t think that’s worse than the case where you’re crashing because you’re sending output to C++. +JGT: It doesn’t look like we’re heading toward consensus today, and so I think I’ll leave it here. The only thing I’d say is that crashing is not the only kind of breakage. Today, if your tz is unrecognized and you get UTC back as an identifier, you care going to be sending bad data to everyone. If you live in Ukraine and you’re using UTC, all your times are going to be off by an hour or two. I don’t think that’s worse than the case where you’re crashing because you’re sending output to C++. YSZ: Basically this tools thing is the largest concern to me. In terms of the user pov, a program that works is better. I don’t think that a crash and using the UTC is in the same bucket, or whether that UTC is worse than crashing applications. -JGT: Sounds like we’re not going to have consensus, not going to accept the PR, current state remains as it is. +JGT: Sounds like we’re not going to have consensus, not going to accept the PR, current state remains as it is. SFC: Is the status quo that if we don’t merge this PR, it remains implementation-dependent? JGT: Status is that the current behaviour of every implementation remains the same: Chromium returns Etc/Unknown and crash if used as input, SM and Safari return UTC. -YSZ: My concern is returning Etc/Unknown as output string. No problem with it as an input string. +YSZ: My concern is returning Etc/Unknown as output string. No problem with it as an input string. SFC: It was my understanding at Stage 2 that we’d solve this problem, I don’t know if I’d like to go to Stage 3 without fixing this problem. @@ -177,13 +177,13 @@ JGT: Everything we’re working on here gets worse when Temporal goes out. Tryin SFC: Yeah, I like that. -JGT: Super short summary of what I’ll present in two weeks. Goal: identify anything that anyone in this room might block. Going to focus on those parts of the proposal and skip the rest. We did get to stage 2 last time – only notable thing is that this proposal removes canonicalization from some cases, but does not change case normalization. If you send in america/los_angeles -> America/Los_Angeles. This allows programmers to store tzs as an enumeration. +JGT: Super short summary of what I’ll present in two weeks. Goal: identify anything that anyone in this room might block. Going to focus on those parts of the proposal and skip the rest. We did get to stage 2 last time – only notable thing is that this proposal removes canonicalization from some cases, but does not change case normalization. If you send in america/los_angeles -> America/Los_Angeles. This allows programmers to store tzs as an enumeration. JGT: Obsolete name thing, we’re familiar with, removing obsolete names, that could cause problems, we know === is unreliable for comparing tz ids across engines and times, and Temporal makes it worse. Currently you have to use an obscure API to get tzid, but for Temporal you’ll see them everywhere – anytime you toString(), toJSON(), so many ways these will be put in front of developers. Developers are already complaining today, when it’s hard to get these tzids, but there will be much more once Temporal hits. Added PRs to 262 and Temporal, goal after the July plenary meeting is to get the 402 PR merged as well. Spec is complete, tests are complete, polyfills are there, thumbs up from stage 3 reviewers, hopefully I’ll add a bullet point saying TG2 is okay. Reminder: proposed solution: stop returning canonical IDs when programs provide non-canonical inputs, and using Temporal.TimeZone.p.equals to compare IDs, replacing ===. JGT: Observable impact, spec is complete, 15 changes and one little note, tests are complete and they’re passing. Recommendations for implementors: part of it is done and seems like it’s on-track, which is a guideline for how to handle renaming in the future. We’ve taken an idea from Android: when a new tzid is added, take two years to make it canonical, this gives time for rest of ecosystem to catch up. If you’re sending it to someone else, it’ll be two years before you send people the new name. What’s not on track is this last piece, which is to help implementers converge on implementations. I’ve kicked this out of the proposal because it’s not advancing on the same timeframe. Support CLDR/ICU work, continue discussing in GitHub issues, later propose ECMA402 changes. -FYT: I reject. The current spec you have is not acceptable. Click on your proposals page, there’s two big problems. 1. SystemTimeZoneIdentifier(). This proposal, the rest are in Temporal, this is not in Temporal. +FYT: I reject. The current spec you have is not acceptable. Click on your proposals page, there’s two big problems. 1. SystemTimeZoneIdentifier(). This proposal, the rest are in Temporal, this is not in Temporal. JGT: The PR to limit time zones to minutes has to make the same change, I’m planning on taking this out if the normative PR to reduce time zone to minutes goes through. It’s only here as a backstop in case the Temporal PR is not approved. In the Stage 3 editor’s review I noted that as well. @@ -191,17 +191,17 @@ FYT: So you’re saying section 1.1 will be removed? JGT: It’s an overlap with a normative PR that Temporal is doing, so assuming that is accepted it will be removed. -FYT: If you remove it, that’s good, but the current shape is not acceptable. +FYT: If you remove it, that’s good, but the current shape is not acceptable. JGT: I have another PR that I’m working on now to catch up, there was an editorial PR that just merged into Temporal that replaces this AO with another one, there’s another PR I’m working on right now to catch up this proposal with the editorial change in Temporal. -FYT: My point is I can’t give consensus on something that’s not there. The if clause is also a problem, it bans everything below the minutes, which I can’t support. +FYT: My point is I can’t give consensus on something that’s not there. The if clause is also a problem, it bans everything below the minutes, which I can’t support. JGT: I understand your objection. There is an editorial PR in progress to catch up with the changes in Temporal that have made this one line invalid, and this entire change here will be rendered moot if the normative changes to Temporal are accepted. By the time we actually get in front of the committee in ten days or so, every link in here and spec text will match what’s happening on the Temporal side, hopefully by tomorrow that will be the case, and the change itself is redundant with the Temporal PR. I’m confident that we will be able to resolve your concerns. FYT: What is the part in this proposal? – -JGT: Hold that thought, I’ll go through the slides to continue. Slides have planned spec text change, mostly it’s about not canonicalizing in several different functions/AOs. A more complex piece is adding canonicalization to TimeZoneEquals so that we can compare Asia/Kolkata and Asia/Calcutta, and adding a new API which exposes TimeZone.p.equals, and the final piece is to add editorial prose about the waiting period after IANA renames. Here’s the current state of the line in the PR, which is to use these methods (from Temporal) that should work correctly, that’s how this particular line is going to change. The other change to the PR, TimeZoneEquals got a little longer because of changes to the Temporal side mostly dealing with offset identifiers, but nothing else will change as a result of the Temporal changes that merged last night. +JGT: Hold that thought, I’ll go through the slides to continue. Slides have planned spec text change, mostly it’s about not canonicalizing in several different functions/AOs. A more complex piece is adding canonicalization to TimeZoneEquals so that we can compare Asia/Kolkata and Asia/Calcutta, and adding a new API which exposes TimeZone.p.equals, and the final piece is to add editorial prose about the waiting period after IANA renames. Here’s the current state of the line in the PR, which is to use these methods (from Temporal) that should work correctly, that’s how this particular line is going to change. The other change to the PR, TimeZoneEquals got a little longer because of changes to the Temporal side mostly dealing with offset identifiers, but nothing else will change as a result of the Temporal changes that merged last night. JGT: There are two non-Temporal changes: the two-year waiting period that we got from Android, changing it to 18 months or a year would okay, but we have definitely documented problems that had happened around the Kyiv thing that we want to prevent next time, tehn the other non-Temporal chagne is the change to IntializeDateTimeFormat to not do the canonicalization. Are there other concerns that folks have with the changes to the proposal some time. @@ -209,9 +209,9 @@ FYT: My main concern is the InitializeDateTime thing, from a V8 POV I want to se SFC: Sorry to interrupt, but I’m going to say if these concerns are still here when we meet in Bergen in a couple of weeks, we could discuss them then. I would like to move on to other topics, because I know that there’s several people on the call waiting to discuss their topics. -JGT: Other than FYT’s concerns, which will addressed before we meet, are there other concerns with the proposal as such? +JGT: Other than FYT’s concerns, which will addressed before we meet, are there other concerns with the proposal as such? -YSZ: LGTM. In general we are supportive of this change. It will avoid random string comparisons, which could cause catastrophic issues in the future. +YSZ: LGTM. In general we are supportive of this change. It will avoid random string comparisons, which could cause catastrophic issues in the future. JGT: Other concerns, especially blocking concerns? And as a note, I do want to acknowledge FYT’s concern about seeing lots of changes. For this proposal in particular there haven’t been normative changes since Stage 1. We have considered things, but not added to the scope at all. The only spec text changes that have happened have been to catch up to upstream editorial changes. I apologize for not being as fast as I could with this, but everything will be current by the time we get to Bergen. Couldn’t get it done in time for this meeting, and I apologize for that. @@ -219,23 +219,23 @@ JGT: Other concerns, especially blocking concerns? And as a note, I do want to a https://github.com/tc39/agendas/pull/1409 -USA: So the expectation is that everything should be discussed by our meeting once before it goes to the other group. Looking to document this as best we can. I’ve also been told that the way that we do normative proposal – presenting them at the end of the editor’s update and asking for consensus on all of them – is not correct. So what I did was I took the two normative PRs that we discussed and already had consensus on and added it here, in a new section (Needs consensus) for us. You may see that needs consensus in links to 262, the point is that all of the normative changes to 262 are done in this section, and we need to do ours as well. Going forward I will add each individual item here. Right now I’ve listed them to myself as presenting them, but I would also encourage you to all to present your own PRs if you’re there. I’ll ask BAN, we don’t have anyone from Mozilla on the call, but I can reach out to everyone behind the scenes so that it doesn’t have to be here. +USA: So the expectation is that everything should be discussed by our meeting once before it goes to the other group. Looking to document this as best we can. I’ve also been told that the way that we do normative proposal – presenting them at the end of the editor’s update and asking for consensus on all of them – is not correct. So what I did was I took the two normative PRs that we discussed and already had consensus on and added it here, in a new section (Needs consensus) for us. You may see that needs consensus in links to 262, the point is that all of the normative changes to 262 are done in this section, and we need to do ours as well. Going forward I will add each individual item here. Right now I’ve listed them to myself as presenting them, but I would also encourage you to all to present your own PRs if you’re there. I’ll ask BAN, we don’t have anyone from Mozilla on the call, but I can reach out to everyone behind the scenes so that it doesn’t have to be here. SFC: Comments on process: for the PRs it’s good to list them. USA: The idea of consensus is present here, I agree that we should leave things, but on the other hand there’s the idea from folks from TG1 who would like some kind of deliberation for everything that is brought to plenary to happen here. What about a requirement that says that everything Intl-related that’s brought to plenary is discussed here, but not necessarily a clear-cut outcome. -SFC: The actual thing we can check and enforce is that any PRs and proposals have a discussion recorded in the minutes of TG2. +SFC: The actual thing we can check and enforce is that any PRs and proposals have a discussion recorded in the minutes of TG2. USA: I don’t think it needs to be super strong, maybe it would make sense to talk to others from the TG1 side about how strongly they care about reported approval rather than asking for it to be discussed. Personally, I’m happy with the idea that every time we talk about this we can use a label saying “ready for TG1” or something. SFC: Process-wise, we can figure it out. It sounds like the actual proposal is that we must have discussed things here before bringing them to plenary, that can be enforced with “is there a discussion in the meeting notes” -USA: If anyone has major concerns, they can bring it up at plenary. That sounds great to me, if no one objects to it. +USA: If anyone has major concerns, they can bring it up at plenary. That sounds great to me, if no one objects to it. -CDA: Only two minutes for each of those? +CDA: Only two minutes for each of those? -SFC: Rule of thumb: five minutes on each one? +SFC: Rule of thumb: five minutes on each one? ### TG2 “Activities” text @@ -245,19 +245,19 @@ USA: I was discussing with the ECMA staff and they proposed an activity report, ### Align ToIntegerIfInteger with Temporal -https://github.com/tc39/proposal-intl-duration-format/pull/158 +https://github.com/tc39/proposal-intl-duration-format/pull/158 -USA: Real quick: two normative PRs to Intl.DurationFormat. First, align ToIntegerIfIntegral with Temporal. Whichever proposal hits stage 4 first will add it to the spec, we’re changing this here to match Temporal. I intend to present this, let me know if you have any concerns. +USA: Real quick: two normative PRs to Intl.DurationFormat. First, align ToIntegerIfIntegral with Temporal. Whichever proposal hits stage 4 first will add it to the spec, we’re changing this here to match Temporal. I intend to present this, let me know if you have any concerns. ### Revert to previous behaviour by setting fallback value for fractionalDigits to *undefined* -https://github.com/tc39/proposal-intl-duration-format/pull/150 +https://github.com/tc39/proposal-intl-duration-format/pull/150 -USA: Next, what I believe is the last change for DurationFormat. This change is because we had consensus on the wrong change – misunderstood the consensus, presented to plenary a solution that’s not aligned with our consensus. Now it is. +USA: Next, what I believe is the last change for DurationFormat. This change is because we had consensus on the wrong change – misunderstood the consensus, presented to plenary a solution that’s not aligned with our consensus. Now it is. SFC: That looks right to me – aligns with my expectations. No opinion on 158 – if [Anba] and BAN like it, I’m okay. -USA: It’s pretty much the only option – we’re copying a PR that exists in Temporal, if we don’t the behaviour on our side would be different. +USA: It’s pretty much the only option – we’re copying a PR that exists in Temporal, if we don’t the behaviour on our side would be different. ### Intl.Locale Info discussion @@ -265,7 +265,7 @@ https://github.com/tc39/proposal-intl-locale-info/issues/68 FYT: One thing we discussed last time was allowing the extension for `-u-fw` to be accepted, meaning that if you have UTS 35 and you have an fw keyword there, you can specify which day is the first day of the week (sunday, monday, saturday), then that will impact the locale because the reason we talk about right now is because in our proposal we have WeekInfoOfLocale, which returns the first day. That’s why we’re adding a PR to make `-u-fw` as a relevant extension key for Intl.Locale. That’s the first change, which is not controversial. So therefore we should add that in our options bags, right? So that’s the second thing we’re trying to add. In the Intl.Locale API, we have an options bag, which should also accept first day of week. Because Unicode Locale Extensions and this should be synced, according to UTS 35. The other thing is for consistency. -The last part, though, is that because of that literally we will have three different ways to represent a day of week. Before this point we only have two: the Date object has a getDate in 262, returns Sunday as 0. In Temporal, Sunday is 7. IntlLocale.firstDayOfWeek /* -u-fw-sun` in locale {firstDayOfWeek: “sun”) => “sun”. We will have a three-letter code that cannot be changed to a number. In BCP 47 this thing has to be a code with three to eight letters, it cannot be a one letter or one character code. Now we have three different representations: the question is, what should we do with a part that we’re turning to weekday? Currently we’re using numbers, in both cases we’re synchronized with Temporal by using 1 to 7. If we return the three letter code, are we supposed to still return the number, or do we also change the firstDay and weekend thing to string? +The last part, though, is that because of that literally we will have three different ways to represent a day of week. Before this point we only have two: the Date object has a getDate in 262, returns Sunday as 0. In Temporal, Sunday is 7. IntlLocale.firstDayOfWeek /* -u-fw-sun` in locale {firstDayOfWeek: “sun”) => “sun”. We will have a three-letter code that cannot be changed to a number. In BCP 47 this thing has to be a code with three to eight letters, it cannot be a one letter or one character code. Now we have three different representations: the question is, what should we do with a part that we’re turning to weekday? Currently we’re using numbers, in both cases we’re synchronized with Temporal by using 1 to 7. If we return the three letter code, are we supposed to still return the number, or do we also change the firstDay and weekend thing to string? SFC: I’ll attempt to answer: I think that we should set the value to Temporal numbers. This is not unlike what we do with other extension keywords. In terms of this API, we should have numbers. That’s the rule of thumb I prefer. @@ -275,23 +275,23 @@ JGT: Consistency is important, I like SFC’s proposal. SFC: If you take the number mod 7 of the two numerical representations they’re the same. So there is an easy way for developers to convert back and forth. In the case of hourCycle, we use the strings throughout the API, so that’s not a problem so much. In terms of other extension keywords– -FYT: For example, we’re not using 24 or 12, we’re using “hc11”, “hc12”. Before we go down to that part, are we okay with this? If option bag were taking string code, would that be okay? And for firstDayOfWeek, returning the string code, is that okay? +FYT: For example, we’re not using 24 or 12, we’re using “hc11”, “hc12”. Before we go down to that part, are we okay with this? If option bag were taking string code, would that be okay? And for firstDayOfWeek, returning the string code, is that okay? JGT: I don’t think I know enough to have a strong opinion, other than that I align with SFC’s opinion as before: if the input and the output are the same, that’s easier for developers. If we want to also be permissive and allow the string codes, I wouldn’t object to that, but I do think that the documented way for the input should match the output. SFC: This may also be a good question for us to bring up with ZB. I’ll ping and see if he can join an upcoming call. It looks like, though, that we don’t have precedent for when the ECMAScript representation of a thing is not in the same namespace as BCP 47. As I see it, things that belong to BCP 47 should be in the BCP 47 namespace and everything else in the ECMAScript namespace. This is, though, an interesting problem and there’s no precedent for how to handle it. This is not an Intl problem, it’s something we could escalate to TG1. -FYT: I have a PR that has that included, would you support me if I just remove this change and go to TG1 to ask for consensus? I included it knowing that we should remove it, but I wanted to show you the changes. +FYT: I have a PR that has that included, would you support me if I just remove this change and go to TG1 to ask for consensus? I included it knowing that we should remove it, but I wanted to show you the changes. SFC: Let’s schedule a half hour in Bergen to discuss with TG1 -FYT: Another quick question: it hasn’t been added yet, we’re supposed to have this option bag named firstDayOfWeek. +FYT: Another quick question: it hasn’t been added yet, we’re supposed to have this option bag named firstDayOfWeek. -SFC: If they’re in different namespaces, it’s probably good that they’re different. +SFC: If they’re in different namespaces, it’s probably good that they’re different. FYT: Agreed! I’ll remove that part from my PR and ask for consensus for the rest. -SFC: Sounds great! +SFC: Sounds great! ### Locale Extensions update diff --git a/meetings/notes-2023-08-03.md b/meetings/notes-2023-08-03.md index 7f806eae..748fc286 100644 --- a/meetings/notes-2023-08-03.md +++ b/meetings/notes-2023-08-03.md @@ -17,7 +17,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -52,7 +52,7 @@ BAN: (introduces PR) SFC: It does seem useful to have the extension keywords – I’m not sure if removing the tags from the locale is the right direction – we could go the other way. Then we can have the locale identifier and the options bag consistent with each other. I also worry that if we start removing this information it may not be completely web-compatible. Adding is easier than taking them back out, especially because the options for setting these are not that old. -ZB: I’m glad that someone noticed the inconsistency, but I’m concerned about making locale lossy. The way I try to think of locale in this setting is that the signal we’re getting from the client is that they’re reading it directly or having it provided elsewhere. If they provide it explicitly, there’s value in maintaining it. The reason why that’s the case is that there’s nothing set in stone about the hour cycle being h23 in English – it could change in the future. If we’re trying to decouple these values, it makes to sense to say. It seems like your PR is making it lossy. I would say that if it were listed in either the string or the options bag, then keep it. If not listed, of course not. Or even that if you set in the extensions and then unset it in the options. +ZB: I’m glad that someone noticed the inconsistency, but I’m concerned about making locale lossy. The way I try to think of locale in this setting is that the signal we’re getting from the client is that they’re reading it directly or having it provided elsewhere. If they provide it explicitly, there’s value in maintaining it. The reason why that’s the case is that there’s nothing set in stone about the hour cycle being h23 in English – it could change in the future. If we’re trying to decouple these values, it makes to sense to say. It seems like your PR is making it lossy. I would say that if it were listed in either the string or the options bag, then keep it. If not listed, of course not. Or even that if you set in the extensions and then unset it in the options. FYT: I don’t think we can use undefined as a value. That’s equal to “we don’t have that option” @@ -64,9 +64,9 @@ ZB: For this PR, gain more consistent and explicit behavior is great, I side wit SFC: We do have a way to, if you want to unset the hour cycle, that’s what we have the Intl.Locale APIs for. I think doing hourCycle: undefined has a difference from the absence of an hourCycle field. What I would expect the behaviour to be in these cases is that rows 1 and 2 are correct, 3 and 4 should both have h23, that way the tag hour cycle and the options hour cycle are the same. -EAO: on the third one I agree that it should be en-u-hc-h23, but the fourth one should just be en. This is a template for the fields that the user expected to be there, and then for the resulting locale to include or not include these fields in the result. +EAO: on the third one I agree that it should be en-u-hc-h23, but the fourth one should just be en. This is a template for the fields that the user expected to be there, and then for the resulting locale to include or not include these fields in the result. -FYT: My question is what the motivations to make a change here? Are they strong enough to deserve a change? +FYT: My question is what the motivations to make a change here? Are they strong enough to deserve a change? SFC: This looks like the original issue, FYT, it looks like you filed it in 2019? But are the motivations still strong enough? @@ -77,7 +77,7 @@ Four options: Remove the extension keywords Add all the extension keywords Leave it the way it is -Only have the extension keywords if they were already present in the locale. +Only have the extension keywords if they were already present in the locale. I lean toward option 2, where we add all of the flags all the time, which means the options bag and locale string are consistent with each other. I’m also okay with leaving the weird status quo for this edge case, but I don’t necessarily think that the motivation that this is confusing for users is fairly strong, I don’t know if it rises to the level of making a normative change. The standard for that should be “this is a behaviour we should have had when we introduced the field a few years ago, but didn’t think to.” @@ -89,17 +89,17 @@ BAN: proposes adding a note explaining the behaviour? EAO: One approach is to consider that we have two different ways that users may be giving the options to us. Do we have a preference between them? The options bag approach that the Intl constructors have are telling the story that this is the way that things are supposed to go. Are we making a explicit preference for one or the other? Like, “you can do it this way, you can do it that way, but this way is better” – and in this case, it’s the options bag that’s better. -RGN: We’ve very clearly sending a preference, because any option that’s set in both the string and the bag, the bag wins. +RGN: We’ve very clearly sending a preference, because any option that’s set in both the string and the bag, the bag wins. EAO: By that logic, I would be happy with anything that’s in the bag getting removed from the string. -SFC: I still maintain my webcompat concerns. I’m fine with a solution that involves adding more clear documentation about the behaviour here. It’s a weird corner of the API, but it’s fine – there’s a lot of things in this API that are a lot weirder. +SFC: I still maintain my webcompat concerns. I’m fine with a solution that involves adding more clear documentation about the behaviour here. It’s a weird corner of the API, but it’s fine – there’s a lot of things in this API that are a lot weirder. -FYT: I propose no change – I don’t see a strong case to solve people’s problem and there’s a small risk for webcompat issue and extra work for the developers. With no strong reason to make change, there’s a strong reason to not make a change. +FYT: I propose no change – I don’t see a strong case to solve people’s problem and there’s a small risk for webcompat issue and extra work for the developers. With no strong reason to make change, there’s a strong reason to not make a change. EAO: +1 to that. -RGN: That makes sense, and I really like BAN’s idea of capturing the reasoning in a note. If nothing else, it will be relevant if this should come up again. Decision for now to not change behavior, and also to document the behaviour and its motivation. +RGN: That makes sense, and I really like BAN’s idea of capturing the reasoning in a note. If nothing else, it will be relevant if this should come up again. Decision for now to not change behavior, and also to document the behaviour and its motivation. SFC: +1 @@ -117,25 +117,25 @@ SFC: Hope to see a concrete presentation/update next month. https://github.com/tc39/ecma402/pull/811 -FYC: [missed part]. The problem is that even after #768, the reading order for rounding are grouped together, but they’re not alphabetical. There’s no reason to move them together and not sort them – if we care about order, let’s care about order. But when I went to make this I realized we have a bug in #768 – the AO is used by Intl.PluralRules, but PluralRules doesn’t have the required internal slot. I don’t think it’s implementable as stands, because the AO will not be able to access a field that PluralRules doesn’t have. +FYC: [missed part]. The problem is that even after #768, the reading order for rounding are grouped together, but they’re not alphabetical. There’s no reason to move them together and not sort them – if we care about order, let’s care about order. But when I went to make this I realized we have a bug in #768 – the AO is used by Intl.PluralRules, but PluralRules doesn’t have the required internal slot. I don’t think it’s implementable as stands, because the AO will not be able to access a field that PluralRules doesn’t have. There are two things going on here: one, the editorial change to make the PluralRules work, the second is ordering the result options and options reading of those three to be the correct order, same between PluralRules and NumberFormat, to have consistency. That’s this PR. -RGN: I have not looked at the bug you’re describing, I trust you on that. I have a preference for putting that in a separate PR. We know from hard work in the Temporal proposal that there is a preferred order: on reading, copy all the properties in iterator order, and then afterward it’s all unobservable so you don’t have to worry about order concerns. On output, alphabetical order or logical, if there’s a clear logical order. But copying everything up front and then keeping order unobservable after that is the best strategy. +RGN: I have not looked at the bug you’re describing, I trust you on that. I have a preference for putting that in a separate PR. We know from hard work in the Temporal proposal that there is a preferred order: on reading, copy all the properties in iterator order, and then afterward it’s all unobservable so you don’t have to worry about order concerns. On output, alphabetical order or logical, if there’s a clear logical order. But copying everything up front and then keeping order unobservable after that is the best strategy. FYT: I don’t see what you’re saying. -RGN: The problem in this PR is that we don’t follow the best practice of reading the options all at once. If we did that, like Temporal does, this problem would never come up. It’s a clear best practice for the specification, but it would be normative to adopt it. If normative changes are on the table I am for adopting that best practice – not fiddling with the order of specific things, but going all the way to reading all the options up front. +RGN: The problem in this PR is that we don’t follow the best practice of reading the options all at once. If we did that, like Temporal does, this problem would never come up. It’s a clear best practice for the specification, but it would be normative to adopt it. If normative changes are on the table I am for adopting that best practice – not fiddling with the order of specific things, but going all the way to reading all the options up front. SFC: My feeling here is that I agree that long-term we should work toward the world that RGN describes, but also that it’s okay to land smaller incremental changes that get us in that direction. This is a fine small change on a relatively recently landed proposal, so it’s fine from my perspective. However, I agree that for any new proposal we should do what Temporal does. I don’t think it’s worth the disruption of an across-the-board change to the existing APIs, though. It’s fine to have small incremental approvals. -RGN: In this case it looks fine to me, but I would still like to see this PR split between the actual fix and the normative change. +RGN: In this case it looks fine to me, but I would still like to see this PR split between the actual fix and the normative change. FYT: Let’s say I want to split. I need to specify how the plural rules should output result options. What should I put on there? Currently, in order to make that change I need to change that table. If I only change the algorithm to make the editorial change, the resolvedOptions() output of the plural format will be inconsistent with the order of NumberFOrmat. -RGN: I’m willing to adopt this if it’s not possible to split in the way that I want. If I do find a way I’ll structure it such that we end up in the same place. +RGN: I’m willing to adopt this if it’s not possible to split in the way that I want. If I do find a way I’ll structure it such that we end up in the same place. -FYT: Originally my intention was to be a normative change, but I found out that there’s an editorial issue here. In a sense the editorial part is the attachment to this normative thing. If the way to fix it for the editorial part, no problem, but that’s not my motivation. +FYT: Originally my intention was to be a normative change, but I found out that there’s an editorial issue here. In a sense the editorial part is the attachment to this normative thing. If the way to fix it for the editorial part, no problem, but that’s not my motivation. RGN: If I can split it, I will, and if not it’ll have whatever structure this one has in terms of commits. I think there’s still an open question of if we’re doing it or not – the rest of it is editorial management. But “accept or reject” is on the table for this group. @@ -145,21 +145,21 @@ RGN: I applaud your ambition and it works for me. SFC: What’s the conclusion that we should record for this? -RGN: Assuming no objections, we adopt it and I assume the responsibility of separating the followup fix from the observable change. +RGN: Assuming no objections, we adopt it and I assume the responsibility of separating the followup fix from the observable change. SFC: Does that work for you? -FYT: Can we add this to the agenda for the plenary? +FYT: Can we add this to the agenda for the plenary? SFC: All of these normative changes have to go on the agenda. FYT: But do we agree to go there? -RGN: I’m in favour. +RGN: I’m in favour. -SFC: +1. Is the PR to bring to plenary the one that’s already been written, or a new one? +SFC: +1. Is the PR to bring to plenary the one that’s already been written, or a new one? -RGN: It should be this one. I assume FYT has the allow maintainer edits. Any rewriting can take place in the context of this PR. +RGN: It should be this one. I assume FYT has the allow maintainer edits. Any rewriting can take place in the context of this PR. #### Conclusion @@ -177,17 +177,17 @@ BAN: That’s the hard question – ICU doesn’t use it. FYT: This isn’t a general exposable thing that if you ask a question it’ll give it to us, it depends on what the available locale is. Whatever comes out is limited to what the system supports. In theory we could have some T extensions, but practically I don’t think anyone ships T extension data. This is a theoretical case, since one part of the sets that need to be matched are not including the whole thing, at least not what we’re currently aware about. Theoretically, yes, practically, I don’t believe it impacts anything, therefore it’s difficult to test. -RGN: I haven’t reviewed the spec text, but the description makes sense and I am in principle in support of this change. In terms of testability, if anyone wants to expose an interface by which the set of locales could be manipulated by command line flags, that opens up an avenue to test it in test262, but without that it’s not going to be testable. I’m alright with just having scrutiny on the text itself. Engine262 would also be a possibility, though I don’t think they have enough of the infrastructure to be at the point of testing this yet. +RGN: I haven’t reviewed the spec text, but the description makes sense and I am in principle in support of this change. In terms of testability, if anyone wants to expose an interface by which the set of locales could be manipulated by command line flags, that opens up an avenue to test it in test262, but without that it’s not going to be testable. I’m alright with just having scrutiny on the text itself. Engine262 would also be a possibility, though I don’t think they have enough of the infrastructure to be at the point of testing this yet. -SFC: Another question: what is the motivation for including the -x- and -t- in locale lookup anyway? +SFC: Another question: what is the motivation for including the -x- and -t- in locale lookup anyway? -RGN: If an implementation did, discarding that is a disadvantage. +RGN: If an implementation did, discarding that is a disadvantage. SFC: Not sure about -t- extensions, it doesn’t necessarily make sense that engines would want to do negotiation with the T and U extensions, though possibly the X extensions. FYT: I am supporting this PR, but I think this is non-observable. This should be an editorial PR. -RGN: I’m certain it’s observable, but none of the current implementations do. +RGN: I’m certain it’s observable, but none of the current implementations do. FYT: So not observable. @@ -195,11 +195,11 @@ RGN: But that’s not what it means – it means that any conforming implementat FYT: How do you know that they’re the same or different? -RGN: You never know for sure. The ECMA262 mathematical operations are similar – implementations do not explore the full space of conforming behaviour, but that doesn’t mean those changes don’t count as observable. +RGN: You never know for sure. The ECMA262 mathematical operations are similar – implementations do not explore the full space of conforming behaviour, but that doesn’t mean those changes don’t count as observable. FYT: Are they normative? -RGN: yes. Or rather, anything normative is observable. “Observable as used” is something that relates to any conceivable conforming implementation. +RGN: yes. Or rather, anything normative is observable. “Observable as used” is something that relates to any conceivable conforming implementation. SFC: It’s exposed indirectly in a lot of places – but if it’s not directly exposed to anyone, it’s not an observable change. @@ -211,15 +211,15 @@ FYT: How? SFC: Let’s treat this as normative just to be safe. -BAN: The problem is that the current state of the spec is buggy – if a hypothetical implementation tries to use `-t-` extensions, they’ll have invalid lookups. +BAN: The problem is that the current state of the spec is buggy – if a hypothetical implementation tries to use `-t-` extensions, they’ll have invalid lookups. RGN: Strongly agree with that; with the current spec text being buggy, I'm in support of a change. I need to review the details of this one. FYT: Looking at the PR, line 90 strips the Unicode locale extensions, and now you're removing it? Are you going to add it back? -BAN: In practice, everything using this AO strips out the Unicode extensions anyway. +BAN: In practice, everything using this AO strips out the Unicode extensions anyway. -SFC: Let’s bring the detailed discussion of the spec text offline, it seems like we’re aligned on the spirit of it. Let’s bring it back up for discussion next month to bring it to the next plenary. If there are substantive updates, we should bring it to the group, otherwise we can say we’ll approve this PR to take to plenary aside from the feedback on the exact wording. +SFC: Let’s bring the detailed discussion of the spec text offline, it seems like we’re aligned on the spirit of it. Let’s bring it back up for discussion next month to bring it to the next plenary. If there are substantive updates, we should bring it to the group, otherwise we can say we’ll approve this PR to take to plenary aside from the feedback on the exact wording. FYT: I have some concerns. I would like to make it explicit what the use case for this PR is. Is it to support any additional extension other than U extensions @@ -227,7 +227,7 @@ SFC: We should list the motivation, but as I see it is that if implementation us FYT: I have a problem here. Here it is: if we look at the big picture, the larger context of this AO’s use, before you call this thing we pass in certain relevant keys for the operation. Everything related to the relevant extension keys are dealt with, everything that’s not is ignored or stripped out. So, if we consider that, anything that not in the U extension is also not a relevant key, and should be treated the same way as any other U extension key not listed in the relevant keys. This isn’t consistent with the larger context of why we have [[RelevantKeys]] – we should strip out everything not in [[RelevantKeys]] and not a U extension. -RGN: I disagree. There’s lots of implementation and locale-specific behaviour that’s escape hatches, and X extensions would be relevant for that. They can’t deviate based on relevant extension keys, but relevant extension keys on their own don’t specify behaviour. +RGN: I disagree. There’s lots of implementation and locale-specific behaviour that’s escape hatches, and X extensions would be relevant for that. They can’t deviate based on relevant extension keys, but relevant extension keys on their own don’t specify behaviour. FYT: Let me make an example: in U extensions there’s u-rg. Regional override specifies supposed behaviour, but currently it’s not in relevant keywords, so we ignore it. We strip it out, even if it’s in there. By the same meaning, all these other extensions should go. @@ -237,17 +237,17 @@ SFC: I agree with what RGN says here. The subdivision subtag is something that c FYT: My point is that currently we in the bigger picture say that if we pass in a locale, language country or region and script are used for negotiation, and anything in U extension are not used for negotiation unless they are specifically stated in relevant keywords. The T and X keywords are forbidden unless they’re allowed to [[RelevantKey]]. Keeping this in mind, how could we allow them in this context? They should be treated by the relevant key, because we have an inclusive list for negotiation for U extensions. We should also have an inclusive framework for those things. I’m not opposing the change, I do oppose that we treat -t- and -x- extensions as higher priority than [[RelevantExtensionKeys]]. -RGN: If you see (say) an nu- subtag that specifies a numbering system, that’s something we expect ECMA402 to pay attention to. That is not true and it cannot be true of an -x- extension, because -x- is private use. To have an implementation pay attention to any -x- tag that might appear, that’s fine, but we can’t have them add something that. +RGN: If you see (say) an nu- subtag that specifies a numbering system, that’s something we expect ECMA402 to pay attention to. That is not true and it cannot be true of an -x- extension, because -x- is private use. To have an implementation pay attention to any -x- tag that might appear, that’s fine, but we can’t have them add something that. FYT: If it’s private use, it should be private use. -RGN: Yes, but that requires that the implementation be allowed to pay attention to it. If the specification requires the implementation ignore it, it is no longer available for private use +RGN: Yes, but that requires that the implementation be allowed to pay attention to it. If the specification requires the implementation ignore it, it is no longer available for private use -BAN: My first thought is that there's a lot of wording ambiguity in the spec. There's not a term for referring to `-t-` or `-x-` extensions, but `-u-` extensions has its own term. Preferences, in order: Keep the extensions, require implementations to ignore them, and then finally the current situation where we allow implementations to consider them but provide a buggy algorithm for doing so. +BAN: My first thought is that there's a lot of wording ambiguity in the spec. There's not a term for referring to `-t-` or `-x-` extensions, but `-u-` extensions has its own term. Preferences, in order: Keep the extensions, require implementations to ignore them, and then finally the current situation where we allow implementations to consider them but provide a buggy algorithm for doing so. RGN: I agree with that order of preferences. -SFC: I have a strong preferences for allowing implementations to use them and not require that they ignore them. But if we can’t reach consensus on that then I don’t know how I’d rank between two and three on those options that BAN listed out. I don’t like requiring implementations to ignore private use extensions, that’s not the direction we should take. +SFC: I have a strong preferences for allowing implementations to use them and not require that they ignore them. But if we can’t reach consensus on that then I don’t know how I’d rank between two and three on those options that BAN listed out. I don’t like requiring implementations to ignore private use extensions, that’s not the direction we should take. SFC: T has a very specific semantics that’s not used for negotiation generally, but could be. If you wanted your locale to be Zawgyi or Chinese Pinyin or Hinglish, all of those use T extensions. @@ -255,20 +255,20 @@ BAN: Sometimes T extensions are use in Japanese to mark that text translated fro FYT: It’s a pretty big change to say that unicode extensions are exclusive and others inclusive. -RGN: Right now it’s not strictly limited, because the algorithm is intending to handle them, but is doing it wrong. +RGN: Right now it’s not strictly limited, because the algorithm is intending to handle them, but is doing it wrong. -FYT: I understand that the current algorithm has bugs, I’m saying that the [[RelevantKey]] thing we’re not taking anything in U extensions unless they’re listed here. +FYT: I understand that the current algorithm has bugs, I’m saying that the [[RelevantKey]] thing we’re not taking anything in U extensions unless they’re listed here. -EAO: I understand perfectly well why we would want to have different practices for U vs T and X. U is a scope where later we might want to define things, with X we’re saying we’re never going to step in this space. +EAO: I understand perfectly well why we would want to have different practices for U vs T and X. U is a scope where later we might want to define things, with X we’re saying we’re never going to step in this space. -FYT: I agree with what you said: if we take that as RGN suggests, we’re taking the stance that we’ll never touch T. I don’t want to close that door. +FYT: I agree with what you said: if we take that as RGN suggests, we’re taking the stance that we’ll never touch T. I don’t want to close that door. SFC: I don’t necessarily understand that allowing the extensions to be used in negotiation closes the door for us to use them in other ways in the future. EAO: The way I see it, if we allow an implementation to establish a meaning for a T extension and we establish a different meaning for that T extension, this is problematic. This is what I understand RGN to have said a while ago on this. -SFC: I think if were were to use the T extension it would be for an Intl.Transliterator context, which is where the T extension could have meaning. This doesn’t mean that the T extension can’t be used for negotiation elsewhere. If an engine is providing Hinglish or Chinese Pinyin data, that data should be available to Intl.DateTimeFormat even if Intl.Transliterator used it for something different. And this is what’s going on with this Unicode locale extensions, we’re ignoring them for the purpose of negotiation. We’re spending like an hour now discussing a thing that we can’t tell is observable. This gives engines flexibility in the future – I don’t think any decision we make now blocks any other doors in the future. -SFC preferences: +SFC: I think if were were to use the T extension it would be for an Intl.Transliterator context, which is where the T extension could have meaning. This doesn’t mean that the T extension can’t be used for negotiation elsewhere. If an engine is providing Hinglish or Chinese Pinyin data, that data should be available to Intl.DateTimeFormat even if Intl.Transliterator used it for something different. And this is what’s going on with this Unicode locale extensions, we’re ignoring them for the purpose of negotiation. We’re spending like an hour now discussing a thing that we can’t tell is observable. This gives engines flexibility in the future – I don’t think any decision we make now blocks any other doors in the future. +SFC preferences: Allow use of T and X Leave it the way it is @@ -276,13 +276,13 @@ Remove them BAN: In any case, we should document this. -SFC: How about both documenting it and also fixing the algorithm to allow their use. +SFC: How about both documenting it and also fixing the algorithm to allow their use. FYT: What does “fixing” mean? -SFC: Let’s look at the original conversation. It looks like the team advised +SFC: Let’s look at the original conversation. It looks like the team advised -FYT: My point is that the resolution for this one was to take that out. +FYT: My point is that the resolution for this one was to take that out. SFC: My read was that he was saying what his team had decided to do, but that he wanted clarification from us. @@ -292,19 +292,19 @@ RGN: An answer can take the form of “we have made the spec something unambiguo FYT: Spec text is not usually the best answer to a question. -RGN: Would you consent to extensions to V8 to make this testable? +RGN: Would you consent to extensions to V8 to make this testable? -FYT: No. You’re saying the reply is a spec change, I’m saying without unit tests +FYT: No. You’re saying the reply is a spec change, I’m saying without unit tests SFC: what are the points of contention? The only one I can identify that’s clear is this concern about whether making a change here closes the door to consume T and X extensions in a different way in the future, FYT was saying yes it does, I say it doesn’t. So if we can agree that this doesn’t close the door – if we were to agree that making this change would definitely close the door on using T and X in the future, is that a reason to adopt or not adopt this behaviour? RGN: For me I say reservedly yes, but there’s the question of what constitutes a change. Making it clear that implementations are allowed to factor in T and X subsequences constitutes a change, given that they’re mentioned in the algorithms. If we don’t know where we are right now, we do not agree on what is allowed and prohibited, it’s more difficult to assess the proposed new spec texts because we’ll have different interpretations of its consequences. -SFC: What is allowed right now is that the spec allows and requires the resolution of these extensions to get into invalid forms – requires they be used, and requires that they be used in a buggy way. +SFC: What is allowed right now is that the spec allows and requires the resolution of these extensions to get into invalid forms – requires they be used, and requires that they be used in a buggy way. -RGN: Does anyone disagree? If I understand FYT correctly, I hear you saying that you do disagree– that implementations aren’t allowed to factor them in right now. Looking at the current state of the spec, SFC has asserted and I agree that implementations are required to pay attention to all subtags, including X and T sequences. +RGN: Does anyone disagree? If I understand FYT correctly, I hear you saying that you do disagree– that implementations aren’t allowed to factor them in right now. Looking at the current state of the spec, SFC has asserted and I agree that implementations are required to pay attention to all subtags, including X and T sequences. -FYT: I don’t get it, why are they require to pay attention? +FYT: I don’t get it, why are they require to pay attention? RGN: There’s nothing to strip them out right now. It’s in a loop that strips off the ending subtags from the end. So if the input includes an -x- subtag sequence, then the algorithm requires the implementation to check them against available locales. @@ -312,7 +312,7 @@ FYT: So you’re saying if we pass an X extension, or a T extension RGN: As currently specified the algorithm requires paying attention to both T and X. -FYT: And we are going to take them off one by one and match whatever is in available locales. And these only behave differently if we have those partially stripped-off locales. +FYT: And we are going to take them off one by one and match whatever is in available locales. And these only behave differently if we have those partially stripped-off locales. RGN: availableLocales could contain en, en-us, en-gb. Do you agree that the current algorithm text requires implementations to pay attention to an -x- subtag sequence? @@ -320,7 +320,7 @@ FYT: Yes RGN: Therefore it would be a change if we required implementations to ignore that subtag sequence. -FYT: Correct. +FYT: Correct. RGN: Popping up the stack, it sounds like we have agreement on the current state of the specification. Implementations are required to pay attention, and implementations are allowed to use them. In light of the current state of this matter, we agree that it would be a change to require them to ignore it, and the question is that if we required them to ignore it would that close the door on future use? @@ -330,7 +330,7 @@ RGN: Is there consensus that continuing to allow them to use it does not close a SFC: Current situation is that the X and T extensions are used in a buggy way. I think the state that we’d like it to get to is one where implementations are allowed to use an implementation to find an algorithm as to how to match X and T extensions. This strip last subtag algorithm isn’t the best way for this. -RGN: Yes, I think this strip last tag algorithm makes sense within the language identifier, but not the broader locale identifier. +RGN: Yes, I think this strip last tag algorithm makes sense within the language identifier, but not the broader locale identifier. BAN: Would it be reasonable to not dictate the algorithm? Since only specific implementations that we don’t know about are even potentially using it, what if we say the algorithm for using them should be implementation defined? @@ -338,23 +338,23 @@ SFC: I hate this algorithm – I kind of want to make it all implementation-defi RGN: If we did that, would there be any difference between LookupMatcher and BestFitMatcher? -SFC: That’s a good question. LookupMatcher is designed to be an “algorithmic algorithm,” not implementation-dependent. +SFC: That’s a good question. LookupMatcher is designed to be an “algorithmic algorithm,” not implementation-dependent. -EAO: I’m not sure what the spec says about this, but the place to find out what it does is the MDN page on it. MDN says “this is the matching algorithm from BCP 47, best fit should be at least as good as that.” +EAO: I’m not sure what the spec says about this, but the place to find out what it does is the MDN page on it. MDN says “this is the matching algorithm from BCP 47, best fit should be at least as good as that.” SFC: This is used by LookupMatcher -FYT: It’s used by both. +FYT: It’s used by both. RGN: Is anyone familiar with the algorithm referenced by LookupMatcher. It looks like our hands are tied – we’re going to follow the RFC 4647 3.4 algorithm for LookupMatcher. It doesn’t leave a lot open – the implementations are open on BestFitMatcher, but for LookupMatcher they have to do just this. This technically does factor in the X and T sequences, but not necessarily in a useful way. For that reason, it’s unlikely to come up in implementations, even the hypothetical ones we’re discussing. But because it is so simple, it would be possible for us to write tests. EAO: Because of the specific example given here, for the BestFitMatcher it ties our hands to need to look at the X extensions as well and care about what’s in there, in order to be at least as good as LookupMatcher. -RGN: I can agree with that, but BestFit is already implementation defined, at most we could “encourage” that implementors not ignore X extensions. We wouldn’t require an implementation to ignore them, but we won’t get precise about how they affect results. +RGN: I can agree with that, but BestFit is already implementation defined, at most we could “encourage” that implementors not ignore X extensions. We wouldn’t require an implementation to ignore them, but we won’t get precise about how they affect results. FYT: We can have tlang, this can have en-latn-gb, you can cut off gb, you can cut off latn, it’s still valid. -RGN: Because availableLocales has content that is canonicalized, at any given step if it matches it matches against something that’s already canonicalized. The output is guaranteed to be canonicalized if not empty. Even in the current form. +RGN: Because availableLocales has content that is canonicalized, at any given step if it matches it matches against something that’s already canonicalized. The output is guaranteed to be canonicalized if not empty. Even in the current form. RGN: I think that there is no need to change the current algorithm. diff --git a/meetings/notes-2023-09-07.md b/meetings/notes-2023-09-07.md index 421c6b23..312108af 100644 --- a/meetings/notes-2023-09-07.md +++ b/meetings/notes-2023-09-07.md @@ -21,7 +21,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -42,7 +42,7 @@ EAO: The workflow is in decent shape and progressing. We are having a MFWG face- https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -FYT: Stage 3 LocaleInfo blocked by issue with firstWeek stuff proposed to TC39, issues related. Have to come back and talk to CLDR about first day of week stuff. Filed ticket, Mark (?) addressed it with SFC, issues a little more complicated because addressing it doesn’t just mean considering the `fw` parameter, but also `-u-rg` and `-u-sd`. That part blocked. Not confident that it’ll be in shape for 2024. Good thing: CLDR spec will be addressed. From there we’ll have a solid ground to move on. +FYT: Stage 3 LocaleInfo blocked by issue with firstWeek stuff proposed to TC39, issues related. Have to come back and talk to CLDR about first day of week stuff. Filed ticket, Mark (?) addressed it with SFC, issues a little more complicated because addressing it doesn’t just mean considering the `fw` parameter, but also `-u-rg` and `-u-sd`. That part blocked. Not confident that it’ll be in shape for 2024. Good thing: CLDR spec will be addressed. From there we’ll have a solid ground to move on. ## Proposals and Discussion Topics @@ -53,7 +53,7 @@ https://github.com/tc39/ecma402/projects/2 https://github.com/tc39/proposal-intl-duration-format/pull/172 -FYT: Big picture: we’re currently reading [[NumberSystem]] last, in all the rest of 402 we follow output order in terms of reading order. Anba suggests that we move it up, just below locale. The detail is that the order was accidentally changed in another PR, didn’t have consensus, other PR was about something else. Another PR, already merged, to revert the accidental merge. Not against moving it to top, but need to go through process. +FYT: Big picture: we’re currently reading [[NumberSystem]] last, in all the rest of 402 we follow output order in terms of reading order. Anba suggests that we move it up, just below locale. The detail is that the order was accidentally changed in another PR, didn’t have consensus, other PR was about something else. Another PR, already merged, to revert the accidental merge. Not against moving it to top, but need to go through process. SFC: Being consistent across 402 is important, locale extensions should appear next to locale. We spend a lot of time bikeshedding in this group about resolvedOptions enumeration order, but this looks good to me. @@ -83,7 +83,7 @@ https://github.com/tc39/proposal-intl-duration-format/pull/167 SFC: Many good editorial changes in this PR, with one normative change. We need to approve this. -FYT: I strongly support this. I currently have to do something weird to output the other way / to comply with the unchanged spec. It would be nice to have this. +FYT: I strongly support this. I currently have to do something weird to output the other way / to comply with the unchanged spec. It would be nice to have this. LAF: +1 @@ -95,7 +95,7 @@ FYT: There are tests, but we’ll have to change them to conform with this chang JGT: What is the user-facing impact of this? -FYT: Very small. If we don’t change this, the resolvedOptions() for the option will say `undefined`, just as in the changed version. The only difference is that the key won’t show up. +FYT: Very small. If we don’t change this, the resolvedOptions() for the option will say `undefined`, just as in the changed version. The only difference is that the key won’t show up. RGN: It's no longer guaranteed to be `undefined`; it becomes a prototype lookup. But this is who all the other resolved options work. So I support this. @@ -111,13 +111,13 @@ Approved by this group. https://github.com/eemeli/proposal-intl-root-locale -EAO: What is the problem we’re solving? It’s twofold – one is that everything we define as a behaviour of all of the Intl formatters is completely implementation-dependent, everyone can do whatever they want for all of these. This, of course, means that everyone has focused on using CLDR/ICU, and we tend to align, and the different implementations produce the same results for the same locales. It would be useful, though, for us to define a root or null locale that we explicitly define the behaviour of within the specification itself. The second part is that there are ways of formatting dates, DateTime especially but possibly the other formatters, that are quite tricky. ISO 8601 formatting? Stackoverflow suggests horrible hacks like formatting everything in Swedish. Currently the proposal suggests using the "und" locale. Most browsers already have behavior defined for this. But we could also decide to use a different language tag that is more rare: "zxx". This is the “no linguistic content / not applicable” locale. The nice thing about this is that it is valid, it’s well-behaved, and we would not be stepping on any implementation’s toes using “zxx” for this. +EAO: What is the problem we’re solving? It’s twofold – one is that everything we define as a behaviour of all of the Intl formatters is completely implementation-dependent, everyone can do whatever they want for all of these. This, of course, means that everyone has focused on using CLDR/ICU, and we tend to align, and the different implementations produce the same results for the same locales. It would be useful, though, for us to define a root or null locale that we explicitly define the behaviour of within the specification itself. The second part is that there are ways of formatting dates, DateTime especially but possibly the other formatters, that are quite tricky. ISO 8601 formatting? Stackoverflow suggests horrible hacks like formatting everything in Swedish. Currently the proposal suggests using the "und" locale. Most browsers already have behavior defined for this. But we could also decide to use a different language tag that is more rare: "zxx". This is the “no linguistic content / not applicable” locale. The nice thing about this is that it is valid, it’s well-behaved, and we would not be stepping on any implementation’s toes using “zxx” for this. -This would not add any new interfaces, this would just allow for “und” or “zxx” as a locale identifier. One particular bit, though, is that if we go with “zxx” that’s even worse than “und” as a trigger for behaviour. +This would not add any new interfaces, this would just allow for “und” or “zxx” as a locale identifier. One particular bit, though, is that if we go with “zxx” that’s even worse than “und” as a trigger for behaviour. I would suggest we support `null` as an alias for this locale. This is what I have on this right now. -SFC: First thing, thank you so much for making this proposal and putting it together – it’s a very important problem space. We saw a lot with the narrow numbering space issue that I presented at this group a couple of months ago. If this new locale doesn’t exist, we’ll never be able to migrate people. Won’t solve our problems, but good as a way for people who need this type of stability for testing or for other reasons, a way to do it that’s otherwise not explicitly specified. JGT says that it looks like how Temporal has the ISO 8601 calendar fully specified, and the UTC time zone. Having one fully specified locale will be useful for testing and the ecosystem as a whole. I like the idea of the “null” keyword as the trigger for this locale. I’m not decided on “und” vs. “zxx” – “und” is convenient, but also loaded because it already has meaning. If we’re okay specifying that meaning, we have to make sure that we’re consistent across all implementors. There’s a certain elegance of having “zxx” or some other locale as the constant locale, because it separates two objectives: “und” is the root fallback locale, which isn’t guaranteed to be stable, but we can define “zxx” as the stable locale. That’s something interesting to discuss at stage 1 or 2. One more thing I wanted to say: I anticipate it will take a lot of time with this proposal bikeshedding exactly what the behaviour is in all cases. One thing we can do: in the spec we have all these JSON objects that specify locale data, one way we could go about specifying this is “define by what’s in this JSON object”, just paste it into the spec and that’s how we go about it. There’ll be bikeshedding on this, but I think it’s a good use of our time to do that, because there are real problems that this is solving. +SFC: First thing, thank you so much for making this proposal and putting it together – it’s a very important problem space. We saw a lot with the narrow numbering space issue that I presented at this group a couple of months ago. If this new locale doesn’t exist, we’ll never be able to migrate people. Won’t solve our problems, but good as a way for people who need this type of stability for testing or for other reasons, a way to do it that’s otherwise not explicitly specified. JGT says that it looks like how Temporal has the ISO 8601 calendar fully specified, and the UTC time zone. Having one fully specified locale will be useful for testing and the ecosystem as a whole. I like the idea of the “null” keyword as the trigger for this locale. I’m not decided on “und” vs. “zxx” – “und” is convenient, but also loaded because it already has meaning. If we’re okay specifying that meaning, we have to make sure that we’re consistent across all implementors. There’s a certain elegance of having “zxx” or some other locale as the constant locale, because it separates two objectives: “und” is the root fallback locale, which isn’t guaranteed to be stable, but we can define “zxx” as the stable locale. That’s something interesting to discuss at stage 1 or 2. One more thing I wanted to say: I anticipate it will take a lot of time with this proposal bikeshedding exactly what the behaviour is in all cases. One thing we can do: in the spec we have all these JSON objects that specify locale data, one way we could go about specifying this is “define by what’s in this JSON object”, just paste it into the spec and that’s how we go about it. There’ll be bikeshedding on this, but I think it’s a good use of our time to do that, because there are real problems that this is solving. EAO: “und” locale has defined behaviour for Java’s formatters, for example, and if we were to specify the behaviour of “und” we would likely in one way or another define it differently than Java and CLDR. I prefer, myself, “zxx” @@ -125,15 +125,15 @@ YSZ: I think my comment would be with SFC, but one thing I’d like to mention t I think I’ve observed Intl.NumberFormat in chart applications that only use it for grouping / formatting with en_US, I think this is why this proposal is important, this en_US is not an intentional use, this is just using Intl.NumberFormat as a nice number formatter, I think this proposal is very important for this area. -FYT: I have a hard time imagining how the result of the spec is going to be used by the user, seems like we’re encouraging users to use it for something that’s not human-readable, is that correct? It’s more for machine exchange. I hesitate with that movement, we’re designed for human-readable output. The real issue is that there’s already a way to do that in Date. We have a toString(), the problem is that toString() doesn’t take the same options that toLocaleString() takes. What EAO is talking about is true, it’s not because toLocaleString() can’t handle it. In this proposal we’re using a locale for a purpose that’s not a locale. Concerned about that. Second thing is that I have a hard time envisioning what the end result would be for the spec for a collator, for example. Are we going to define exactly how collators work in this locale if we’re going to do this? One reason why we have implementation-defined behavior is that we’re trying to delegate that part to CLDR, if this proposal goes through we’re doing the work that we’d otherwise try to delegate, it’s a huge amount of work to write that spec and I have a hard time envisioning what it might look like and how many tests we need to add for the benefit, which is I personally feel pretty limited. +FYT: I have a hard time imagining how the result of the spec is going to be used by the user, seems like we’re encouraging users to use it for something that’s not human-readable, is that correct? It’s more for machine exchange. I hesitate with that movement, we’re designed for human-readable output. The real issue is that there’s already a way to do that in Date. We have a toString(), the problem is that toString() doesn’t take the same options that toLocaleString() takes. What EAO is talking about is true, it’s not because toLocaleString() can’t handle it. In this proposal we’re using a locale for a purpose that’s not a locale. Concerned about that. Second thing is that I have a hard time envisioning what the end result would be for the spec for a collator, for example. Are we going to define exactly how collators work in this locale if we’re going to do this? One reason why we have implementation-defined behavior is that we’re trying to delegate that part to CLDR, if this proposal goes through we’re doing the work that we’d otherwise try to delegate, it’s a huge amount of work to write that spec and I have a hard time envisioning what it might look like and how many tests we need to add for the benefit, which is I personally feel pretty limited. -JGT: This seems like a good idea – I assume the main goal is avoiding having people use ‘en’ for things that they’re not supposed to use it for. If we scope it down to that, that’s fine. This seems like a reasonable way to point people in every stackoverflow case where they say “use swedish” or “use english”, we can say “use this”. Avoids people doing weird things. +JGT: This seems like a good idea – I assume the main goal is avoiding having people use ‘en’ for things that they’re not supposed to use it for. If we scope it down to that, that’s fine. This seems like a reasonable way to point people in every stackoverflow case where they say “use swedish” or “use english”, we can say “use this”. Avoids people doing weird things. I strongly prefer “zxx” because “und” has previously understood behaviour, starting with something new gives less risk that things will break in some way, less of a challenge to deal with extant CLDR behaviour. For DateTime and Duration, one thing we could do is use the toString() for various things from Temporal. There already is an ISO 8601-based toString() output, and I think most of the options available for formatting are available in toString(). We could actually use the toString() methods of the various Temporal types. That might be a way to reduce the scope of this, make it easier to implement. I think a good general principle to follow is deliberately pick formats that do not evoke differences across cultures. For numeric format, for example, not to support separators or only support the ECMAScript _ separator. Final thing, for the equivalent things in calendars and timezones, there’s a precedence in ECMA-262 for these, and a question for the group is that if we precisely specify this does that mean that toLocaleString() for the locale is specified in 262, as the toString() of the ISO calendar and the UTC timezone? SFC: We’ve got some good feedback for this, we should focus on whether this needs to be moved to stage 1, and then continue discussing these very good points. -EAO: I was going to point out that the thing I’m going to be asking for, if it’s okay with you guys, is stage 1, to say “this problem has a solution” rather than “this is the right solution.” I don’t know if it makes sense to define this for all formatters, if it might make sense to solve this in a different way, these are stage 1 questions that I’d be interested in talking with you about. +EAO: I was going to point out that the thing I’m going to be asking for, if it’s okay with you guys, is stage 1, to say “this problem has a solution” rather than “this is the right solution.” I don’t know if it makes sense to define this for all formatters, if it might make sense to solve this in a different way, these are stage 1 questions that I’d be interested in talking with you about. EAO: A second question is that I don't know what I should name this PR. Right now it is named "root locale" but I could instead name it "null locale". @@ -147,23 +147,23 @@ RGN: +1 ZB: Yeah, I think I struggle with the motivation being intl -JGT: About the proposal name, I strongly agree that “root locale” is a bad name, because this has precedence in CLDR and we want to make sure we’re not confused with this. I don’t like “null” because it’s reminiscent of the null keyword. Generic locale, neutral locale, something along those lines. Also fine with SFC’s idea to punt on the name. +JGT: About the proposal name, I strongly agree that “root locale” is a bad name, because this has precedence in CLDR and we want to make sure we’re not confused with this. I don’t like “null” because it’s reminiscent of the null keyword. Generic locale, neutral locale, something along those lines. Also fine with SFC’s idea to punt on the name. EAO: I sense this as having an Intl motivation because there is an existing reality of Intl formatters being misused and abused. ZB: By solving it as an Intl proposal, we're making it harder to motivate as a potential non-Intl proposal. -EAO: Ignore what’s said at this meeting and address it directly at TG1? +EAO: Ignore what’s said at this meeting and address it directly at TG1? -ZB: Come to it and say “we’re doing this in ECMA-402, but the solution exist beyond 402” +ZB: Come to it and say “we’re doing this in ECMA-402, but the solution exist beyond 402” -EAO: I like SFC’s name suggestion, because it addresses what it’s for, the motivation. Is everyone okay with “Stable formatter”, with the understanding that the solution might be found outside of Intl. +EAO: I like SFC’s name suggestion, because it addresses what it’s for, the motivation. Is everyone okay with “Stable formatter”, with the understanding that the solution might be found outside of Intl. -FYT: I strongly agree with ZB's concern. First of all, you need to look at this issue from two points of view. There's a formatting issue, and there's the abuse issue. Let's talk about sorting. 262 defines sorting as plain lexicographic sorting. Same thing, formatting, that’s not a locale operation, that’s a formatting operation for an ISO spec. The issue that 262’s lack of certain functionality to address that non-locale usage of formatting, something that shouldn’t be a localization thing, because they’re not providing it and 402 is providing it, that causes the misuse. The root of the issue is the lack of functionality in 262, not the fact that we have functionality. If it’s not in 262, the abuse usage will increase. This has to be in 262 – we have toString(), we have number toString(), but they don’t have anything to control anything else. The real solution should come from addressing 262’s lack of functionality, not for 402 to do the correct internationalization thing for non-locale function. I think this proposal will increase our API misusage. +FYT: I strongly agree with ZB's concern. First of all, you need to look at this issue from two points of view. There's a formatting issue, and there's the abuse issue. Let's talk about sorting. 262 defines sorting as plain lexicographic sorting. Same thing, formatting, that’s not a locale operation, that’s a formatting operation for an ISO spec. The issue that 262’s lack of certain functionality to address that non-locale usage of formatting, something that shouldn’t be a localization thing, because they’re not providing it and 402 is providing it, that causes the misuse. The root of the issue is the lack of functionality in 262, not the fact that we have functionality. If it’s not in 262, the abuse usage will increase. This has to be in 262 – we have toString(), we have number toString(), but they don’t have anything to control anything else. The real solution should come from addressing 262’s lack of functionality, not for 402 to do the correct internationalization thing for non-locale function. I think this proposal will increase our API misusage. SFC: We don’t even need to approve EAO bringing it to TG1 as a proposal called Stable Formatting or whatever he wants to call it, I think EAO should bring it for there, there are interesting questions about where this gets specified and how it works, those can be handled at Stage 1, I think most people here are aligned in terms of the motivation. On the one hand, Intl APIs don’t give us a way to get stable results, but also 262 doesn’t have the formatting functionality needed. I think we should rename it Stable Formatting, no Intl in the name to avoid bikeshedding about that. -FYT: I really don’t want to connect this to 402, I think it’s unrelated. +FYT: I really don’t want to connect this to 402, I think it’s unrelated. SFC: My proposal is that we name it “Stable Formatting” and list out the motivation, leave the question about the relation to 402 as an open question to explore in stage 1 @@ -171,15 +171,15 @@ FYT: but I also don’t want to connect it to formatter. Let me put it this way SFC: do you have a proposal for the name? -FYT: Stable Formatting is fine. We don’t have formatter in 262. +FYT: Stable Formatting is fine. We don’t have formatter in 262. EAO: “Stable Formatting” sounds like a great name. -SFC: We’ll answer questions about the state of the proposal, the impact/non impact of 402, at stage 1. I haven’t been commenting on the collator formatting problem, but I think we should state that the motivation is clear, the problem may not look the same for all the Intl objects. The goal might not to have a stable formatting for all Intl objects, perhaps Collator should be out of scope. We can answer that at stage 1. +SFC: We’ll answer questions about the state of the proposal, the impact/non impact of 402, at stage 1. I haven’t been commenting on the collator formatting problem, but I think we should state that the motivation is clear, the problem may not look the same for all the Intl objects. The goal might not to have a stable formatting for all Intl objects, perhaps Collator should be out of scope. We can answer that at stage 1. -YSZ: I support. This has enough strong motivation. I think that FYT’s comment is good: we need to consider taking this out of Intl. But as a motivation, I support it. +YSZ: I support. This has enough strong motivation. I think that FYT’s comment is good: we need to consider taking this out of Intl. But as a motivation, I support it. -ZB: I just want to say, SFC, I think what you’re saying is not misaligned with what FYT and I are talking about. If ECMA-262 had a problem with abuse of APIs that should be in Intl, they would bring it up as a problem and ask ECMA-402 to solve it. I think what we could do is bring the problem and ask 262 to evaluate the solution, rather than bring up to TG1 that we found a problem and we are solving it. The problem-bringer and the solution-deliverer might be two different bodies, and I want to preserve that possibility as we present it to TG1. I think it’s unique for 402 proposals. It’s like when we needed a new type of iterator or map or set, we could have this problem but expect TG1 to evaluate the solution, which may not be inside 402. +ZB: I just want to say, SFC, I think what you’re saying is not misaligned with what FYT and I are talking about. If ECMA-262 had a problem with abuse of APIs that should be in Intl, they would bring it up as a problem and ask ECMA-402 to solve it. I think what we could do is bring the problem and ask 262 to evaluate the solution, rather than bring up to TG1 that we found a problem and we are solving it. The problem-bringer and the solution-deliverer might be two different bodies, and I want to preserve that possibility as we present it to TG1. I think it’s unique for 402 proposals. It’s like when we needed a new type of iterator or map or set, we could have this problem but expect TG1 to evaluate the solution, which may not be inside 402. ZB: (in chat) yeah, I think I struggle with the motivation being intl. I think the problem is in intl, because we do not have an API that addresses the need, but the solution may, and I suspect should, live outside of Intl. and the problem of what is the locale we should use here is caused by the fact tht this is not locale related. bending backwards to come up with a non-locale-locale to supply this is imho leaking that we're trying to use a hammer @@ -187,7 +187,7 @@ LAF: TG1 "Stable format" for discussion +1. +1 "Stable formatting". SFC: I think you’re good to move forward to stage 1, given all the caveats that I believe you acknowledged. -EAO: I’ll refactor the text and ping you when it’s ready. Not going to hold off on getting PR approval, I think I have what we need to present in Tokyo. It also sounds like I may need to ask for more time than I asked for, given the length of this discussion. +EAO: I’ll refactor the text and ping you when it’s ready. Not going to hold off on getting PR approval, I think I have what we need to present in Tokyo. It also sounds like I may need to ask for more time than I asked for, given the length of this discussion. ### Intl.MessageFormat Stage 1 Update @@ -196,25 +196,25 @@ EAO: I’ll refactor the text and ping you when it’s ready. Not going to hold - MFWG Spec: https://github.com/unicode-org/message-format-wg/tree/main/spec - Presentation: https://docs.google.com/presentation/d/15lwZipk0k5pMscSBbEPpMySsnM_qd4MOo_NqmmKyS-Q/edit?usp=sharing -EAO: I have a couple of API design questions that the proposal currently has answers for, but I’m interested in getting help in getting the spec text written. The proposal is currently proposing to create a new Intl.MessageFormat object that has [interface shown in slides]. This has a required first argument that gives the source of the message being formatted, has formatToParts like the other ones, and resolvedOptions. The message resource stuff has been taken out of the proposal, so this is now for just one message. The API as a whole has changed, there’s a more normal .format() and .formatToParts() method attached here. This is related to the API questions I have going on, which is describing how the values are coming in, what’s happening to them in Intl.MessageFormat, and how they’re coming out (i.e. parts instead of string). There’s updates for MessageFormatv2: the message data structure is well defined in the spec, there’s JSON we can use as an input method. Second is that the bidirectional isolation / concerns around those issues need to have a corresponding implementation here. Not related directly to the changes in the MessageFormatv2 spec, is that the error behaviour has been specified so that the default for errors would be to emit warnings rather than throw errors. formatToParts() and format() have parameters related to this. +EAO: I have a couple of API design questions that the proposal currently has answers for, but I’m interested in getting help in getting the spec text written. The proposal is currently proposing to create a new Intl.MessageFormat object that has [interface shown in slides]. This has a required first argument that gives the source of the message being formatted, has formatToParts like the other ones, and resolvedOptions. The message resource stuff has been taken out of the proposal, so this is now for just one message. The API as a whole has changed, there’s a more normal .format() and .formatToParts() method attached here. This is related to the API questions I have going on, which is describing how the values are coming in, what’s happening to them in Intl.MessageFormat, and how they’re coming out (i.e. parts instead of string). There’s updates for MessageFormatv2: the message data structure is well defined in the spec, there’s JSON we can use as an input method. Second is that the bidirectional isolation / concerns around those issues need to have a corresponding implementation here. Not related directly to the changes in the MessageFormatv2 spec, is that the error behaviour has been specified so that the default for errors would be to emit warnings rather than throw errors. formatToParts() and format() have parameters related to this. Here’s what it looks like: you need a source, we feed it to Intl.MessageFormat along with a locale, first argument is a set of values / mapping of values that can be used there, formatToParts() similar to how other formatToParts() work. We see a little more of what MessageFormatv2 is capable of. Selectors: messages that have more than one variant that depend on the plurality, or the count, or other factors. The message may have these internal variables that are defined and then reused across the message. The questions I have on this is how do we format compound values? Values that like a number together with a currency code that should be kept together rather than separate. In NumberFormat, since it’s directly calling, we could have the currency code as the option. In MessageFormat, where you have these messages that could be changed with translators while working on it, that gets tricky. MessageFormat has internal functions that deal with inputs, they end up calling internally the other formatters (NumberFormat, DateTimeFormat) and they support similar options bags. One API decision: is using something like a valueOf the right thing to do? -The second question is how do we format to parts? There are parts that themselves have parts, and we have values that need to go into the parts but that aren’t strings. All the values in the current objects are strings, that’s not going to work in MessageFormatv2 because those values could be anything. The current answer is that each of the formatted parts can have a unitary value or an array of parts as their effective value. The literal part has a value, the value itself has parts coming from NumberFormat. Another part is that the values may be non-strings (though not for the default stuff) but it’s possible for a user to define a custom function like “image” here, and use it in an expression that does something to all of “cow.png” (on slides). +The second question is how do we format to parts? There are parts that themselves have parts, and we have values that need to go into the parts but that aren’t strings. All the values in the current objects are strings, that’s not going to work in MessageFormatv2 because those values could be anything. The current answer is that each of the formatted parts can have a unitary value or an array of parts as their effective value. The literal part has a value, the value itself has parts coming from NumberFormat. Another part is that the values may be non-strings (though not for the default stuff) but it’s possible for a user to define a custom function like “image” here, and use it in an expression that does something to all of “cow.png” (on slides). This is different from how formatToParts work currently, but it seems like the least-worst option, and might even be a good one. A question I’m presenting here and at TG1 is “are these good choices?” EAO: Further, what’s going on in the middle? How do we define this sort of customization, i particular as the value of a custom formatter can be used in a variety of ways in MessageFormat. The message value here is not a complete class, it’s an interface that the output of these message functions are required to take. If you want to use it as a selector, you have to add a select() message for that. -EAO: Because these are being used as inputs for other formatting functions, they need to have the same shape as a compound value input, so there’s a little bit of an interplay and a place to ask questions, because right now message value has the same valueOf, both of these can be changed one way or another, instead of having an options value we could have a resolvedOptions() method, and instead of having value, we could have a valueOf() method. +EAO: Because these are being used as inputs for other formatting functions, they need to have the same shape as a compound value input, so there’s a little bit of an interplay and a place to ask questions, because right now message value has the same valueOf, both of these can be changed one way or another, instead of having an options value we could have a resolvedOptions() method, and instead of having value, we could have a valueOf() method. -The request I have is that I would appreciate a lot of help with this. The API looks small, but goes in deep and has all these complexities that users don’t have to worry about, but users still need to be able to work with it. +The request I have is that I would appreciate a lot of help with this. The API looks small, but goes in deep and has all these complexities that users don’t have to worry about, but users still need to be able to work with it. -FYT: Two comments: I prefer the arguments in the constructor be consistent with other 402 constructors, second is that the locale should be a list of locales rather than a single one to align with other objects. +FYT: Two comments: I prefer the arguments in the constructor be consistent with other 402 constructors, second is that the locale should be a list of locales rather than a single one to align with other objects. -EAO: The problem with accepting locales as the first argument for the constructor is that it is not a required argument, whereas “source” is a required argument. +EAO: The problem with accepting locales as the first argument for the constructor is that it is not a required argument, whereas “source” is a required argument. -SFC: We don’t have time, unfortunately, in this meeting to get into the weeds. The only thing we should do right now is identify areas for discussion. Shu-Yu arranges these calls, they can address them, or we can address them at future TG2 meetings. +SFC: We don’t have time, unfortunately, in this meeting to get into the weeds. The only thing we should do right now is identify areas for discussion. Shu-Yu arranges these calls, they can address them, or we can address them at future TG2 meetings. RGN: I wanted to highlight that this isn’t the first instance where the output of formatToParts itself has structure. I’m thinking especially of formatRangeToParts, where we kept the output as a flat array with a source property identifying what they’re part of. That’s my sense here – it’s not firm, but we do have prior art. @@ -230,11 +230,11 @@ $ node -p 'new Intl.NumberFormat("en", {notation:"engineering"}).formatRangeToPa ``` -EAO: One aspect here is that there’s two levels of source. +EAO: One aspect here is that there’s two levels of source. -SFC: I believe that most of these problems that EAO has pulled out are solvable, but we just need to hammering out details. If there are concerns about going this direction we should bring them up now so that we don’t do all that work and then having proposals blocked later. +SFC: I believe that most of these problems that EAO has pulled out are solvable, but we just need to hammering out details. If there are concerns about going this direction we should bring them up now so that we don’t do all that work and then having proposals blocked later. -SFC: If there are no concerns, this seems good, I’m happy with the general direction you’ve shown, I think we should convene a smaller group of people who can go in deep, I think an incubator call is the way to do it (RGN, SFC, ZB, BAN?) to dive into the details? This is probably the biggest, most exciting proposal we’ve seen in this group since it was formed. This is an excited proposal, I’m guessing there’s a number of people who would be excited to be in the loop on this one. +SFC: If there are no concerns, this seems good, I’m happy with the general direction you’ve shown, I think we should convene a smaller group of people who can go in deep, I think an incubator call is the way to do it (RGN, SFC, ZB, BAN?) to dive into the details? This is probably the biggest, most exciting proposal we’ve seen in this group since it was formed. This is an excited proposal, I’m guessing there’s a number of people who would be excited to be in the loop on this one. ### Normative: Added note about sets of locales for web browser implementations needing to not change as a result of user behaviour #780 @@ -266,15 +266,15 @@ SFC: Bringing us up to speed, because we’ve discussed this multiple times. We JGT: As a result of the feedback from this group, we have reduced the precision of offset time zones to the minute. There were some concerns about iCalendar supporting down to the seconds, but from research it appears iCalendar does not actually use seconds for anything but custom time zones. System time zones are all in minutes precision. -I think at this point all the major open issues are resolved with the precision thing. +I think at this point all the major open issues are resolved with the precision thing. -SFC: Going back to the PR, it looks like this is still based on offset nanoseconds, I believe we should update this to only allow minutes and greater as part of the offset timezone. If we get an offset time zone it looks at nanoseconds, then pieces together the offset time zone with ASCII characters. So then the goal here is to say that this is limited to minutes precision. +SFC: Going back to the PR, it looks like this is still based on offset nanoseconds, I believe we should update this to only allow minutes and greater as part of the offset timezone. If we get an offset time zone it looks at nanoseconds, then pieces together the offset time zone with ASCII characters. So then the goal here is to say that this is limited to minutes precision. SFC: I have another question: Do we have support for the localized formatting of offset timezones. I think we already have that, like, GMT-5, we could format offset time zones with that formatter. RGN: We could, but I don’t think we should conflate the offset timezones with named GMT timezones. -SFC: The named GMT timezones are just one of the format options. +SFC: The named GMT timezones are just one of the format options. LAF: In real life all the time zones, like Paris for example, is defined to precision for seconds. I don’t think it makes sense to define them to nanoseconds, I’m not sure this is something that you can compute, but for seconds I think it is. This is what I wanted to say from the point of view of the user. Today it is the case that if you try to output to display a date before 1900, you have an offset of nine minutes, 21 seconds. And when you take the function timezoneOffset(), you get only nine minutes and not the 21 seconds. When I try to make an application for this, I have to compute the real timezone offset – I’d rather be getting this from the standards. If there’s already precision to the second in CLDR, it’d be nice to get that from the function. @@ -284,7 +284,7 @@ LFS: In terms of the use cases it’s only if you deal with historical data. I JGT: So if you want to create your own custom timezone you can still go down to the nanoseconds level. This is solely about string parsing and string formatting for built-in timezones. If I have a built-in timezone like Europe/Paris, whatever resolution is there we can format and part. The only limitation is on offset timezones (formatting in 402, parsing in Temporal). As far as we know there are no use cases for those offset timezones. But if you want to create your own – so say a village in France had its own idea of noon – you create your own custom calendar. I think the use case you’re talking about is already solved, and not covered by this PR. -LFS: All I’m saying is that before the 20th century, the computation you have shows that the timezone offset is in minutes and seconds, which is just what I wanted to say. It would be nice for users if you use a function like timezoneOffset() to get the complete picture. Today the behaviour is different in Chromium and Firefox, as far as I understand. In one of them, you get the minutes, in the other, you get minutes and seconds. +LFS: All I’m saying is that before the 20th century, the computation you have shows that the timezone offset is in minutes and seconds, which is just what I wanted to say. It would be nice for users if you use a function like timezoneOffset() to get the complete picture. Today the behaviour is different in Chromium and Firefox, as far as I understand. In one of them, you get the minutes, in the other, you get minutes and seconds. JGT: That sounds like a bug, and if it’s inconsistent across browsers I’d say take a look at the spec, see which one matches the spec, and file a bug in the other one. @@ -294,13 +294,13 @@ RGN: What are you looking for that you don’t see? SFC: It’s still talking about nanoseconds -RGN: But it’s using an ECMA-402 operation to get nanoseconds, it’s not built in. We can impose that restriction in 402, but that would be somewhat pointless given that Temporal is modifying the very operation that this one uses, that is inside 262. +RGN: But it’s using an ECMA-402 operation to get nanoseconds, it’s not built in. We can impose that restriction in 402, but that would be somewhat pointless given that Temporal is modifying the very operation that this one uses, that is inside 262. SFC: We’re calling the operation parseTimeZoneOffsetString(), which already exists and already returns nanoseconds? RGN: Yes. -FYT: In the PR you have to format the second part, line 162. +FYT: In the PR you have to format the second part, line 162. RGN: I can take that on no problem, I’ll replace it with assertions. Now, parseTimeZoneOffsetString() in 262 might actually support nanoseconds precision. @@ -308,25 +308,25 @@ JGT: If I recall correctly that AO is used to parse all offsets, and can be used FYT: I think the issue is that the AO timeZoneOffsetString() formats to second, the consequences is that the AO is oging to generate the offset with the seconds part, meaning it still needs to be updated. -RGN: The problem is that there’s this discontinuity between 262 and 402. [method] is allowed to return a named timezone or an offset from a timezone, and 402 relies on that – but has no way to process an offset that’s not a named timezone. Temporal has decided (this is using the 262 operations, because I can’t have the 402 spec point into a proposal) but I can copy whatever parts into it that this group would consider necessary to proceed. But the situation we’re in right now is untenable. +RGN: The problem is that there’s this discontinuity between 262 and 402. [method] is allowed to return a named timezone or an offset from a timezone, and 402 relies on that – but has no way to process an offset that’s not a named timezone. Temporal has decided (this is using the 262 operations, because I can’t have the 402 spec point into a proposal) but I can copy whatever parts into it that this group would consider necessary to proceed. But the situation we’re in right now is untenable. SFC: It’s not immediately clear – it looks like this AO timeZoneOffsetString() is not used for user-visible output. And we still use the same formatting codepath that we do for everything else. Does that formatting codepath allow the use of short offsets and long offsets, the names of the timezone name field. -RGN: That’s going to be the DateTimeFormatFunctions: FormatDateTime, etc. I believe the answer is yes, but the details are probably relevant. +RGN: That’s going to be the DateTimeFormatFunctions: FormatDateTime, etc. I believe the answer is yes, but the details are probably relevant. SFC: I think this is approvable given two changes: we should make an assertion so that we’re very clear about exactly what the precision is of these offset timezones, we should change that to an assertion, and something I should have raised earlier is that formatting with timeZoneName works as expected? -RGN: It looks like that is implementation-defined behavior. We get a string value representing a timezone in the form returned by timeZoneName(), if the implementation doesn’t have that timezone it can just use the string itself, so it’s easy for the operation to do the right thing when it receives a timezone. +RGN: It looks like that is implementation-defined behavior. We get a string value representing a timezone in the form returned by timeZoneName(), if the implementation doesn’t have that timezone it can just use the string itself, so it’s easy for the operation to do the right thing when it receives a timezone. -SFC: That sounds fine to me. With that I think this is approvable and we can bring it to TG1. +SFC: That sounds fine to me. With that I think this is approvable and we can bring it to TG1. -JGT: The only thing work checking out is whether ICU and CLDR are capable of displaying the full range of offset timezone. I think there’ll need to be some changes, but it’ll be nice to know how deep the changes need to be: JS engines, ICU, even CLDR itself? It would be useful not for whether we approve this PR and instead just to set peoples’ expectations. +JGT: The only thing work checking out is whether ICU and CLDR are capable of displaying the full range of offset timezone. I think there’ll need to be some changes, but it’ll be nice to know how deep the changes need to be: JS engines, ICU, even CLDR itself? It would be useful not for whether we approve this PR and instead just to set peoples’ expectations. FYT: I’m still confused about what RGN said about adding an assertion. Calling [two AOs] from 262, and both of those are dealing with precisions lower than minutes. RGN: in the call to ParseTimeZoneOffsetString, I’ll put in a constraint – copied from Temporal – about rejecting anything with sub-minute precision, guaranteeing that all the subsequent steps don’t have sub-minute precision. ParseOffsetTimeZoneString is going to come back, and if it proposes sub-minute precisions, we encounter an exceptional case, which here is going to be a RangeError, like if you present a name that’s not known to the system. Only accept an offset timezone if it doesn’t have sub-minute precision. -SFC: I’m not hearing any other concerns from this group, we’ve addressed the questions, we need to see the updated PR but I think we can do it in the context of TG1. I think we should update this PR and review it and approve it in the context of TG1. +SFC: I’m not hearing any other concerns from this group, we’ve addressed the questions, we need to see the updated PR but I think we can do it in the context of TG1. I think we should update this PR and review it and approve it in the context of TG1. FYT: Yes, I'd like to see the updated PR before TG1. @@ -340,7 +340,7 @@ Tentatively approved, pending updated spec text. https://blog.unicode.org/2023/08/unicode-technology-workshop-call-for.html -SFC: This is going to be the first major in-person event since IUC, which was two years ago. So the UTW is going to take place November 7th and 8th in Sunnyvale, CA. I’m going to be there to give some ECMAScript updates, but I’d love to see some of you here – it’s sort of the internationalization conference, even though it’s not called a conference. I’d also like to host a hybrid TG2 call that week. We haven’t had a hybrid call since 2020, so I’d love to if there are some folks coming into town I’d like to get people together so we could have a hybrid TG2 call. If you are able to make it I’d love to see you there. We’ll be informing accepted speakers in a few weeks’ time. +SFC: This is going to be the first major in-person event since IUC, which was two years ago. So the UTW is going to take place November 7th and 8th in Sunnyvale, CA. I’m going to be there to give some ECMAScript updates, but I’d love to see some of you here – it’s sort of the internationalization conference, even though it’s not called a conference. I’d also like to host a hybrid TG2 call that week. We haven’t had a hybrid call since 2020, so I’d love to if there are some folks coming into town I’d like to get people together so we could have a hybrid TG2 call. If you are able to make it I’d love to see you there. We’ll be informing accepted speakers in a few weeks’ time. ### Possible forward-compatibility issue in Intl.Locale.prototype.getTimeZones()? #73 @@ -350,23 +350,23 @@ FYT: We have a naming issue with this one. What Anba is interested in is that we FYT: I will look to see if we have a group decision to say “don’t change name” or “change name” for timezone and calendar -SFC: And if we change it for one we should change it for the other, I think Anba’s point is good. One issue is that we already have a getter on Intl.Locale called timezone, but not one called calendar. +SFC: And if we change it for one we should change it for the other, I think Anba’s point is good. One issue is that we already have a getter on Intl.Locale called timezone, but not one called calendar. -FYT: And changing that would be painful, are we going to obsolete the old one? +FYT: And changing that would be painful, are we going to obsolete the old one? -JGT: I’m just thinking, already across Intl we call this TimeZone and Calendar, it sounds like this is really a question of whether we want Intl.Locale to align with other Intl APIs or with Temporal. +JGT: I’m just thinking, already across Intl we call this TimeZone and Calendar, it sounds like this is really a question of whether we want Intl.Locale to align with other Intl APIs or with Temporal. RGN: Given the detail with calendar pre-existing, I have a slight preference to just call it timeZones here and not introduce the IDs concept. It lets the 402 APIs be internally consistent rather than partially aligned with Temporal and partially not. JGT: I agree. Also, if we ever support something like usnyc, we should use very different names. -RGN: I entirely agree, we’re going to ensure that there’s guaranteed no collision and no introduction of ambiguity. +RGN: I entirely agree, we’re going to ensure that there’s guaranteed no collision and no introduction of ambiguity. SFC: I agree. FYT: Does anyone object to keeping `getTimeZones()` and `getCalendars()` ? -SFC: I think after weighing all the pros and cons I’m back to the position that we should leave it unchanged. +SFC: I think after weighing all the pros and cons I’m back to the position that we should leave it unchanged. #### Conclusion @@ -376,29 +376,29 @@ Close the issue. https://github.com/tc39/proposal-intl-locale-info/issues/71 -FYT: What happens currently is if getTimeZones() we have this Intl.Locale, and it really is the object way to represent a string form, in a sense, and then we try to get the properties for that. So whenever a certain field – the region field, say – is constructed without that part, we consider it as undefined (i.e. we don’t know what the region is). Anba suggests that if we call getTimeZone(), we maximize it and try to derive the getTimeZone() value. His argument is that that’s what used in getWeekInfo() and getHourCycle(). I think currently we through an error whenever getTimeZone() is called and we don’t have the region call. +FYT: What happens currently is if getTimeZones() we have this Intl.Locale, and it really is the object way to represent a string form, in a sense, and then we try to get the properties for that. So whenever a certain field – the region field, say – is constructed without that part, we consider it as undefined (i.e. we don’t know what the region is). Anba suggests that if we call getTimeZone(), we maximize it and try to derive the getTimeZone() value. His argument is that that’s what used in getWeekInfo() and getHourCycle(). I think currently we through an error whenever getTimeZone() is called and we don’t have the region call. SFC: One thought I’ve had here is that if the region is not explicitly specified, it could be the case that we return UTC as the timezone. That being said, I think there’s a lot of people using ‘en-US’ who would get America/New York anyway, and if you’re using ‘en’ instead we could try to be more friendly and use UTC instead, because this is a case where adding in the region can cause confusion to users. FYT: I misspoke: we don’t throw, we currently return undefined. So what you’re suggesting is that instead of returning undefined, we return UTC. -SFC: Yes, just as a special case for timezone. +SFC: Yes, just as a special case for timezone. -FYT: I think that makes sense. The return value is an array, we currently return undefined. What you say makes sense, if the region is unknown we return a single-element array that has UTC. SFC has that suggestion, anyone want to second? I still need to make a change, but we’re changing it toward that one. +FYT: I think that makes sense. The return value is an array, we currently return undefined. What you say makes sense, if the region is unknown we return a single-element array that has UTC. SFC has that suggestion, anyone want to second? I still need to make a change, but we’re changing it toward that one. EAO: +1 to UTC SFC: I think this is probably good, JGT? -JGT: I admit I don’t understand, because I’m unfamiliar with locales and regions. +JGT: I admit I don’t understand, because I’m unfamiliar with locales and regions. SFC: (will post code on the issue) -So what happens if you don’t have a region subtag? Currently it returns undefined, Anba is suggesting we guess, I’m a little opposed to that. SFC suggests/I agree that we should return a single-element array with UTC. +So what happens if you don’t have a region subtag? Currently it returns undefined, Anba is suggesting we guess, I’m a little opposed to that. SFC suggests/I agree that we should return a single-element array with UTC. JGT: I like this, because UTC is not the timezone of any human on the planet, unless they’ve been uploaded to an AWS server. -SFC: I think an advantage of the single-element array: if you’re expecting the return value to be an array of strings but something else, the definition has to be updated, etc. etc., I think it’s cleaner to have a single-element array to keep the types cleaner. +SFC: I think an advantage of the single-element array: if you’re expecting the return value to be an array of strings but something else, the definition has to be updated, etc. etc., I think it’s cleaner to have a single-element array to keep the types cleaner. JGT: Could we have an empty array? What you don’t want is to have code that says “let’s go format the time for this locale,” and we’re guaranteed that UTC is going to be wrong for everyone. @@ -412,13 +412,13 @@ SFC: My point is that if any of this code is assuming it’s getting an array, w JGT: I’m fine with leaving it undefined, I don’t have a strong opinion for undefined vs. empty array, slight preference for undefined, I just don’t like “UTC” -SFC: I think it’s a big footgun to return the likely subtag, the suggestion for UTC is fine but maybe it’s better to surface this to the user instead of filling in UTC, returning undefined seems like a fine way to surface this for the user. +SFC: I think it’s a big footgun to return the likely subtag, the suggestion for UTC is fine but maybe it’s better to surface this to the user instead of filling in UTC, returning undefined seems like a fine way to surface this for the user. JGT: We don’t fix anything. SFC: You had previously +1ed UTC, how do you feel? -EAO: I don’t feel strongly either way. +EAO: I don’t feel strongly either way. LAF: +1 to undefined @@ -434,14 +434,14 @@ The following items were discussed after the end of the official time slot. https://github.com/tc39/proposal-intl-locale-info/issues/68 -FYT: The issue is that there’s multiple ways to represent a day of the week (three-letter string, 0-6, 1-7). The question then is what should we accept from the read option, and what is the result option to be? +FYT: The issue is that there’s multiple ways to represent a day of the week (three-letter string, 0-6, 1-7). The question then is what should we accept from the read option, and what is the result option to be? -SFC: We broached this with TG1, they said that they just don’t like the idea of adding another representation for day of the week, that’s my understanding of the July discussion on this topic? +SFC: We broached this with TG1, they said that they just don’t like the idea of adding another representation for day of the week, that’s my understanding of the July discussion on this topic? -FYT: wait, it’s not resolvedOptions(), I take it back, it’s the getter. +FYT: wait, it’s not resolvedOptions(), I take it back, it’s the getter. -SFC: TG1 would like us to return the number values, when we went to TG1 we returned the BCP 47 strings, but TG1 wants us to return numbers. So the question is what do we accept? The BCP 47 strings, just the numbers? And if we accept the numbers, what do we do with 0? I think we should cut this down to two choices: either be lenient with what we accept (strings and 0) or we should be strict. There’s no reason to be partially lenient. I think if we are lenient we should be fully lenient. +SFC: TG1 would like us to return the number values, when we went to TG1 we returned the BCP 47 strings, but TG1 wants us to return numbers. So the question is what do we accept? The BCP 47 strings, just the numbers? And if we accept the numbers, what do we do with 0? I think we should cut this down to two choices: either be lenient with what we accept (strings and 0) or we should be strict. There’s no reason to be partially lenient. I think if we are lenient we should be fully lenient. FYT: SFC is suggesting we ignore option A, B, E (reject some, accept others), but only look at C and D (fully lenient, fully strict). @@ -451,7 +451,7 @@ LAF: +1 for C JGT: +1 for C -SFC: I’ve gone back and forth on this, we’ve tended to be lenient lately. +SFC: I’ve gone back and forth on this, we’ve tended to be lenient lately. #### Conclusion diff --git a/meetings/notes-2023-10-12.md b/meetings/notes-2023-10-12.md index e644e4be..c50553bb 100644 --- a/meetings/notes-2023-10-12.md +++ b/meetings/notes-2023-10-12.md @@ -16,7 +16,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -29,11 +29,11 @@ RGN: Not many changes since last meeting, did land offset timezones, substantial ### Updates from the MessageFormat Working Group -EAO: Since the last TG2 call quite a bit has happened. First, soon after that four of us in the MessageFormat working group ended up meeting in person around TPAC, and spent a few days hammering out some of the details of the specification work that we still have. And that produced quite a few good results, and narrowed down many of the differences we had, for example we reached agreement on how mutability inside messages work. During TPAC we ended up talking with some of the people there and to reconsider what we were doing with the syntax, and so far we ended up settling that syntax should start in “code mode”, so that you need a sigil at the start of every single message indicating that what follows is pattern text. A hello world message would need to be {hello world}, and we’ve decided that this is not okay and that we should revisit this fundamental on what to do on this syntax, which opened up a whole can of worms that we’re figuring out. We’re running what Addison Philips, the chair, calls a “beauty contest.” I am optimistic that we can hopefully reach a conclusion-ish on Monday, and then refactor the syntax on pattern delimiting, for example. Once that hopefully is done there are only a few significant resolvable issues with MessageFormatV2. The greatest of those is what is the syntax of opening and closing of standalone elements, in our context something like HTML but not exactly HTML. This work is ongoing. +EAO: Since the last TG2 call quite a bit has happened. First, soon after that four of us in the MessageFormat working group ended up meeting in person around TPAC, and spent a few days hammering out some of the details of the specification work that we still have. And that produced quite a few good results, and narrowed down many of the differences we had, for example we reached agreement on how mutability inside messages work. During TPAC we ended up talking with some of the people there and to reconsider what we were doing with the syntax, and so far we ended up settling that syntax should start in “code mode”, so that you need a sigil at the start of every single message indicating that what follows is pattern text. A hello world message would need to be {hello world}, and we’ve decided that this is not okay and that we should revisit this fundamental on what to do on this syntax, which opened up a whole can of worms that we’re figuring out. We’re running what Addison Philips, the chair, calls a “beauty contest.” I am optimistic that we can hopefully reach a conclusion-ish on Monday, and then refactor the syntax on pattern delimiting, for example. Once that hopefully is done there are only a few significant resolvable issues with MessageFormatV2. The greatest of those is what is the syntax of opening and closing of standalone elements, in our context something like HTML but not exactly HTML. This work is ongoing. Beauty contest link: https://github.com/unicode-org/message-format-wg/issues/493 -Sort of related was the TC39 meeting in Toyko, where I presented on the MessageFormat API, and that one ended up with TG1 approving in general the direction of the proposal, but there is now also an incubator call that I’m hoping to get a scheduled time by the end of tomorrow at the latest. If you’re interested in MessageFormat, let me know so we can take that into account on scheduling. +Sort of related was the TC39 meeting in Toyko, where I presented on the MessageFormat API, and that one ended up with TG1 approving in general the direction of the proposal, but there is now also an incubator call that I’m hoping to get a scheduled time by the end of tomorrow at the latest. If you’re interested in MessageFormat, let me know so we can take that into account on scheduling. Incubator call link: https://github.com/tc39/Reflector/issues/508 @@ -53,11 +53,11 @@ SFC: Thank you for keeping up with this proposal, and the changes in DurationFor ### Updates from the W3C i18n Group -EAO: At TPAC there was a presentation from DE on the role of TC39, and about the overlap of what TC39 and W3C actors might be doing. The W3C I18N working group would very much welcome participation from people here, because there is such an overlap. +EAO: At TPAC there was a presentation from DE on the role of TC39, and about the overlap of what TC39 and W3C actors might be doing. The W3C I18N working group would very much welcome participation from people here, because there is such an overlap. SFC: I hope that establishing a liaison relationship will help us with this. We should also do a reverse update on what we do at TG2 to the W3C i18n working group. -EAO: I’ll talk about that with Addison and Richard. Highlight conversations here that you would like me to bring up at the W3C i18n working group. +EAO: I’ll talk about that with Addison and Richard. Highlight conversations here that you would like me to bring up at the W3C i18n working group. ## Proposals and Discussion Topics @@ -85,7 +85,7 @@ https://github.com/tc39/proposal-intl-locale-info/issues/78 FYT: In July I presented for Intl.Locale to add first day of week, and I initially proposed that we return it as a string (“mon” to “sun” or *undefined*). They aren’t happy with that, so we changed it to return 1 to 7 for that. Now the problem is that if – in the past, if someone in the locale id itself if you have something other than a string, you’ll have garbage in garbage out to return that string. If you have -u-fw-xyz, we can return xyz. But what happens when it’s not coming from the option bag – if it’s in the option bag, we reject it – but what if it’s in the locale string that adheres to the syntax but isn’t one of those specific values. What should we do? Throw error? Should we still take it but ignore it? In the constructor? Whatever we return from that one, what should the value be? *undefined*? It’s troublesome, because this breaks away with traditionally how we deal with the locale getter, which has been GIGO – whatever you put in that locale is what it returns. But this suggestion from TG1 changes that. -SFC: I listed some possibilities in the reply, and FYT added one more. The current behaviour is that if it’s not a valid BCP 47 id, we reject it. But what if it’s not valid? Most just return it to the user, but since we made a decision to return integers rather than strings, we have to make a decision on what to do here. These cases we should work out, but they probably have the same answer: what do you do when you either have options or a locale string that sets fw? +SFC: I listed some possibilities in the reply, and FYT added one more. The current behaviour is that if it’s not a valid BCP 47 id, we reject it. But what if it’s not valid? Most just return it to the user, but since we made a decision to return integers rather than strings, we have to make a decision on what to do here. These cases we should work out, but they probably have the same answer: what do you do when you either have options or a locale string that sets fw? FYT: Those two cases aren’t the same thing. In the option bag, it’s guaranteed to throw, in the second one there’s no spec that throws. @@ -101,23 +101,23 @@ SFC: Options we have for what to do here: 2. Constructor succeeds, getter echoes back the string if it is not one of the well-known strings that gets converted to an integer. 3. Constructor succeeds; getter returns the default first day of week for the locale as an integer if the string is not one of the well-known strings 4. Send it back to TG1 – this change doesn’t work for us. -5. Constructor succeeds: getter returns `undefined`. +5. Constructor succeeds: getter returns `undefined`. YSZ: One question: currently 1 to 7 and “mon” to “sun”, these same strings are accepted. In CLDR/ICU, is there any other thing that would change that behaviour, or is it kind of like a reasonable set of string features that won’t be changed in the future. Do you have any idea? SFC: I mean, there’s seven days of the week and most of the world agrees on that. It’s not something I anticipate changing, but I could even see us adopting at some point certain calendars that use a different structure (weekend on friday and sunday, something like that, a weekend that’s not contiguous). We might want to update fw to reflect that – it wouldn’t be out of the question for CLDR to use the existing keyword to reflect that somehow – I’m just speculating, don’t know if they would. -YSZ: Right now we’re anticipating that the currently accepted strings is a reasonable set for the foreseeable future, right? Because I’d like to know what happens if we accept random strings that are syntactically valid, and if this would change something / become supercritical. If the set of accepted strings is a reasonable set, we can just check. I feel like it’s fine to check it in the constructor or getter side, but anyway, it’s fine. +YSZ: Right now we’re anticipating that the currently accepted strings is a reasonable set for the foreseeable future, right? Because I’d like to know what happens if we accept random strings that are syntactically valid, and if this would change something / become supercritical. If the set of accepted strings is a reasonable set, we can just check. I feel like it’s fine to check it in the constructor or getter side, but anyway, it’s fine. EAO: 1>5>3>2>4 -SBE: The thing I'd take into consideration is which one gives a developer the most insight into what is going wrong? A few of those options don’t really let someone know until it’s presented to the user. I prefer option 1 for that reason, because there’s immediate insight that you’ve passed in something that’s not going to work. +SBE: The thing I'd take into consideration is which one gives a developer the most insight into what is going wrong? A few of those options don’t really let someone know until it’s presented to the user. I prefer option 1 for that reason, because there’s immediate insight that you’ve passed in something that’s not going to work. SFC: There’s not a huge difference between 1 and 5. Actually, what happens if the getter returns, if there’s no `fw` keyword in the locale does it return `undefined`? Because maybe it already returns *undefined*. FYT: Option 3 is unnecessary, because the [missed this]. In theory this getter should return whatever is represented by the locale itself, not whatever it resolves which is gotten from getWeekInfo. If you compare with any other property in there, the getter, they’re kind of reflecting whatever’s in the string id itself, and this breaks away from that. I think 3 is unnecessary, you could get that integer from getWeekInfo not first day of week. -EAO: Does anyone prefer some other choice than throwing over throwing? +EAO: Does anyone prefer some other choice than throwing over throwing? SFC: The pushback against throwing is that we don’t do it in other cases unless it’s syntactically invalid, and generally we err toward best fit behavior. @@ -129,7 +129,7 @@ FYT: One thing I want agreement on, if we don’t throw we still need to return EAO: My preference would be for throwing. It’s an edgy edge case, opinions here are not very strong. -SFC: Concrete proposal: return `undefined` in the getter, and `toString` retains the input string. Then the only thing that makes `-u-fw` different from other keywords is that we do this weird conversion to an integer, since that’s the feedback we got from TG1. The precedent is simply in cases where we’d want to return a different value, in cases that we must do that because of a mandate from TG1, only in those limited cases do we go into the getter with a scalpel, if we can convert it to an integer we can, if we can’t we return `undefined`. That’s a clean precedent to se. +SFC: Concrete proposal: return `undefined` in the getter, and `toString` retains the input string. Then the only thing that makes `-u-fw` different from other keywords is that we do this weird conversion to an integer, since that’s the feedback we got from TG1. The precedent is simply in cases where we’d want to return a different value, in cases that we must do that because of a mandate from TG1, only in those limited cases do we go into the getter with a scalpel, if we can convert it to an integer we can, if we can’t we return `undefined`. That’s a clean precedent to se. RGN: `new Intl.Locale("en-u-ca-mistake").calendar // => "mistake"` is current specified behavior. So I think if we’re going to respect that guidance of converting to integer, then your proposal makes the most sense. @@ -147,9 +147,9 @@ RGN: I think that’s where I am. FYT: I’ll need strong support from you otherwise we’re killing a dead snake. But if you guys are willing to go there and say that the July one is better than the September one, I think I can bring it back. -EAO: Having been a part of that TG1 discussion, presenting this – my sense of what happened in TG1 is that this was presented as – the context in which this was presented is a context that led people to look at the other places where we define days of the week, which means the numberings and so on, but if this is in fact intended to present explicitly the BCP 47 string representation that we happen to understand to mean starting day of the week, that puts this in a different light and puts more focus on what’s immediately around it, the other strings we’re unpacking from the string and representing directly even if the values in those fields we consider to be incorrect, but we still understand what they mean syntactically. +EAO: Having been a part of that TG1 discussion, presenting this – my sense of what happened in TG1 is that this was presented as – the context in which this was presented is a context that led people to look at the other places where we define days of the week, which means the numberings and so on, but if this is in fact intended to present explicitly the BCP 47 string representation that we happen to understand to mean starting day of the week, that puts this in a different light and puts more focus on what’s immediately around it, the other strings we’re unpacking from the string and representing directly even if the values in those fields we consider to be incorrect, but we still understand what they mean syntactically. -SFC: I think EAO’s characterization is correct, but I don’t want to make assumptions about the rationale that led to the TG1 recommendation. We have to bring it back as a normative change anyway, and I think when we do we can present TG1 with two choices: return a string like every other getter, and if that gets too much pushback we should have a fallback ready, and be able to explain the pros and cons of the fallback. I like option 5 as the fallback, but be clear with TG1 that we want the getters to behave like toString. I think we should bring this back to TG1 and give them these two options, and let them choose which one. As a group we should advocate for option 4 – can we just make this thing return the string and move on? +SFC: I think EAO’s characterization is correct, but I don’t want to make assumptions about the rationale that led to the TG1 recommendation. We have to bring it back as a normative change anyway, and I think when we do we can present TG1 with two choices: return a string like every other getter, and if that gets too much pushback we should have a fallback ready, and be able to explain the pros and cons of the fallback. I like option 5 as the fallback, but be clear with TG1 that we want the getters to behave like toString. I think we should bring this back to TG1 and give them these two options, and let them choose which one. As a group we should advocate for option 4 – can we just make this thing return the string and move on? RGN: +1 @@ -165,7 +165,7 @@ FYT: I’ll try to contact him. I’ll craft a proposal and try to reach out to SFC: I think that was in the presentation – -FYT: I just didn’t emphasize it enough – it was mentioned, but not as a reason. And the toString part I don’t think we mentioned, and some other things that showed up here we didn’t mention that. Intuitively I know what’s the right thing to do, but I didn’t articulate it well last time. +FYT: I just didn’t emphasize it enough – it was mentioned, but not as a reason. And the toString part I don’t think we mentioned, and some other things that showed up here we didn’t mention that. Intuitively I know what’s the right thing to do, but I didn’t articulate it well last time. ### Locale Extensions Update @@ -205,51 +205,51 @@ BAN: The limitation on this is, if the user has something in Accept-Language, bu #### Conclusion -BAN to create example buckets based on CLDR data to inform decisions about how much entropy is needed, define the entropy in the specification but not the specific buckets, use CLDR data to inform us on how much entropy is necessary. +BAN to create example buckets based on CLDR data to inform decisions about how much entropy is needed, define the entropy in the specification but not the specific buckets, use CLDR data to inform us on how much entropy is necessary. ### Should ECMA-402 spec text for time zone canonicalization refer to CLDR or to IANA as authoritative? #825 https://github.com/tc39/ecma402/issues/825 -JGT: The summary here is that CLDR is making a bunch of helpful changes to resolve longstanding issues with their data that has led to calcutta rather than kolkata, kiev instead of kyiv, and so forth. They’re adding a new attribute called IANA that’s only present when it’s different – so for Europe/Kiev canonical ID in CLDR, there’s now an IANA attribute that’s Europe/Kyiv. In addition, they’re going through and adding missing IANA timezone IDs, cleaning it up so that all browsers should be able to depend on CLDR as their source of truth for IANA. For example, today Firefox loads the actual IANA data and uses that for canonicalization instead of using CLDR, and that’s the source of differences between the data. But with this, we could have specified behavior that actually matches, with the caveat that the IANA database changes over time, but at least there won’t be changes that persist. +JGT: The summary here is that CLDR is making a bunch of helpful changes to resolve longstanding issues with their data that has led to calcutta rather than kolkata, kiev instead of kyiv, and so forth. They’re adding a new attribute called IANA that’s only present when it’s different – so for Europe/Kiev canonical ID in CLDR, there’s now an IANA attribute that’s Europe/Kyiv. In addition, they’re going through and adding missing IANA timezone IDs, cleaning it up so that all browsers should be able to depend on CLDR as their source of truth for IANA. For example, today Firefox loads the actual IANA data and uses that for canonicalization instead of using CLDR, and that’s the source of differences between the data. But with this, we could have specified behavior that actually matches, with the caveat that the IANA database changes over time, but at least there won’t be changes that persist. -If we assume the world we want to get to is all browsers use ICU and that pulls data out of CLDR and all browsers can depend on that, what do we want to write in the spec? There are two options I lay out in this issue: we could essentially write the spec to say “use CLDR.” Yes we’re using the IANA database, but conforming implementations must use CLDR data in this way for it to be a conforming ECMAScript implementation. The other way is to define behavior in terms of the IANA database, so that all browsers work the same, and probably mention – add a sentence that says “by the way ICU/CLDR will provide you with a spec-compliant implementation of this, so you might as well use it.” So those are the three options and I wanted to see if anyone had an opinion about which to use. +If we assume the world we want to get to is all browsers use ICU and that pulls data out of CLDR and all browsers can depend on that, what do we want to write in the spec? There are two options I lay out in this issue: we could essentially write the spec to say “use CLDR.” Yes we’re using the IANA database, but conforming implementations must use CLDR data in this way for it to be a conforming ECMAScript implementation. The other way is to define behavior in terms of the IANA database, so that all browsers work the same, and probably mention – add a sentence that says “by the way ICU/CLDR will provide you with a spec-compliant implementation of this, so you might as well use it.” So those are the three options and I wanted to see if anyone had an opinion about which to use. SFC: To be clear about the options: A: use CLDR only, B: Use IANA only, and C:, what was C? -JGT: Everyone’s going to be using CLDR, but the question is what to write in the spec. A is dictate CLDR, option B is define it in terms of IANA that just so happen to match what CLDR is doing, option C is option B but also add a note saying “by the way, CLDR does this so you might want to use it.” +JGT: Everyone’s going to be using CLDR, but the question is what to write in the spec. A is dictate CLDR, option B is define it in terms of IANA that just so happen to match what CLDR is doing, option C is option B but also add a note saying “by the way, CLDR does this so you might want to use it.” EAO: If the source of truth here is IANA I have a hard time understanding why we should be defining something other than IANA as the source of truth. SFC: I agree with EAO’s statement in the sense that CLDR is trying to reflect IANA, so it makes sense to go to IANA. My more meta question, though: I like where we arrived in the timezone canonicalization, I’m wondering if with this proposal why do we even need to name the authority? Why don’t we just sort of – I don’t see a reason we need to make a normative reference to either CLDR or IANA, but just say that browsers should reflect the latest IANA name from whatever database the browser is using, then leave the decision on which database to use up to the implementation. We don’t want necessarily an implementation that’s using an old timezone database to suddenly become a nonconforming implementation. -JGT: With CLDR, what you’re saying is totally doable. That said there are some overrides that ECMAScript does on CLDR, and those do need to be in the spec because we’ll need to modify behavior in some way. If we say IANA is the source of truth, you can’t just say “use the latest IANA”, you have to say “use the latest IANA customized in this way to match what CLDR is doing.” +JGT: With CLDR, what you’re saying is totally doable. That said there are some overrides that ECMAScript does on CLDR, and those do need to be in the spec because we’ll need to modify behavior in some way. If we say IANA is the source of truth, you can’t just say “use the latest IANA”, you have to say “use the latest IANA customized in this way to match what CLDR is doing.” -RGN: Basically, this is an area where there are multiple plausible right answers, even the IANA data itself is configurable by build options. The definitions here are not universally agreed, and generally in ECMA-402 when that is the case we do not make normative requirements, but instead limit ourselves to recommendations – describe the scope of conforming behavior and say that as long as you adhere to that, you’re good. I don’t want to nail this down more specifically, given that different databases are used. Additionally, I don’t want to make normative requirements. It’s valid for different implementations to disagree on the spelling of any particular timezone. +RGN: Basically, this is an area where there are multiple plausible right answers, even the IANA data itself is configurable by build options. The definitions here are not universally agreed, and generally in ECMA-402 when that is the case we do not make normative requirements, but instead limit ourselves to recommendations – describe the scope of conforming behavior and say that as long as you adhere to that, you’re good. I don’t want to nail this down more specifically, given that different databases are used. Additionally, I don’t want to make normative requirements. It’s valid for different implementations to disagree on the spelling of any particular timezone. -JGT: I want to push back a little bit about users complaining about that exact issue. Less about the differences between implementations and more – well, the whole proposal was an attempt to solve that. There aren’t so many implementations that people will willfully violate it. But I do think encouraging implementations to do what users will expect and complain about the least and be consistent with each other is a good thing. We have years of experience showing that this hasn't happened so far with the laxity of the specification. And so I do think there’s a pretty strong case to be made that we should tighten the specification to prevent future problems of implementations getting out of sync with each other or getting out of sync with user expectations. +JGT: I want to push back a little bit about users complaining about that exact issue. Less about the differences between implementations and more – well, the whole proposal was an attempt to solve that. There aren’t so many implementations that people will willfully violate it. But I do think encouraging implementations to do what users will expect and complain about the least and be consistent with each other is a good thing. We have years of experience showing that this hasn't happened so far with the laxity of the specification. And so I do think there’s a pretty strong case to be made that we should tighten the specification to prevent future problems of implementations getting out of sync with each other or getting out of sync with user expectations. RGN: I'm pretty sure I agree with that. I wouldn't characterize it as tightening the specification but improving the recommendations that live in it. My suspicion is that part of the problem we’re seeing is that the majority of implementations do just strictly rely on a data source, and the feedback from their users isn’t getting far enough upstream. -JGT: Let me see if this same thing you are saying: the core problem today is that CLDR is something everyone wants to rely on, but also CLDR has an implementation that is bad from the perspective of many users. So in terms of implementations, if everyone uses CLDR and CLDR continues on the path it’s going, we’ll have consistent behavior across implementations that matches what users expect. +JGT: Let me see if this same thing you are saying: the core problem today is that CLDR is something everyone wants to rely on, but also CLDR has an implementation that is bad from the perspective of many users. So in terms of implementations, if everyone uses CLDR and CLDR continues on the path it’s going, we’ll have consistent behavior across implementations that matches what users expect. Let’s say CLDR or IANA make really dumb decisions. What is the right way to ensure that there is consistency in the ECMAScript ecosystem. SBE: At this point I think this is the consensus but I wanted to register support for not making this a normative change. The ability of any given data source to reflect what users expect may change over time. At one point IANA was the go-to, now CLDR is making improvements. So I think informative recommendation is better than anything normative. -YSZ: I think that I agree with SFC on other folks – I think these implementation, even a timezone database, has multiple (?). Some of the internationalization data from ICU doesn’t work well in very small embedded systems. I think this is agreement on the current ECMA-402 spec. I think it is nice that we have a recommendation, but I’m not sure we should have a normative requirement of what we should include. +YSZ: I think that I agree with SFC on other folks – I think these implementation, even a timezone database, has multiple (?). Some of the internationalization data from ICU doesn’t work well in very small embedded systems. I think this is agreement on the current ECMA-402 spec. I think it is nice that we have a recommendation, but I’m not sure we should have a normative requirement of what we should include. EAO: Agreeing with much of what YSZ and SBE said. JGT: What I’m hearing is consensus that we should make a non-normative recommendation. Should that recommendation be to use whatever CLDR says, or should it be “here’s the set of behavior we expect to see based on IANA that matches what CLDR does”. From what I hear from folks in this conversation, going direct to IANA and describing the IANA behavior we want would be safer? Does that sound right? -SFC: I think what we should do here is we should describe the outcome we want. And I would even say that it’d be acceptable for us to add some test262 on what we want that outcome to be, even if the recommendation is non-normative. The outcome we want is that we want the canonical names (like Kyiv) to be promoted in a certain timeframe, so we should describe what the outcome we want is, and in terms of what data source you use to get that outcome, we should at best give suggestions on data sources you could get to give this outcome, and even have tests for it. I think, though, the question of whether we refer to CLDR or IANA is a red herring – we could give both as examples, but that’s not we’re specifying. What we should actually say is what we want, and what we want is timezone names having a certain behavior, being merged or not merged, updated or not updated. +SFC: I think what we should do here is we should describe the outcome we want. And I would even say that it’d be acceptable for us to add some test262 on what we want that outcome to be, even if the recommendation is non-normative. The outcome we want is that we want the canonical names (like Kyiv) to be promoted in a certain timeframe, so we should describe what the outcome we want is, and in terms of what data source you use to get that outcome, we should at best give suggestions on data sources you could get to give this outcome, and even have tests for it. I think, though, the question of whether we refer to CLDR or IANA is a red herring – we could give both as examples, but that’s not we’re specifying. What we should actually say is what we want, and what we want is timezone names having a certain behavior, being merged or not merged, updated or not updated. JGT: What you’ve described matches option C, so if everyone agrees I can prepare a PR with text that matches option C. EAO: If the sense is that we’ll get a decent result even if we don’t do anything as a result of CLDR fixing it, do we even need to do anything? Do we even need to include a non-normative note (though I’m also fine with that) -JGT: CLDR seems less committed than we are in the behavior we’d like to see, so it’s helpful to have very clear spec text indicating what we want, so that if personnel change at CLDR or they make a bad decision, we can point to the spec text. +JGT: CLDR seems less committed than we are in the behavior we’d like to see, so it’s helpful to have very clear spec text indicating what we want, so that if personnel change at CLDR or they make a bad decision, we can point to the spec text. SFC: +1 @@ -273,9 +273,9 @@ SFC: My angle here on the followup is that I think this issue is sufficiently in JGT: That makes a lot of sense. Let me focus this discussion on the rest of it. We can skip past 1. 2 is pretty straightforward – switch to use the other ICU API when it’s available. 3 is more interesting, of when we want to ship these changes in implementations. Do we use the new ICU API right away? Do we wait for Temporal? I don’t have a strong opinion but we do have customer complaints about this, and if the ICU API can fix it, we could fix it right away instead of waiting for Temporal. -SFC: Shu has said that if we change the behavior of one we [missed a bit]. +SFC: Shu has said that if we change the behavior of one we [missed a bit]. -JGT: If no one objects, we can wait for Temporalv4 to switch over to the new ICU API to stop canonicalizing. I guess there’s one more thing that’s in another issue that’s related to this, which is the two year waiting period. The next time we get a Kyiv situation where an existing id is renamed, we decided to wait two years before we change it. +JGT: If no one objects, we can wait for Temporalv4 to switch over to the new ICU API to stop canonicalizing. I guess there’s one more thing that’s in another issue that’s related to this, which is the two year waiting period. The next time we get a Kyiv situation where an existing id is renamed, we decided to wait two years before we change it. SFC: We discussed this at length in this group in March or something, is there anything that’s changed that would make us want to revisit that discussion? I think it’s this group that made the two-year recommendation. @@ -283,7 +283,7 @@ SFC: We discussed this at length in this group in March or something, is there a https://github.com/tc39/proposal-intl-duration-format/issues/169 -SFC: All three of these things are things, of course, that Anba brought up. The first is negative durations – we have positive and negative durations, we don’t have mixed positive and negative durations. How do we render that? CLDR doesn’t give us a clear signal here. I think if we reached a reasonable conclusion in this group we could go to CLDR with that resolution, and still be able to reflect it in our spec. +SFC: All three of these things are things, of course, that Anba brought up. The first is negative durations – we have positive and negative durations, we don’t have mixed positive and negative durations. How do we render that? CLDR doesn’t give us a clear signal here. I think if we reached a reasonable conclusion in this group we could go to CLDR with that resolution, and still be able to reflect it in our spec. I listed here that there’s two reasonable ways to do it: put the sign on the the first unit in display order, or put the sign on every single element. @@ -311,21 +311,21 @@ SFC: Intl and Temporal can already have negative durations, we just have to deci EAO: Yes, but is there a human meaningful use of these? -SFC: If you take two instances in time and take the difference, you might get a negative value. +SFC: If you take two instances in time and take the difference, you might get a negative value. JGT: A real-world example could be a long distance plane flight, and the flight time. The delta in flight times between takeoff and departure in local time. If you’re going across time zones in a fast plane on a long flight, you might land before you take off when considered from the perspective of local time, and you’d want to be able to indicate that. -SFC: That’s a really good example. Back to the question at hand. I still think we should do option 2 and go back to CLDR with a recommendation. +SFC: That’s a really good example. Back to the question at hand. I still think we should do option 2 and go back to CLDR with a recommendation. RGN: It’s offputting in a way that would make me think we’ll regret specifying it. FYT: I agree! -RGN: When you look at – do we have a corpus of these to look at? I would guess if we do that 2 would be much, much less common than 1. +RGN: When you look at – do we have a corpus of these to look at? I would guess if we do that 2 would be much, much less common than 1. SFC: My response to this is that generally durations are only going to have one unit in them, maybe two, in which case they might use the digital format,. If you only have the digital format, there’s not a huge amount of ambiguity – there is a correct solution. Having a multi-field negative duration is already an edge case that’s not going to come up too often, but our job is to make sure that even edge cases are well-specified – non edge cases are easy, so specifying the edge cases is what our job is. -RGN: I agree, but even as I look at it I’m not sure 2 is free of ambiguity. The issue is whether the composite is recognizable as a unit in itself, or whether the individual pieces can have that variance. +RGN: I agree, but even as I look at it I’m not sure 2 is free of ambiguity. The issue is whether the composite is recognizable as a unit in itself, or whether the individual pieces can have that variance. SFC: Are you advocating for 3? @@ -347,11 +347,11 @@ BAN: The more I look at this, the more appealing option 4 (parentheses) is. The JGT: For the keyphrase option 5, consider the word "earlier". "3 days earlier." Where you treat backwards as an exceptional case. -FYT: I am proposing a new idea that may not be popular: what we know is that we have to output a string whenever a negative duration happened, right? But in reality this is not something people usually use in language, that’s why we’re struggling here. We can’t find a lot of examples in our daily life. What if whenever duration is negative we return to toString: return machine-readable time, because we don’t think people are really going to use it. I do agree with RGN that we may regret if we specify something incorrect, it will haunt us later. One possibility is to say “nah, we don’t know how to deal with it, we don’t believe anyone will use it, so we just fall back to toString unless/until someone yells at us.” +FYT: I am proposing a new idea that may not be popular: what we know is that we have to output a string whenever a negative duration happened, right? But in reality this is not something people usually use in language, that’s why we’re struggling here. We can’t find a lot of examples in our daily life. What if whenever duration is negative we return to toString: return machine-readable time, because we don’t think people are really going to use it. I do agree with RGN that we may regret if we specify something incorrect, it will haunt us later. One possibility is to say “nah, we don’t know how to deal with it, we don’t believe anyone will use it, so we just fall back to toString unless/until someone yells at us.” SFC: My response to both FYT and JGT at the end of the time box, we’ve heard two examples where this can come up, the other is like on a chess timer where you might accrue negative time. I think those are both examples. I think the key phrase doesn’t work with the chess time example. I didn’t expect this to be so controversial – I was thinking making a recommendation to CLDR, but maybe we could just bring it to CLDR and let them make the decision, because they have more resources if we need a data-driven solution. -JGT: We could also add some more use cases – use cases never hurt. +JGT: We could also add some more use cases – use cases never hurt. EAO: 4 is the only option for which I can be sure of its meaning. diff --git a/meetings/notes-2023-11-16.md b/meetings/notes-2023-11-16.md index fd1a9cf1..076fea1d 100644 --- a/meetings/notes-2023-11-16.md +++ b/meetings/notes-2023-11-16.md @@ -17,7 +17,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -58,11 +58,11 @@ DLM: I thought it was that there’s one date format that’s incorrect, but one EAO: My understanding that it’s not specifically related to these locales, but about how ICU is handling dependencies between this locales, or root and locales. Anba has pointed to a likely reason for this, and it looks like the fix will be easy and simple – but it hasn’t been done yet, so who knows? -SFC: Based on the findings in Anba’s thread as well as in the ICUTC thread that followed from it, it appears the root cause is a bug with the ICU fallback mechanism, which means that it probably impacts other types of data as well, it’s just this is the one that got noticed because it’s a common pattern to use on the web for ISO date formatting. Probably this is just a symptom and it affects other locales as well – it’s a little bit of a pity that ICUTC didn’t detect it sooner. We’re working on a new data-driven test framework that should hopefully have better test coverage and detect these things in alpha, beta, or release candidate. There was a talk about the data-driven testing at the Unicode Technology Workshop last week – hopefully these issues will be detected sooner. The next step is to get the ICU74 patched, and make sure that YSZ and FYT be careful about incorporating shipping once Rich’s change is landed, before we ship anything. +SFC: Based on the findings in Anba’s thread as well as in the ICUTC thread that followed from it, it appears the root cause is a bug with the ICU fallback mechanism, which means that it probably impacts other types of data as well, it’s just this is the one that got noticed because it’s a common pattern to use on the web for ISO date formatting. Probably this is just a symptom and it affects other locales as well – it’s a little bit of a pity that ICUTC didn’t detect it sooner. We’re working on a new data-driven test framework that should hopefully have better test coverage and detect these things in alpha, beta, or release candidate. There was a talk about the data-driven testing at the Unicode Technology Workshop last week – hopefully these issues will be detected sooner. The next step is to get the ICU74 patched, and make sure that YSZ and FYT be careful about incorporating shipping once Rich’s change is landed, before we ship anything. YSZ: Sounds good! -EAO: To address the other part of the root cause, that makes this bug a webcompat issue, is the way this locale is misused on the web. +EAO: To address the other part of the root cause, that makes this bug a webcompat issue, is the way this locale is misused on the web. FYT: I think we need to think carefully about this, and we need to talk with the rest of TC39. There’s web misuse of this locale, but why? Because there’s no other way to do the right thing. When ECMA-402 produces an option that’s good for the user, we have to think about whether non-402 has something to offer. This will be used in the future, because 262 doesn’t have the right way to do it. @@ -189,7 +189,7 @@ FYT: I have a hard time understanding this. BAN: Style "fractional" means "append this to the last unit that didn't have fractional style." -LAF: I did not totally understand what you did, because it was the same. I think if you want to expand that idea to fractional hours, I would rather say “decimal hours” instead of “dividing the hour into sixty minutes”, express it as a decimal number. +LAF: I did not totally understand what you did, because it was the same. I think if you want to expand that idea to fractional hours, I would rather say “decimal hours” instead of “dividing the hour into sixty minutes”, express it as a decimal number. FYT: It doesn't make sense to say milliseconds: "fractional" but it's not milliseconds that have a fraction, it's seconds that has a fraction. @@ -197,11 +197,11 @@ LAF: There are in fact two concepts here. First, do I want to express seconds? S BAN: We're taking in Temporal.Duration objects, which have separate properties for the subsecond values. So we have a way of expressing desired precision, with the fractionalDigits option. But yeah, it's because seconds in durations as we have them set up… it's an integer number. -SFC: Based on what FYT and LAF said, it seems we have more design space to explore here. Therefore, I think we should stick with the current style options right now, and revisit this in DurationFormat v2. Additionally, though, I do think we should have a DurationFormat v2 – we just can’t start v2 until we have DurationFormat v1 landed. +SFC: Based on what FYT and LAF said, it seems we have more design space to explore here. Therefore, I think we should stick with the current style options right now, and revisit this in DurationFormat v2. Additionally, though, I do think we should have a DurationFormat v2 – we just can’t start v2 until we have DurationFormat v1 landed. SFC: And we can still use style "fractional" internally in the spec. -BAN: Yes, using it internally improves the readability of the spec. +BAN: Yes, using it internally improves the readability of the spec. ### Digital duration format should probably be more lenient with data #161 @@ -211,17 +211,17 @@ SFC: This issue would change restrictions on engines when they perform formattin FYT: DurationFormat? I don’t think so, I don’t think there’s something I can defer to ICU -SFC: You can defer to ICU on digital duration formatting, which is the thing that this largely impacts. +SFC: You can defer to ICU on digital duration formatting, which is the thing that this largely impacts. -FYT: No? I don’t think so? I don’t think DurationFormat is easy to delegate, with the complexity we’ve put in the spec. +FYT: No? I don’t think so? I don’t think DurationFormat is easy to delegate, with the complexity we’ve put in the spec. -SFC: Conclusion for Issue 161: I’ll say the conclusion that I think it is, that we should bring it to plenary when we’re ready, but doesn’t necessarily have to be in the batch that we bring in November. +SFC: Conclusion for Issue 161: I’ll say the conclusion that I think it is, that we should bring it to plenary when we’re ready, but doesn’t necessarily have to be in the batch that we bring in November. YSZ: SGTM SFC: [posted comment on DF #89] -SFC: I believe we’ve gotten in all the issues – I’m marking them as “consensus” and “needs tg1”. I think this brings us to the end of DurationFormat in terms of all the issues we know about. +SFC: I believe we’ve gotten in all the issues – I’m marking them as “consensus” and “needs tg1”. I think this brings us to the end of DurationFormat in terms of all the issues we know about. ### Locale with -u-fw- value other than 13 value will cause assertion #78 @@ -231,11 +231,11 @@ FYT: Some background: I presented Intl.LocaleInfo in July and September meeting. SFC: It is useful to discuss that the proposed fix does go back to what we discussed last month, which is that the return value is should be the string. -FYT: Yes, but the point is that it should be returning anything in the locale that you pass in, so this is not a good PR. +FYT: Yes, but the point is that it should be returning anything in the locale that you pass in, so this is not a good PR. -SFC: I still think we can bring this back to the November plenary as a 15 minute item once we have the PR fixed up. +SFC: I still think we can bring this back to the November plenary as a 15 minute item once we have the PR fixed up. -FYT: Anyway, DE agreed that we could return the string form. But it should be, probably, the same as whatever we have in the calendar for the thing, and he agree that if we take 0 to 7, he’s fine. So we do need special handling for 0 to 7. +FYT: Anyway, DE agreed that we could return the string form. But it should be, probably, the same as whatever we have in the calendar for the thing, and he agree that if we take 0 to 7, he’s fine. So we do need special handling for 0 to 7. SFC: Do we still want to have the special handling for 0 through 7, or now that we’re returning Strings should we only deal with Strings in this API? It might be easier, since otherwise you have to have a special case for it. @@ -243,12 +243,12 @@ EAO: The other interface is representing this, right, the other places in JavaSc FYT: Yes, those are returning numbers -EAO: Then I think we should accept specifically those ones. +EAO: Then I think we should accept specifically those ones. -FYT: Yes, I should rework the PR and convert 0 to 7 to that. I think that’s what TC39 told me before, and they have concern about that part. -EAO: That would match the approach of being liberal on input and strict on output, which I think is appropriate here. +FYT: Yes, I should rework the PR and convert 0 to 7 to that. I think that’s what TC39 told me before, and they have concern about that part. +EAO: That would match the approach of being liberal on input and strict on output, which I think is appropriate here. -SFC: Thank you, FYT! +SFC: Thank you, FYT! #### Conclusion @@ -256,15 +256,15 @@ FYT to update the PR and bring to TG1. ### Consider making ResolveLocale return the normalized requested locale instead of the available locale #830 -SFC: There’s two places you can get locales back from the API: supportedLocalesOf, which takes in a list and returns a subset of that list, with normalization, but it just returns the elements of the list in normalized form. But resolvedOptions of a locale returns information about any locale, not just this locale. +SFC: There’s two places you can get locales back from the API: supportedLocalesOf, which takes in a list and returns a subset of that list, with normalization, but it just returns the elements of the list in normalized form. But resolvedOptions of a locale returns information about any locale, not just this locale. SFC: For example, if your input locale is de-Latn-At and your resolved locale is de, should we return the input locale or the resolved locale? The alternative is we keep the current behavior, which we implemented in ICU4X. The original motivation for this is kind of moot, because we have an avenue to support both the original behavior and the proposed behavior. I just think the proposed behavior is cleaner, because resolveLocale isn’t exposed anywhere else in 402, which makes it a lot more flexible for implementations. -FYT: The resolved locale is… you're talking about the resolvedOptions().locale, right? The issue is that you’re passing in a list of locales, and whatever got resolved would be maybe something that you never pass in. For example, you pass in nothing, it’ll be the default locale. +FYT: The resolved locale is… you're talking about the resolvedOptions().locale, right? The issue is that you’re passing in a list of locales, and whatever got resolved would be maybe something that you never pass in. For example, you pass in nothing, it’ll be the default locale. SFC: That’s true, passing in nothing would need to be a special case. -FYT: Or you pass something we don't have, you pass in Cherokee or something that we may not have sorting order, it will resolve to default locale or some other language. It’s not just normalized. +FYT: Or you pass something we don't have, you pass in Cherokee or something that we may not have sorting order, it will resolve to default locale or some other language. It’s not just normalized. EAO: I think there are two different behaviors here. One is when we take the input and decide that it really means something, and we are not doing fallback to the system locale, then we end up in a situation where resolvedOptions and supportedLocalesOf end up producing different sorts of results. If we are doing fallbacking to the system locale or to whatever that is, that’s different. Because if we end up not supporting this locale, the result is the same always, right? So I would say that the least surprising thing for me as a user of this interface would probably be that effectively the behavior of resolvedOptions and supportedLocalesOf are as much the same thing as possible. @@ -278,7 +278,7 @@ EAO: With the same localization as in supportedLocalesOf FYT: I still have problems understanding the motivation for the change – what’s the problem with the current behavior? If there’s no good reason to change, there’s a good reason not to change. -SFC: The reason to change is because the available locales list is not exposed anywhere, except in this one API. By keeping it away from users so that they can’t get to it, it makes it a little bit easier to implement, because otherwise this is an implementation detail that we’re exposing to the web, which would be nice to avoid. In terms of priority of constituency, that’s low: most end users, second developers, third implementors. But also I agree with what EAO is saying, which is that it’s strange that you can pass to a list to supportedLocalesOf and to the constructor, and get different results. So I do think there’s a motivation for changing the behavior. The reason, though, that I’m not like “we should definitely move forward with this 100%” is that this is a very old behavior, and if we change it there may be web compatibility issues. +SFC: The reason to change is because the available locales list is not exposed anywhere, except in this one API. By keeping it away from users so that they can’t get to it, it makes it a little bit easier to implement, because otherwise this is an implementation detail that we’re exposing to the web, which would be nice to avoid. In terms of priority of constituency, that’s low: most end users, second developers, third implementors. But also I agree with what EAO is saying, which is that it’s strange that you can pass to a list to supportedLocalesOf and to the constructor, and get different results. So I do think there’s a motivation for changing the behavior. The reason, though, that I’m not like “we should definitely move forward with this 100%” is that this is a very old behavior, and if we change it there may be web compatibility issues. EAO: To go on from there, there’s also the POV that with this trying to make implementor work easier, we’re doing it by making implementors do extra work and have extra uncertainty. I would be okay with us deciding not to change anything at all, but I can also see that doing this differently than we did before to make it more logical does have appeal. @@ -304,7 +304,7 @@ FYT: If you want to support underscore, you could do it in userland – you don SFC: That’s a good point -FYT: And I believe those three criteria are drafted by ZB, so I turn it back to him. +FYT: And I believe those three criteria are drafted by ZB, so I turn it back to him. #### Conclusion @@ -327,7 +327,7 @@ FYT: So cash rounding is connected to the physical bill or coin, right? BAN: Yes, it’s what you’re most likely to be using in your day to day life. I believe this came up because there exists locales where the ISO 4217 digits are far more than what anyone would ever use. -SFC: “precision” is alright – the other option would be something more specific, like “currencyCash”, either “cash” or “financial”. I think I lean toward “currencyPrecision”, though. Another issue with this type of PR is that it’s right on the border of what’s big enough to be a proposal and what’s small enough to be a PR, so I would like to hear a signal from someone like FYT or YSZ about whether it’s reasonable to move forward in its current form as a PR, or if you’d like to make it a full-fledged proposal. +SFC: “precision” is alright – the other option would be something more specific, like “currencyCash”, either “cash” or “financial”. I think I lean toward “currencyPrecision”, though. Another issue with this type of PR is that it’s right on the border of what’s big enough to be a proposal and what’s small enough to be a PR, so I would like to hear a signal from someone like FYT or YSZ about whether it’s reasonable to move forward in its current form as a PR, or if you’d like to make it a full-fledged proposal. YSZ: I would like to look into it. I don’t have a concrete comment right now, but I would like to look into ICU and if the current interface works well, or if we need to have to have an additional option pack or something like that, in terms of implementation. @@ -350,8 +350,8 @@ FYT: Well, he doesn’t say he wants the pattern, he says he wants to get the la EAO: To me this seems way too much like they’re saying they want to get this so that they can parse this localized string you’re giving me. If they wanted it, they could use .formatToParts -SFC: I agree, and also we have date field display names. If you really must get the things out of the parts, we also support formatToParts. We support this, and a user can implement this in userland. And this particular pattern is very much English-specific. Somewhere else they might use different letters, and CLDR doesn’t even give us that information – they used to have something called a “localized pattern”, but that was a mistake and they don’t use it anymore. I think we should say that we don’t plan on action this in its current state and then close the issue. +SFC: I agree, and also we have date field display names. If you really must get the things out of the parts, we also support formatToParts. We support this, and a user can implement this in userland. And this particular pattern is very much English-specific. Somewhere else they might use different letters, and CLDR doesn’t even give us that information – they used to have something called a “localized pattern”, but that was a mistake and they don’t use it anymore. I think we should say that we don’t plan on action this in its current state and then close the issue. #### Conclusion -Say we’re not going to action this, and give advice on what to do in the short term. +Say we’re not going to action this, and give advice on what to do in the short term. diff --git a/meetings/notes-2023-12-14.md b/meetings/notes-2023-12-14.md index 3f1acfc2..b272b942 100644 --- a/meetings/notes-2023-12-14.md +++ b/meetings/notes-2023-12-14.md @@ -16,7 +16,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -57,7 +57,7 @@ SFC: I didn’t like the last time we had to scramble to get it done at the end, FYT: From my understanding at the moment, I don’t think any proposals can make the cut. -SFC: The unresolved issue regarding the first day of the week, was it approved by TG1? +SFC: The unresolved issue regarding the first day of the week, was it approved by TG1? FYT: Yes diff --git a/meetings/notes-2024-01-18.md b/meetings/notes-2024-01-18.md index 48e3804f..ba6de12a 100644 --- a/meetings/notes-2024-01-18.md +++ b/meetings/notes-2024-01-18.md @@ -17,7 +17,7 @@ - [Discussion Board](https://github.com/tc39/ecma402/projects/2) - [Status Wiki](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking) -- please update! -- [Abbreviations](https://github.com/tc39/notes/blob/master/delegates.txt) +- [Abbreviations](https://github.com/tc39/notes/blob/HEAD/delegates.txt) - [MDN Tracking](https://github.com/tc39/ecma402-mdn) - [Meeting Calendar](https://calendar.google.com/calendar/embed?src=unicode.org_nubvqveeeol570uuu7kri513vc%40group.calendar.google.com) - [Matrix](https://matrix.to/#/#tc39-ecma402:matrix.org) @@ -26,7 +26,7 @@ ### Updates from the Editors -USA: There's not a whole lot of activity lately in the repo, although Anba made an excellent editorial pull request that would get rid of the alias dataLocale in the spec. It's an awkwardly phrased section of the spec, with variables named dataLocaleData. So this is an editorial change that is just from earlier today, soI couldn’t review it, but that’s the one recent editorial change. Then there’s +USA: There's not a whole lot of activity lately in the repo, although Anba made an excellent editorial pull request that would get rid of the alias dataLocale in the spec. It's an awkwardly phrased section of the spec, with variables named dataLocaleData. So this is an editorial change that is just from earlier today, soI couldn’t review it, but that’s the one recent editorial change. Then there’s BAN: The wording for table iteration has inconsistency, so I went through and made it consistent with 262. Changes are all in DateTimeFormat. @@ -38,17 +38,17 @@ SFC: One other comment for editors: it’s getting close to when we should start USA: I can be more proactive about that, but it’s a bit of a mess to be honest on the ECMA side, given that there has not been any agreement between the 262 editors and the ECMA secretariat on what to do in the process in terms of editorializing these specs. What happened last year is that we were late when it came to starting the process, we’re still ahead of 262 because it requires more work, and they couldn’t reach an agreement on how to proceed. I would reach out to Samhina and the 262 folks in February so, if we could prompt both groups to come to an agreement that would be helpful for 402 as well. -SFC: Also, we want the repo to be a clean, stable state, so at some point in the next month we should say “no more PRs” so that we have a nice clean slate when we build what we need to build. +SFC: Also, we want the repo to be a clean, stable state, so at some point in the next month we should say “no more PRs” so that we have a nice clean slate when we build what we need to build. ### Updates from the MessageFormat Working Group -EAO: Very briefly: MF2 has reached feature freeze, so we are now finishing up details for the release in April as a tech preview. The polyfill that I maintain for Intl.MessageFormat has also been updated, so it’s the only full implementation that is there. There is also a planned in-person meeting for the WG, immediately following TC39 in San Diego, but that has been cancelled, so we will need to work remotely and very intensely after the TC39 meeting so that it can be included in the CLDR release in April. +EAO: Very briefly: MF2 has reached feature freeze, so we are now finishing up details for the release in April as a tech preview. The polyfill that I maintain for Intl.MessageFormat has also been updated, so it’s the only full implementation that is there. There is also a planned in-person meeting for the WG, immediately following TC39 in San Diego, but that has been cancelled, so we will need to work remotely and very intensely after the TC39 meeting so that it can be included in the CLDR release in April. ### Updates from Implementers https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking -YSK: From the JSC side we have some bugfixes, but no big updates in terms of implementaiton +YSK: From the JSC side we have some bugfixes, but no big updates in terms of implementaiton FYT: No recent 402 updates; been fixing security bugs in ICU. No big moves over christmas break. @@ -66,7 +66,7 @@ https://github.com/tc39/ecma402/projects/2 - [Proposal](https://github.com/tc39/proposal-intl-messageformat) - [Slides](https://docs.google.com/presentation/d/1ejR7UZXOxywDxC-rHh4uJftvKpbdSirpmD5mHwCKlCA/edit) -EAO: A rough outline of where this proposal is: It started life over 4 years ago, and we quickly recognized that the MessageFormat syntax should be spun off / defined better under Unicode CLDR. That progress is ongoing. In parallel with that, about 2 years ago the Intl.MessageFormat was accepted for stage 1, and later MessageResource split off from it to stage 1. Now I’m presenting, and possibly asking for stage 2, depending on how discussions go here. +EAO: A rough outline of where this proposal is: It started life over 4 years ago, and we quickly recognized that the MessageFormat syntax should be spun off / defined better under Unicode CLDR. That progress is ongoing. In parallel with that, about 2 years ago the Intl.MessageFormat was accepted for stage 1, and later MessageResource split off from it to stage 1. Now I’m presenting, and possibly asking for stage 2, depending on how discussions go here. EAO: There is now a formal spec language defining the proposal, it’s missing a couple of pieces but is largely complete, and the JavaScript API is the same. @@ -74,15 +74,15 @@ EAO: There is now a formal spec language defining the proposal, it’s missing a How do we express a message in source form? This is defined by the MF2 specification. How do we interact with it as a parsed data structure? Data model defined by MF2, API defined in this proposal. How to format a message? Behavior defined in MF2 [ consult with slides, fill in ] -EAO: There are a couple of specific things I’d call out with the API. The constructor takes three parameters: source, locales, options. SFC and others have said that maybe we want to do locales, source, options order. For format, the values parameter is what you’re formatting, and the second parameter, onError, is a little different. Because this is user-provided data coming from translators, a long chain of people, and the likelihood that there will be a mismatch in data given to this will be higher than in other formats, and in many cases it’s not discoverable or testable for developers. Therefore the default for error handling is to warn rather than throw, though this is customizable through this parameter. +EAO: There are a couple of specific things I’d call out with the API. The constructor takes three parameters: source, locales, options. SFC and others have said that maybe we want to do locales, source, options order. For format, the values parameter is what you’re formatting, and the second parameter, onError, is a little different. Because this is user-provided data coming from translators, a long chain of people, and the likelihood that there will be a mismatch in data given to this will be higher than in other formats, and in many cases it’s not discoverable or testable for developers. Therefore the default for error handling is to warn rather than throw, though this is customizable through this parameter. -Otherwise this is relatively normal. The MessageFunctions defined here are the customizable functions for users to use. More on that later. +Otherwise this is relatively normal. The MessageFunctions defined here are the customizable functions for users to use. More on that later. -Here are some of the core features we’re supporting. To start with a relatively simple example, you can create a MessageFormat and pass in a variable, essentially, to it that ends up formatted as part of the message. We include a bunch of functionality already in here :number, etc. We’re able to plug into the Intl formatters and use the options they support. Note that parts have the same part that you’d get by Intl.NumberFormat with these same options and locale. Now we get into some of the other aspects that I thought I’d call out, which is that we can have these variable declarations in MessageFormat, input variables and local ones, which depend on the preceding ones. For example here the currency is input, and the currency size is local. +Here are some of the core features we’re supporting. To start with a relatively simple example, you can create a MessageFormat and pass in a variable, essentially, to it that ends up formatted as part of the message. We include a bunch of functionality already in here :number, etc. We’re able to plug into the Intl formatters and use the options they support. Note that parts have the same part that you’d get by Intl.NumberFormat with these same options and locale. Now we get into some of the other aspects that I thought I’d call out, which is that we can have these variable declarations in MessageFormat, input variables and local ones, which depend on the preceding ones. For example here the currency is input, and the currency size is local. Another very programming-language-ey aspect of this is that for selection, effectively we do pattern matching, and this means that when we have a number that defaults to plural selection (there are other possibilities, this is user-customizable) we select what is the best match for the given selector, and then when you are formatting a message we first select the pattern and then format the pattern. One thing to note is that the .match selector can have more than one selector on it, so you can match on multiple things at the same time, though all matching has to be at the top level. -The most complicated bit of how this really works is that the second-from-bottom line on the slide, you see the constructor being called and it has a `functions` option passed in. When it’s used in the message that’s being formatted, it ends up being able to work as a selector based on the return object having a selectKey method on it. The boolean value, though, you could theoretically pass on from one declaration to the next if you need to. Particularly, the shape of how these message functions work, the values they get in, the values they give out, was a major topic of the September incubator call. +The most complicated bit of how this really works is that the second-from-bottom line on the slide, you see the constructor being called and it has a `functions` option passed in. When it’s used in the message that’s being formatted, it ends up being able to work as a selector based on the return object having a selectKey method on it. The boolean value, though, you could theoretically pass on from one declaration to the next if you need to. Particularly, the shape of how these message functions work, the values they get in, the values they give out, was a major topic of the September incubator call. One thing to note is that this is what it looks like when we hit an error condition. You see in the previous example `true` is passed in, and we have the “you have the thing” variant of this message. If there are no parameters that are passed in, or if the exists value is not defined, we end up with a situation where the exists selector doesn’t work, because the variable isn’t available, therefore you can’t select on it, which defaults into this * catchall situation. @@ -96,7 +96,7 @@ The question I’d like to be asking here, and then hopefully in a few weeks in SFC: One thing is I feel like it’s not clear to me how hard Michael Ficcara’s concern is on the DSL. I agree we shouldn’t have a syntax we’re referencing until we have a stable syntax. Discussing how stable it needs to be is a good discussion to have with Michael Ficarra and others who share his concerns. So are we okay with a compromise that involves not having the syntax? However, I don’t want to do that prematurely. -Second thing, I think the proposal is less motivated without the syntax, in the sense that it seems that in large part the thing the proposal brings to the table is being able to handle the processing of message format strings. If we say that we’re only processing the data model version of the message string, then you still have to carry a message syntax parser. +Second thing, I think the proposal is less motivated without the syntax, in the sense that it seems that in large part the thing the proposal brings to the table is being able to handle the processing of message format strings. If we say that we’re only processing the data model version of the message string, then you still have to carry a message syntax parser. So is this proposal motivated by the things we use to evaluate proposals at stage 2: @@ -114,7 +114,7 @@ EAO: One significant benefit for including the data model is the fact that right SFC: To respond to DLM, it’s a good precedent for us to approach Intl proposals, especially library-focused, as having an implementation first, or a polyfill, so that we can more easily demonstrate how the proposal works. I do think when we start with spec-first, the way we’ve largely been developing proposals, sometimes we miss some of these corner cases. And it’s good practice to have a polyfill. However, I don’t think we should gate advancement on having a certain number of downloads, or other metrics, and especially in the case of MF I think this is a “if we build it they will come” type of proposal: if the Intl library defines a message syntax, people are much more motivated to using that syntax. If it’s just another `npm` library, it’s less motivating for users to adopt. I do think it’s not necessarily harmful for us to develop the proposal and also the polyfill alongside it, and once it’s ready – “ready” is a discussion we should have with Michael Ficarra and others who are concerned – that’s when we can look to advance it to stage 2 / bring it into the standard library. -USA: After we briefly discussed the issue yesterday, I do feel if we explain the context better to various people in TG1 who’ve missed out how much we’ve deliberatted about this, they will be more understanding. For an outsider, to see the repo of the Unicode working group we have, it can be quite chaotic. So as DLM pointed out, they have a fair point in that the actual DSL isn’t stable yet, but that doesn’t need to be true for stage 2 anyway, since that’s happened many times in the past (for example, the serialization format we used in Temporal). Given the context, given that MF’s been developed with various stakeholders, +USA: After we briefly discussed the issue yesterday, I do feel if we explain the context better to various people in TG1 who’ve missed out how much we’ve deliberatted about this, they will be more understanding. For an outsider, to see the repo of the Unicode working group we have, it can be quite chaotic. So as DLM pointed out, they have a fair point in that the actual DSL isn’t stable yet, but that doesn’t need to be true for stage 2 anyway, since that’s happened many times in the past (for example, the serialization format we used in Temporal). Given the context, given that MF’s been developed with various stakeholders, DLM: To clarify, I’m not saying we should gate proposals on number of downloads, I just think it would be good evidence for stage 2. And I do think the parser is a core part of the proposal: I would rather wait for the parser instead of removing it to get to stage 2 right now. @@ -122,7 +122,7 @@ EAO: What I’m leading up to here is the core question I have presenting this t USA: I do think that it would be a good idea for this meeting, in February, instead of going for stage advancement right away to go to a stage update and focus the presentation half and half on the current progress, the stability we’re going for, [?] is nearly settled, and present these things, the past context, and then two months is not a massive delay. We here (Michael and Kevin, both quite active members of the committee), I think it would be nice to have a temperature check of the plenary at large. Such a presentation and the discussion after it could reveal if they’re in the minority, or if it’s an opinion that’s more widely held. -SFC: I think we should definitely have a TG1 presentation, and I think it’s worthwhile asking some of these questions at TG1. I don’t think we’re going to get to stage 2 this meeting, and I don’t think we should necessarily try for that: I would like to Unicode to stamp the syntax as being finalized before we ask for stage 2, and then once it’s finalized and there’s enough implementations of it – one thing I said on the issue is that the ECMAScript stage 2 should be gated on the Unicode proposal being stage 3 (or stage 3 equivalent). The other thing I wanted to say is that I don’t think it’s a good use of our time in TG2 to have that discussion, because we can pontificate as much as we want about this, we are not actually the decision-makers. It’s more useful in TG2 to have discussions like “what’s the shape of the API” and the error handlers and such. +SFC: I think we should definitely have a TG1 presentation, and I think it’s worthwhile asking some of these questions at TG1. I don’t think we’re going to get to stage 2 this meeting, and I don’t think we should necessarily try for that: I would like to Unicode to stamp the syntax as being finalized before we ask for stage 2, and then once it’s finalized and there’s enough implementations of it – one thing I said on the issue is that the ECMAScript stage 2 should be gated on the Unicode proposal being stage 3 (or stage 3 equivalent). The other thing I wanted to say is that I don’t think it’s a good use of our time in TG2 to have that discussion, because we can pontificate as much as we want about this, we are not actually the decision-makers. It’s more useful in TG2 to have discussions like “what’s the shape of the API” and the error handlers and such. DLM: I agree with USA and SFC, I think it’d be helpful to do a stage update at this point and get a feeling whether most of the committee is in agreement with Michael and Kevin, or if they’re a minority opinion. @@ -134,7 +134,7 @@ EAO: I appreciate that. I think one of the core questions is to define, or to as SFC: What EAO said is a good summarization of the question we should be asking. I was wondering if there were other questions we wanted to discuss here, or is the question of how to phrase the question about syntax stability the main question on the table for today. -EAO: I would like to be discussing more of the details of the proposal, but given that the meta-level has been discussed so thoroughly, that overrides all other concerns. I would be very happy for other people than DLM and USA to review the spec language of this and look more deeply into the feature it includes and the complexities there. I have glossed over things, of course, because this is a brief presentation, but if people have concerns I would be happy to dive more deeply into any of these details. Without input on concerns people have, it’s hard to raise technical questions for our consideration here. +EAO: I would like to be discussing more of the details of the proposal, but given that the meta-level has been discussed so thoroughly, that overrides all other concerns. I would be very happy for other people than DLM and USA to review the spec language of this and look more deeply into the feature it includes and the complexities there. I have glossed over things, of course, because this is a brief presentation, but if people have concerns I would be happy to dive more deeply into any of these details. Without input on concerns people have, it’s hard to raise technical questions for our consideration here. SFC: Thank you for that. I think we can go ahead and skip back up to status updates. After that we’ll take a short break and do the three open issues in the agenda. @@ -156,11 +156,11 @@ TG2 approval; will bring to TG1. https://github.com/tc39/agendas/pull/1513 add t https://github.com/tc39/ecma402/issues/806 -SFC: The question for FYT and YSK: Firefox is already using modern ids for default timezone, and v8 and JSC are not. The question is: what’s in the way, or is there any change we need to make, in order to have the three engines be consistent about default timezone? The example here is that if you get new.Intl.DateTimeFormat.resolvedOptions().timeZone, there are problematic ones. +SFC: The question for FYT and YSK: Firefox is already using modern ids for default timezone, and v8 and JSC are not. The question is: what’s in the way, or is there any change we need to make, in order to have the three engines be consistent about default timezone? The example here is that if you get new.Intl.DateTimeFormat.resolvedOptions().timeZone, there are problematic ones. -YSZ: I think Buenos Aires has three components instead of two, but let me check. +YSZ: I think Buenos Aires has three components instead of two, but let me check. -SFC: Here’s an example: I set my time zone to Ho Chi Minh and I get "Asia/Saigon" back. Firefox gives Ho Chi Minh, Chrome gives Saigon. +SFC: Here’s an example: I set my time zone to Ho Chi Minh and I get "Asia/Saigon" back. Firefox gives Ho Chi Minh, Chrome gives Saigon. ``` // Case 1 (DefaultTimeZone is Indochina time) @@ -188,7 +188,7 @@ SFC: The question is whether we can make the user’s timezone use the canonical FYT: so if user’s set to Asia/Saigon, it should return Asia/Ho_Chi_Minh? So we always canonicalize when we’re in default. But why does that matter? What’s the impact? Of course we can talk about that, but how would that be important in terms of the whole thing? Why do we need to do it earlier? What benefit will this bring to the developer? -SFC: Justin’s position is that this is a bug, and that we’ve established that it’s a bug, and his proposal got to stage 3 with the understanding that that’s a bug we’d like to fix. When we got to stage 3 we merged it in with Temporal. Justin’s argument is that we return the modern ID for the default timezone. +SFC: Justin’s position is that this is a bug, and that we’ve established that it’s a bug, and his proposal got to stage 3 with the understanding that that’s a bug we’d like to fix. When we got to stage 3 we merged it in with Temporal. Justin’s argument is that we return the modern ID for the default timezone. FYT: If it’s a bug, it’s a bug: we don’t have disagreement on that. The question is whether on each browser is when will they have time to fix that bug? @@ -196,7 +196,7 @@ SFC: And should we have test coverage for it? HJS: Testing right now, both Firefox and Chrome, both canonicalize to different versions. It seems like a new bug if resolvedOptions canonicalize. [..] Point 2 is that since Firefox has been returning these modern values, they seem to be sufficiently web-compatible. -HJS: There may be a misunderstanding of what you’re proposing. As I understood what SFC said, or what SFC said you said, you were proposing what the resolvedOptions for default time zone gives to change potentially out of sync with changing the canonicalization of putting in explicitly one of these name-changed cities and then taking out of resolvedOptions? The point I’m making is that resolvedOptions should be consistent in both cases. +HJS: There may be a misunderstanding of what you’re proposing. As I understood what SFC said, or what SFC said you said, you were proposing what the resolvedOptions for default time zone gives to change potentially out of sync with changing the canonicalization of putting in explicitly one of these name-changed cities and then taking out of resolvedOptions? The point I’m making is that resolvedOptions should be consistent in both cases. JGT: My understanding of what was approved for Temporal as part of the proposal approved by plenary two or three meetings ago, the canonicaltz proposal, is that if the user supplies a particular ID, we shouldn’t change it – adjust the capitalization, because that’s important, but (for example) asia/saigon should give back asia/saigon, asia/ho_chi_minh should give back asia/ho_chi_minh. As far as defaults, that's a tough one because there are multiple values. I think right now Firefox is returning the right one, and the wrong one in Chrome/Safari. The proposal is to switch to the modern one. In default, it has to choose: there’s no way for it to know which the user would pick. But if the user supplies it, we should keep it the same and stop canonicalizing the results. @@ -208,7 +208,7 @@ SFC: This is what we decided in terms of the Temporal proposal. My understanding JGT: To clarify: if we change what default time zone returns, we should also change the canonicalized value. Is that the point? -HJS: Yes. My point is that if the default gives you a value that’s not what the canonicalization, if you put it as an explicit argument, if that changes from what you’ve gotten as a default, that’s really weird. +HJS: Yes. My point is that if the default gives you a value that’s not what the canonicalization, if you put it as an explicit argument, if that changes from what you’ve gotten as a default, that’s really weird. SFC: In other words: @@ -227,13 +227,13 @@ JGT: My understanding is that 1, 2, and 3 all return Ho Chi Minh in Firefox. EAO: I was just going to say that my recollection of what we discussed previously is that, I have not reviewed the minutes. -YSZ: Because this information is updated in the IANA database, basically when we apply this to our engine, or OS, is not necessarily guaranteed. Even if we introduce this into the spec, that doesn’t mean we can’t use the modern version. All browsers don’t adhere if the IANA database was updated five minutes ago, or something. So we’ll need to have a Temporal.equals type function to check both input. I can’t see if always requiring the modern id in the spec solves an actual problem or not. +YSZ: Because this information is updated in the IANA database, basically when we apply this to our engine, or OS, is not necessarily guaranteed. Even if we introduce this into the spec, that doesn’t mean we can’t use the modern version. All browsers don’t adhere if the IANA database was updated five minutes ago, or something. So we’ll need to have a Temporal.equals type function to check both input. I can’t see if always requiring the modern id in the spec solves an actual problem or not. -HJS: I confirmed that Firefox, at least on Mac, in case 1 returns Ho Chi Minh. Mac doesn’t allow me to set system timezone to Saigon; only Ho Chi Minh exists. As an additional observation, Kyiv is a city that has a Finnish name, and Tallinn, and Mac (version) knows the Finnish name for Tallinn, but not Kyiv. So the change to the English name has a mismatch in localization. +HJS: I confirmed that Firefox, at least on Mac, in case 1 returns Ho Chi Minh. Mac doesn’t allow me to set system timezone to Saigon; only Ho Chi Minh exists. As an additional observation, Kyiv is a city that has a Finnish name, and Tallinn, and Mac (version) knows the Finnish name for Tallinn, but not Kyiv. So the change to the English name has a mismatch in localization. -JGT: Responding to YSZ, there are two cases. Changes that happened a long time ago, like Kolkata, then there’s new ones, the next example of Kyiv or Kolkata. For the first case it’s easy, we can just agree across implementations saying ‘this is when we make the change’, and then in a few weeks we’ll have switched. But not everyone is going to switch at the same time – honestly there are disruptions today, between Firefox and other browsers. I am now convinced that the safest web compatibility approach is to wait until Temporal is finished, so that users who want that canonicalization behavior can get it. Another six or nine months doesn’t make a sense. However, it’s also causing discontent – I don’t think it a be a hugely disruptive thing to change Calcutta/Kolkata, Kiev/Kyiv. +JGT: Responding to YSZ, there are two cases. Changes that happened a long time ago, like Kolkata, then there’s new ones, the next example of Kyiv or Kolkata. For the first case it’s easy, we can just agree across implementations saying ‘this is when we make the change’, and then in a few weeks we’ll have switched. But not everyone is going to switch at the same time – honestly there are disruptions today, between Firefox and other browsers. I am now convinced that the safest web compatibility approach is to wait until Temporal is finished, so that users who want that canonicalization behavior can get it. Another six or nine months doesn’t make a sense. However, it’s also causing discontent – I don’t think it a be a hugely disruptive thing to change Calcutta/Kolkata, Kiev/Kyiv. -The second is the next case. Changes happen rarely, about every two years. In the current spec text in Temporal, the version approved in plenary, is that there should be a recommended waiting period for two years from the time when the rename happens and the canonical value inside the spec changes, making it easier for implementers to sync up all those changes, and people whose software expect one thing can adapt to a new identifier turning up. What we saw last time is that when names change, a new ID was introduced at the same time. Unlike today, where we have both Calcutta/Kolkata, we know. With Kyiv, though, Firefox switched to Kyiv at the same time as the switch. If I get Kyiv as the default time zone and send it to someone else, they won’t necessarily know about it. So the idea is that when default time zone returns that value, nobody fails. +The second is the next case. Changes happen rarely, about every two years. In the current spec text in Temporal, the version approved in plenary, is that there should be a recommended waiting period for two years from the time when the rename happens and the canonical value inside the spec changes, making it easier for implementers to sync up all those changes, and people whose software expect one thing can adapt to a new identifier turning up. What we saw last time is that when names change, a new ID was introduced at the same time. Unlike today, where we have both Calcutta/Kolkata, we know. With Kyiv, though, Firefox switched to Kyiv at the same time as the switch. If I get Kyiv as the default time zone and send it to someone else, they won’t necessarily know about it. So the idea is that when default time zone returns that value, nobody fails. EAO: I just though I’d mention that the reason and rationalization for timezone.equals exists independently of all of the rest of Temporal. Of course if it’s landing in six months or nine months, it makes sense to keep it there, but since Temporal has been slow in getting over the finish line, I would consider timezone and timezone.equals as a standalone proposal to help with this and similar matching. @@ -249,19 +249,19 @@ JGT: There’s about 20 of these, but the three that matter – that have sizabl SFC: I don’t expect we’re ready today, necessarily, to make that call, but the request now that we have clarity is for FYT and YSZ [...] -FYT: Every time we make a change, there are risks. Knowing that eventually Temporal will change one way, the question is whether the risk of making a change right now has a good ROI. In other words, we know we're going to change to another place. Changing right now to a second place… does that really help? Is it worth it for the effort to deal with the risk? It's not easy… it's a pretty big change in terms of the behavior. Some users may cry out and say, this works, revert! And that could cause engineering time. If this is the final result, that's good justification to make the change. But already knowing that this is not the end result, I would be concerned to make that effort. If it is clear that if we don’t do it now it would cost 100 times more than later, then we could justify, but unless we have that, if there’s no strong reason to change now, that’s a good reason to not change now. That’s what I’m waiting for, a strong reason to change it now. - +FYT: Every time we make a change, there are risks. Knowing that eventually Temporal will change one way, the question is whether the risk of making a change right now has a good ROI. In other words, we know we're going to change to another place. Changing right now to a second place… does that really help? Is it worth it for the effort to deal with the risk? It's not easy… it's a pretty big change in terms of the behavior. Some users may cry out and say, this works, revert! And that could cause engineering time. If this is the final result, that's good justification to make the change. But already knowing that this is not the end result, I would be concerned to make that effort. If it is clear that if we don’t do it now it would cost 100 times more than later, then we could justify, but unless we have that, if there’s no strong reason to change now, that’s a good reason to not change now. That’s what I’m waiting for, a strong reason to change it now. + JGT: I'm convinced by FYT's point in the sense that this is not as disruptive as other changes, but it will be disruptive. I think just optically it will be easier to change things once, and if we have Temporal in place at the time that that changes, it’ll be easier to convince users that it’s a good thing – we’re making this change in order to support this new date/time API which will do good things for you, that smooths the process. If we were getting thousands of complaints and a global boycott from everyone in Ukraine, then I can see it, but without a compelling thing it makes sense to wait. EAO: I was going to say that I don’t think the bar for this should be a national-level boycott, or otherwise, these people have changed the names of their cities, most often to something that is not an imperial name for their city from a colonizing body, and I think there is a strong moral case to be made for honoring the choice these people have made about the name of their timezone. I am happy that Firefox is doing what it’s doing, I’d be happier if it wasn’t just Firefox doing what it’s doing. -JGT: To respond to EAO, I totally agree with you – it’s the whole reason I spent months on this proposal, and it’s our obligation as i18n people to honor the wishes of people around the globe. It may be less disruptive to stop canonicalizing and +JGT: To respond to EAO, I totally agree with you – it’s the whole reason I spent months on this proposal, and it’s our obligation as i18n people to honor the wishes of people around the globe. It may be less disruptive to stop canonicalizing and -If I’m already calling it calcutta and my tests are saying calcutta, I’m going to get calcutta back. People expecting the behavior of sending Kolkata and getting Calcutta, those people would be disrupted. I think it’s fine to wait, but if some reason Temporal gets stalled – say they need to put in a year worth of work on it – then we can reconsider. +If I’m already calling it calcutta and my tests are saying calcutta, I’m going to get calcutta back. People expecting the behavior of sending Kolkata and getting Calcutta, those people would be disrupted. I think it’s fine to wait, but if some reason Temporal gets stalled – say they need to put in a year worth of work on it – then we can reconsider. SFC: My comment is that we’re really slow-moving, and saying “this could land one to two years from now”, that’s pretty fast. Our job as a standards body isn’t to be the first people to adopt a change, it’s to be the last. We’ve discussed this issue three or four times already in this group. I brought it up for the discussion of the question should be make a change before Temporal, and I’m happy if the answer is no. I think 2024 is a year we have more headroom to make progress on Temporal, more than 2023, so I’m optimistic that the timeline for fixing this problem the way we want to fix it is close enough in standards timelines that we should do that. -FYT: I have a different view about this type of changes: it’s often not about the people but about some politician with an electoral agenda. I do think we should change it, but if we change it to another direction and then go to a 90 degree angle to do that, that’s the question. I do believe we have to change it and respect national bodies to do the change, but will the people really be impacted that much? +FYT: I have a different view about this type of changes: it’s often not about the people but about some politician with an electoral agenda. I do think we should change it, but if we change it to another direction and then go to a 90 degree angle to do that, that’s the question. I do believe we have to change it and respect national bodies to do the change, but will the people really be impacted that much? #### Conclusion @@ -287,17 +287,17 @@ BAN: That's my concern also; I can't think of use cases for the cash rounding th SFC: I agree that we don’t want to be the data source for law. I don’t like that we do any rounding at all for monetary values: I’ve been concerned that if you create a NumberFormat with a currency style that we round off digits that the user provides for us (say a unit of gas is listed as 3.599, that presents as 3.60). I’ve always been bothered by that, and this exacerbates the problem further. Monetary values should not be something you round at the last second for display to the user. That might be appropriate for road distances or something like that, but rounding currencies is not a thing we should be in the business of doing in the first place. -SFC: Another point is that it may be useful to expose an API that only exposes the currency rounding directly. If we did want to be the data source – I don’t think we should – we could have a currencyInfo API, instead of having it be NumberFormat formatting options in the first place. +SFC: Another point is that it may be useful to expose an API that only exposes the currency rounding directly. If we did want to be the data source – I don’t think we should – we could have a currencyInfo API, instead of having it be NumberFormat formatting options in the first place. -EAO: Given that we do have this current behavior of rounding – if you set a currency you get a specific sort of rounding – and given that it’s current web reality, it’s unlikely we’re able to get rid of it. So this sounds to me like there’s a good use case for NumberFormat to be able to display to the user the actual numeric value, if rounding has occurred or otherwise? Or should we expect the user to understand that they should formatToParts and then reconstruct the value from there. That sounds unlikely for a developer to be using, though actually getting the value out of what has been displayed to the user could be useful from an online banking or a shopping POV. +EAO: Given that we do have this current behavior of rounding – if you set a currency you get a specific sort of rounding – and given that it’s current web reality, it’s unlikely we’re able to get rid of it. So this sounds to me like there’s a good use case for NumberFormat to be able to display to the user the actual numeric value, if rounding has occurred or otherwise? Or should we expect the user to understand that they should formatToParts and then reconstruct the value from there. That sounds unlikely for a developer to be using, though actually getting the value out of what has been displayed to the user could be useful from an online banking or a shopping POV. -HJS: I’m looking at CLDR JSON here as far as I can tell the domain modeling is not right, so the rounding behavior is attached to currencies rather than regions, and as EAO said there are these rules in Finland, but as I understand it that’s not Euro-wide rules. Other jurisdictions have 1 and 2 cent coins, but when Finland adopted the euro they went with 5 cents. Attaching the behavior to the currency is incorrect domain modeling. +HJS: I’m looking at CLDR JSON here as far as I can tell the domain modeling is not right, so the rounding behavior is attached to currencies rather than regions, and as EAO said there are these rules in Finland, but as I understand it that’s not Euro-wide rules. Other jurisdictions have 1 and 2 cent coins, but when Finland adopted the euro they went with 5 cents. Attaching the behavior to the currency is incorrect domain modeling. SFC: Proposal: The problem – the bug we’re trying to fix, #134 – is that we want to use a better source for these currency digits, and we think CLDR is better. Given that we already round currency values by default in NF, and we think there’s an answer that’s better for users on the web, perhaps we should change it to fix up Intl.NF giving a source, and if you want to use a different data source you can do it yourself and give a specific number of decimal units. If we were to flag “use cash rounding or use this source”, the use case is narrow and it’s not motivated to add it. NFv3 adds support for nickel rounding, which means they can specify it if they want. But we should, maybe, focus on the original problem: the current behavior for NF is not great. We could talk with the CLDR committee on that data source. BAN: So say that this is recommended but don't give a way for users to choose between cash rounding and financial rounding. -SFC: Or just say “the behavior of 402 is financial rounding” and document it better. +SFC: Or just say “the behavior of 402 is financial rounding” and document it better. BAN: Give that we currently have rounding… the original issue was that some currencies have rounding that goes to digits only used in financial institutions. That's the version currently required, and that gives more digits than what CLDR gives. And given the sense that we're worried about rounding currencies in the first place, maybe we just define that we just do financial rounding. @@ -319,7 +319,7 @@ EAO: So something like an Intl.NumberFormat that you’re asking to format a num SFC: The API that returns a formatted value should return a decimal, since an decimal is the closest thing in the JavaScript ecosystem to what it really is. That’s what it should be returning. One catch: the decimal type doesn’t support whether not you’ve chosen to use scientific notation or not, but that may be a thing we need to carry on the side. But for cases where you’re not using scientific notation, that’s the closest thing we have – decimal is a DecimalList, which is why we should be using it for this type. -EAO: I see. We need more discussion, and this is not something we need to decide on for San Diego. +EAO: I see. We need more discussion, and this is not something we need to decide on for San Diego. #### Conclusion diff --git a/scripts/auto-deploy.sh b/scripts/auto-deploy.sh index 1ade0639..89d3318c 100755 --- a/scripts/auto-deploy.sh +++ b/scripts/auto-deploy.sh @@ -33,4 +33,4 @@ $(npm bin)/update-branch --commands "npm run build-ci" \ --commit-message "Update gh-pages [skip ci]" \ --directory "out" \ --distribution-branch "gh-pages" \ - --source-branch "master" + --source-branch "main"