- Shane Carr - Google i18n (SFC), Co-Moderator
- Ben Allen - Igalia (BAN)
- Daniel Minor - Mozilla (DLM)
- Eemeli Aro - Mozilla (EAO)
- Henri Sivonen - Mozilla (HJS)
- Yusuke Suzuki - Apple (YSZ)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
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.
SFC: Anba opened a large pull request in August, which has been bitrotting and I would like to see it be merged.
BAN: It would be great if others would review Anba's PR but I'm not super concerned with just merging it.
SFC: One other comment for editors: it’s getting close to when we should start thinking about ES2024 and the processes, so that we don’t do like we did last year and wait until the deadline has passed and have the ECMA people scream at us about not having the draft done on time, which means we need to be more proactive.
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.
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.
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
FYT: No recent 402 updates; been fixing security bugs in ICU. No big moves over christmas break.
EAO: none
https://github.com/tc39/ecma402/projects/2
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.
(missed some)
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.
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.
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.
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.
Here’s the thing that’s why I’m hurrying through all this. When I started proposing this earlier this week for the TC39 agenda, I got a couple of TC39 members responding to the issue mentioning the stage 2, stating that they are not necessarily comfortable with us bringing in any more DSL to JavaScript until it is very very stable. This means that the proposal in its current form might not be able to reach stage 4 until many years down the line. One possibility I’d like to discuss here is what if we left out the syntax? What if we didn’t support parsing input data, but required the input data to come in pre-parsed as a MessageData structure?
At a high level this means that we don’t solve the problem of expressing a message in source form, but only as a data structure. We also still include the runtime behavior and the function customizability.
The data structure here is a message data model that’s a byproduct of the MF2 work at Unicode. This is a data structure that’s capable, as far as we can determine, every message in any known format that currently exists. It’s relatively minimal in complexity, and it’s still extensible if/when new things come up. [see slide “messages as data”]. The pattern is the literal pieces, and then the placeholder. The annotations can be applied to the expression arguments, and they end up being structured like on the slide, and then the declarations have this own section that they end up reading if they’re included in the definition. These follow closely the expression style of what’s in them; this is coming in part because the data model is solving the problem of how MF2 message need to be represented, though this ends up being able to support the other extant formats. The pipe message has a different shape, because we want to know the selectors we’re doing the selection on and the variants, which are patterns for the type message.
The question I’d like to be asking here, and then hopefully in a few weeks in San Diego, is that is there a way we can take this to stage 2 now? Particularly, we have the question of whether we should hold the proposal in the shape it currently has, or should we be lifting out the MF2 syntax, if that would enable us to go for it now instead of many years from now. Let’s open the floor to discussion and questions
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.
So is this proposal motivated by the things we use to evaluate proposals at stage 2:
- Is it difficult to implement in userland?
- Is it going to have a wide impact / be useful for clients across the web (I think this one is true)
- Is there prior art? (it’s good to have a discussion before it’s stable)
I want to make sure we very clearly discuss all three of these points in the presentation. If the proposal becomes “we have an API that takes an AST and interpolates stuff into a string” it’s not clear to me that that’s as strongly motivated, since that’s something that seems to me that it could be implemented in a userland library, and a lot of people are going to need to be convinced that it’s not better implemented in a userland library.
EAO: Note that the data structure definition here is JSONifiable, which means that even with just the data model part of this it’s conceivable for a user with a client/server situation to do the parsing on the server side and then deliver the output as JSON, so there are benefits to that sort of approach. This doesn’t mean that in the client there’s necessary to be a syntax also
DLM: I also thought of pulling out the parsing part and advancing just the API itself to stage 2, and I can see people pushing back, saying this is just a library. I can still see the utility in this, but maybe I’m too close to the project: I was surprised about the pushback we’ve seen, but now I’m beginning to see where the concerns are coming from. So as devil’s advocate: what if the pushback is the right thing? Do we need this to be stage 2, do it in userland, come back when the Unicode MessageFormat spec is in stage 2, then say “so and so many people are using MessageFormatv2. Can we convince ourselves that there’s a real justification for this being stage 2? For me, the answer is “of course it’s ready for stage 2,” but if I step back and look at it from the POV of people on the committee, I can see where they’re coming from.
EAO: One significant benefit for including the data model is the fact that right now the space of localization in JavaScript is quite fractured. There are many different standards and specs for how to format messages, there are many different runtimes for how to do this, there are many challenges in passing messages from one place to another. Defining a data model description, the shape of a message to be formatted, can be really powerful as a unifying interface for messages, providing a way to transmit messages over the wire with a common understanding that this is what a message looks like, without the need for the consumer to parse that message. I find that benefit of it very intriguing, and that benefit would be much greater if it were indeed not a library but a core part of the language.
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,
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.
EAO: What I’m leading up to here is the core question I have presenting this today: should I be asking for stage 2 for this proposal now, and if not, should I be speaking with TC39 (or we be presenting on TC39) about this proposal and its history, and what it’s really all about?
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.
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.
EAO: That seems pretty conclusive. I’ll update the PR for the TG1 agenda to be an update instead of a stage 2 request, likely increasing the 45 minute time window, with a discussion of what is an appropriate process or what are the requirements for accepting a new DSL. If the comparison points are “it needs to be comparable to JSON or regexes” in terms of stability, we’ll need to come back and discuss. I would also appreciate assistance in reviewing, or even putting together, the presentation for TC39, since I’ll need to defend all of what we’ve been doing and that we’ve thought for four years that we can be doing these things, and we are potentially being told that that premise was false to start with.
USA: On the first one it’s a bit unfair to compare to JSON, since they’re very different formats for very different things, and the level of stability for JSON is more nuanced than just “hey, JSON has been the same forever.” Out in the wild people talk about extensions to JSON more than we see in plenary. There are reasons that we don’t want to touch JSON, but the same constraints / requirements don’t apply here. As for your call for volunteers, I’d be able to help out, and to defend our position in plenary.
EAO: I appreciate that. I think one of the core questions is to define, or to ask TC39, what is the minimum bar for a DSL to be supported? The understanding we have is that a stability reached in Unicode for MF2 would be sufficient to include in JavaScript, but what I understand Michael Ficarra to be stating is that that is not sufficient – even after achieving that nominal stability, it will take years before consideration is appropriate. And figuring out the actual view of TC39, where it sits in this spectrum, is necessary.
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.
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.
FYT: Last time there was a discussion about a missing of the canonicalization value from the report, and I volunteered to make the PR to amend it, talking about following the process for canonicalization. It’s a very text-based spec – I copied stuff from other places in ECMA 402 to make sure that the value is canonicalized. Basically, deferring to UTS 35 for that. I believe that’s already in ECMA 402 somewhere else, the same kind of text. The text used is the language from ResolveLocale, and I’m making sure this part is doing the same thing. We have review and confirmation from the bug reporter, but we need to agree on this, and then put it on the TG1 agenda I or BAN will bring it up to TG1. Questions?
SFC: LGTM
YSZ: +1
TG2 approval; will bring to TG1. tc39/agendas#1513 add to the agenda
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.
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)
new Intl.DateTimeFormat().resolvedOptions().timeZone
'Asia/Saigon' // Chrome
// Case 2
new Intl.DateTimeFormat("en", { timeZone: "Asia/Saigon" }).resolvedOptions().timeZone
'Asia/Saigon' // Chrome
// Case 3
new Intl.DateTimeFormat("en", { timeZone: "Asia/Ho_Chi_Minh" }).resolvedOptions().timeZone
'Asia/Saigon' // Chrome
YSZ: Related: https://bugs.webkit.org/show_bug.cgi?id=218542
FYT: There’s something, I don’t quite remember, somewhere in test262 the canonicalization has to be done whenever shipping Temporal. Otherwise, the user will not have the facility to do what they need to do. I thought that was blocking.
SFC: When it comes to the canonicalization of input timezones, that is the case, and we should not canonicalize them. However, this is about the default timezone. If I specify the timezone explicitly, it should not canonicalize. The behavior we’re not supposed to change (when timezone explicitly given). But when it’s the default timezone, that’s the thing we should be able to change. I wanted to test the waters and see if there’s anything wrong with this change.
FYT: Help me out here: so the default timezone is based on the user’s value, correct? And the users could specify either. We would have a possibility for both values to show up from the user’s default?
SFC: The question is whether we can make the user’s timezone use the canonical modern id, but not change if it’s given explicitly.
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.
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?
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.
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.
HJS: I thought we could keep the canonicalization on explicit input so that if you put in a city name, it would potentially change. What you said didn’t match what I thought was meant before, so I was responding to what I thought I heard and what you said was different. If what you said has been previously approved, then I was misunderstanding. I don’t understand why canonicalization should be removed when Firefox doing it seems to be sufficiently web compatible.
JGT: To respond to that, the approval was essentially – the big question remaining is timing: when do we do it relative to Temporal getting Stage 4. The reason to stop canonicalizing is because every time a name changes, it creates a lot of disruption for existing code that already relies on that code being the same. The idea is that we would stop that disruption: from the user standpoint, if they think this is the value we should agree with them, so long as it’s a valid value, and send it back. Regardless of whether we canonicalize to the old one or the new one, that changes what the user specifies. This stops this disruption from happening forever because we go with what the user said. However, if we stop canonicalizing, we have no way of verifying that two ids are the same. In Temporal there’s timezone.equals method, that will give you that, but that doesn’t exist today. So that’s why the question of delaying the timing until Temporal is available. I don’t have a strong opinion, but it is a valid concern.
SFC: This is what we decided in terms of the Temporal proposal. My understanding with why you filed #806 is that there’s something to change with web reality even before that. The concern was if we change it now, we can’t change it back, but until we get to that point this is the only place the web platform exposes canonicalization behavior, and we should not change that behavior. My question is what’s the thing we should change now, before Temporal lands, to be spec-compliant until the future we’ve already agreed on. My understanding, which could be wrong, is that we should change the default behavior and keep explicit timezone canonicalization the way it is.
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.
SFC: In other words:
- Current ChromeOS behavior: Cases 1, 2, and 3 all return Asia/Saigon
- Current Firefox macOS behavior: Cases 1, 2, and 3 all return Asia/Ho_Chi_Minh
- Behavior after Temporal lands: Cases 1 and 3 returns Asia/Ho_Chi_Minh; Case 2 returns Asia/Saigon
- Proposed behavior in the interim: Cases 1, 2, and 3 all return Asia/Ho_Chi_Minh in all browsers
Is that correct?
FYT: Question: so this is assuming the default is set by the user to Asia/Saigon, right?
SFC: Yes. It doesn’t matter, because they’re the same (indochina time, which is what my OS selector made available)
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.
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.
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.
SFC: I guess my next comment is, I just want to have a conclusion for this topic, and I think the conclusion is that we’ve already discussed and don’t need to discuss what the final behavior is. I want JGT to verify that what I have for the behavior is correct. Are we proposing that YSK and FYT need to do some work, or is it okay to keep the status quo where the browsers have different canonical forms and wait until Temporal is ready. I want to be clear what the proposal we’re actually discussing right now is.
JGT: To respond to EAO, I don’t think it’d be a good idea to have a standalone timezone proposal. If we’re going to do some work, let’s do work to get Temporal over the finish line and I don’t want to discuss that.
In the interim, should we change the canonical values for three of them (Kolkata, Saigon, Kyiv) before Temporal lands?
SFC: And when you say “change the canonical form”, canonically cases 1, 2, 3 should start returning Ho Chi Minh.
JGT: There’s about 20 of these, but the three that matter – that have sizable populations sitting behind them – are those three. There are time zones in the ocean with very small numbers of people living in them, but these three are the ones that matter.
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.
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
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?
Do not make any changes right now. Wait for Temporal and make a change then. If there is a change to Temporal's timeline, then potentially revisit this.
BAN: (introduces issue)
BAN: When I first made the proposal, it was to require the use of CLDR data, which I then changed to make recommended. I'm working on changing this to a proposal instead of a PR.
BAN: I wanted to get temperature on… CLDR provides two types of data: how many digits after the decimal point, and what to round to, like nickel rounding. The cash rounding value is not necessarily appropriate in many cases. There are jurisdictions that say that for eCommerce sites, you should round to the penny even if there aren't pennies in circulation.
EAO: Being the one who raised this… what I'm realizing is that there is a third rounding policy which I don't think CLDR has data for, which is what happens in Finland, which is that for online sites, you need to round to pennies, for cash you round to nickels. It's not clear that CLDR has data for that. As I've understanded from your presentation, CLDR has data for financial transactions and cash transactions but not online transactions, which is a third category of rounding that might be the best default for JavaScript.
BAN: I think it rounds to one by default and there's not a way to toggle between the different use cases.
HJS: Is this the kind of data that is useful to have in a browser? Suppose you're an online retailer; you have some obligations for what you need to do in your locale. Are you going to implement the thing based on the browser or your own data source or a npm-provided data source? Are you going to trust those data sources?
BAN: That's my concern also; I can't think of use cases for the cash rounding that CLDR gives. I think the existence is an invitation to mistakes.
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.
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.
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.
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.
SFC: The more recent comments on the issue are observing that Chrome and Firefox differ in behavior.
BAN: The current requirement is that we use the financial rounding. If you want to round to some other value, here's how you do it.
SFC: Should we add tests for this behavior?
BAN: I like that.
HJS: I agree with keeping more digits.
EAO: Should we have an API that returns the resolved value?
SFC: Yes, I think we should do it with the Decimal proposal.
EAO: So something like an Intl.NumberFormat that you’re asking to format a number, not a decimal, the API you’d access the value that’s reported, that returns not a number, but a decimal?
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.
Add Test262 and docs for the current spec behavior.
LGTM: SFC, BAN, FYT
https://github.com/ben-allen/locale-extensions
BAN: We've been looking at 7 sets of commonly used customizations. (missed the rest)
HJS: Are the 7 written down somewhere?
BAN: They are in the README. Arabic weekend settings are one of them.