From 8ad694a98c6879c1d93f907bbb18e84ab5330242 Mon Sep 17 00:00:00 2001 From: "Shane F. Carr" Date: Thu, 7 Sep 2023 13:38:27 -0700 Subject: [PATCH] Create notes-2023-09-07.md --- meetings/notes-2023-09-07.md | 474 +++++++++++++++++++++++++++++++++++ 1 file changed, 474 insertions(+) create mode 100644 meetings/notes-2023-09-07.md diff --git a/meetings/notes-2023-09-07.md b/meetings/notes-2023-09-07.md new file mode 100644 index 00000000..3cf0fa7f --- /dev/null +++ b/meetings/notes-2023-09-07.md @@ -0,0 +1,474 @@ +# 2023-09-07 ECMA-402 Meeting + +## Logistics + +### Attendees + +- Shane Carr - Google i18n (SFC), Co-Moderator +- Daniel Minor - Mozilla (DLM) +- Louis-Aimé de Fouquières - Invited Expert (LAF) +- Ben Allen - Igalia (BEN) +- Eemeli Aro - Mozilla (EAO) +- Yusuke Suzuki - Apple (YSZ) +- Richard Gibson - OpenJS Foundation (RGN) +- Chris de Almeida - IBM (CDA) +- Frank Yung-Fong Tang - Google i18n, V8 (FYT) +- Justin Grant - Invited Expert for Temporal (JGT) +- Zibi Braniecki - Amazon (ZB) +- Myles C. Maxfield - Apple (MCM) + +### 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) +- [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) + +## Status Updates + +### Updates from the Editors + +RGN: I've been getting things ready for the upcoming plenary. I merged Frank's 768 follow-up. Had some back-and-forth with Ben. Most of the clarifications we had at our last meeting are pretty much ready to go. + +BEN: Anba has migrated all of 402 to structured headers! + +### Updates from the MessageFormat Working Group + +EAO: The workflow is in decent shape and progressing. We are having a MFWG face-to-face in Seville adjacent to TPAC. + +### Updates from Implementers + +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. + + +## Proposals and Discussion Topics + +https://github.com/tc39/ecma402/projects/2 + +### Normative: Move numberingSystem before style in resolvedOptions + +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. + +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. + +FYT: Any objection? + +SFC: Explicit support? + +LAF: +1 + +BEN: +1 + +DLM: +1 + +YSZ: +1 + +FYT: We have to put this on the TC39 agenda, we need the champion to give an update. + +SFC: I could do the update if necessary. + +#### Conclusion + +Approved by this group. + +### Normative: Don't output "fractionalDigits" when the value is undefined #167 + +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. + +LAF: +1 + +BEN: +1 + +SFC: Are these normative changes for Intl.DurationFormat tracked in Test262? + +FYT: There are tests, but we’ll have to change them to conform with this change. Current tests will break with spec change. + +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. + +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. + +JGT: +1 + +YSZ: +1 + +#### Conclusion + +Approved by this group. + +### New proposal: Define the behavior and properties of the “und” root locale + +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. + +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. + +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” + +YSZ: I think my comment would be with SFC, but one thing I’d like to mention that as SFC said, the ‘en’ locale is not stable across the platform anyway. When we use a narrow format, for example, for duration or a time, in normal CLDR it uses ‘m’ for month and minute, but AppleICU/CLDR uses “mo” for months. This is aligned with each platform’s convention, the concern is if we say “just use ‘en’ locale of CLDR as a fallback”, that doesn’t work because it’s already different. Let’s specify each behaviour very precisely instead of just saying “current CLDR root” or something. + +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. + +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: 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". + +RGN: I think using "zxx" is fine. "null" locale might have a certain shape. "generic" locale is another name that might not have baggage. + +ZB: My only question about this, EAO, is have you considered how much you want to propose this as an Intl API surface? One thing, no matter how open you go with this proposal, is that you are presenting it as a Stage 1 Internationalization API. What I suspect is happening here is that you’re looking for a date formatting API and a number formatting API, and other formatting APIs, but by phrasing it as a proposal from ECMA-402, unless we’re careful we’re locked into the idea that the solution should be in the scope of ECMA-402 + +SFC: Regarding naming, we should focus on the problem we’re solving when we think about the name. The problem is listed under “Motivation”. I think we should call it something like “stable formatting proposal”, something like that? Leave the mechanism as a separate question. To address ZB’s point, is it an Intl problem? It is in the sense that the goal is that we have these Intl APIs that people want to use in ways that require stability, if you’re not convinced about the motivation we should continue to dive deep into the motivation. I feel the motivation is strong enough that it’s motivated for stage 1, if there are problems with motivation leave that for stage 2, and it’s enough in the Intl space that we should keep it as a 402 proposal. + +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. + +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? + +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. + +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. + +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 + +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. + +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. + +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: (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 + +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. + +### Intl.MessageFormat Stage 1 Update + +- Proposal: https://github.com/tc39/proposal-intl-messageformat +- Refactor PR: https://github.com/tc39/proposal-intl-messageformat/pull/22 +- 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. + +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). + +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. + +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. + +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. + +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. + +RGN (via chat): formatRangeToParts methods in e.g. NumberFormat also have substructure, but they still flatten and add `source` properties + +``` +$ node -p 'new Intl.NumberFormat("en", {notation:"engineering"}).formatRangeToParts(100, 1000)' +[ + { type: 'integer', value: '100', source: 'startRange' }, + { type: 'exponentSeparator', value: 'E', source: 'startRange' }, + { type: 'exponentInteger', value: '0', source: 'startRange' }, + { type: 'literal', value: ' – ', source: 'shared' }, + +``` + +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: 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, BEN?) 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 + +https://github.com/tc39/ecma402/pull/780 + +LAF: Can you clarify what you mean by the impact on fingerprinting? + +BEN: i18n and privacy is fundamentally difficult. + +DLM: Is this going to TG1? + +SFC: Yes that's the plan + +MCM: In this fake download, I assume it is asynchronous. If code tries to observe the effects of the locale that is being fake-downloaded, will it be able to observe those effects? + +SFC: The normative text is about making users not "distinguishable". Whatever is needed for that to happen is yet to be set in stone since no browsers currently implement it. + +DLM: This is good to go to plenary. + +#### Conclusion + +Okay to send to TG1. + +### Normative: Allow UTC offset time zones #788 + +https://github.com/tc39/ecma402/pull/788 + +SFC: Bringing us up to speed, because we’ve discussed this multiple times. We had a very lengthy discussion in June on this where the resolution was that we’re not aligned on the precision that should be allowed, since that time Temporal has made a decision. Maybe JGT or RGN can bring us up to speed on that decision. + +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. + +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. + +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. + +JGT: It’s important to call out that there’s different kinds of time zones. There’s named ones, like Europe/Paris. There’s offset timezones, which are statically-defined offsets that can be put into an ISO 8601 string. In the first case it’s whatever we get from the timezone database. It is possible that Date, legacy Date in JavaScript, might be limited to minutes, but in Temporal you can get seconds. That said, for offset time zones we have decided that – well, okay, the only reason offset timezones exist is for cross-compatibility with Java – so it’s really an interoperability reason that we support that. Offset timezones are rare, seconds are rare, the overlap between them might be null. So this is about making sure that 402 and Temporal are aligned, so that everything in Temporal can be formatted in 402. If you have a real timezone, like Paris or Amsterdam, you can get the full precision. + +LFS: In terms of the use cases it’s only if you deal with historical data. I’m not sure it’s an extended case here in JavaScript. + +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. + +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. + +SFC: I think that the main thing we’re looking at from this group is what is the precision, and I think we can all agree that that’s the precision that Temporal specifies (minutes), but there’s also the case that this PR hasn’t been updated so we can’t approve it here. + +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. + +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. + +RGN: I can take that on no problem, I’ll replace it with assertions. Now, parseTimeZoneOffsetString() in 262 might actually support nanoseconds precision. + +JGT: If I recall correctly that AO is used to parse all offsets, and can be used for nanoseconds. There may be some refactoring that we can do to simplify this. + +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. + +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. + +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. + +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. + +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. + +FYT: Yes, I'd like to see the updated PR before TG1. + +FYT: It would be helpful in the PR description if JGT could add some JavaScript code to illustrate what time zone strings will be acceptable that were previously not acceptable. + +#### Conclusion + +Tentatively approved, pending updated spec text. + +### Unicode Technology Workshop + +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. + +### Possible forward-compatibility issue in Intl.Locale.prototype.getTimeZones()? #73 + +https://github.com/tc39/proposal-intl-locale-info/issues/73 + +FYT: We have a naming issue with this one. What Anba is interested in is that we have two timezone ideas, one supported by 402, one supported by UTS 35, we’re trying to ensure that there’s no name collisions. But the question remaining is that should we change this from getTimeZones to getTimeZoneIDs. Anba has a question, though: what about calendars? Should it be calendarID? But Temporal doesn’t have that. In my preference in Stage 3 proposals it shouldn’t be easily changed, but we’ve already changed it a couple of times after Stage 3. Should we change the name, or not? And if we do, should we only change timeZones, or should we also change calendar? + +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. + +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. + +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. + +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. + +#### Conclusion + +Close the issue. + +### Consistent "region" subtag requirements for getTimeZones() and getWeekInfo()/getHourCycles() #71 + +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. + +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. + +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. + +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. + +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. + +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. + +SFC: I’m fine for empty array. + +FYT: What’s the difference? Why not keep it undefined? + +JGT: I think SFC’s point is that it simplifies TypeScript definitions. But let me consider – if undefined is an acceptable response, TypeScript — + +SFC: My point is that if any of this code is assuming it’s getting an array, we can call map functions, we can use for of. Is empty array falsy? I guess not, so you’d have to call .length on it. + +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. + +JGT: We don’t fix anything. + +SFC: You had previously +1ed UTC, how do you feel? + +EAO: I don’t feel strongly either way. + +LAF: +1 to undefined + +#### Conclusion + +Keep undefined + +## Overflow Items + +The following items were discussed after the end of the official time slot. + +### Add support for -u-fw and other Unicode extensions that could impact the result #68 + +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? + + +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. + +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). + +JGT: +1 for C + +LAF: +1 for C + +JGT: +1 for C + +SFC: I’ve gone back and forth on this, we’ve tended to be lenient lately. + +#### Conclusion + +Tentative agreement on option C. + +### Update on Locale Extensions + +https://github.com/ben-allen/locale-extensions + +- Slides: https://drive.google.com/file/d/1gry4GFNPhzV42ezJ4ArtF5RHA9z6EETA/view + +BEN: (summarizes the updated README) + +DLM: Support getting feedback from the W3C group. But getting it on the agenda for Tokyo also gives me something to point to. + +EAO: About the US having a peculiar set of standards, something that might help is making en-001, international english, be more of a thing. + +LAF: "en-ZX" ? + +SFC: If we want to fix this only for en-US, there are some smaller, narrower solutions. The hope is that we can solve the slightly more general, but more impactful, problem of a user's regional preferences differing from their language preference.