diff --git a/meetings/notes-2023-10-12.md b/meetings/notes-2023-10-12.md new file mode 100644 index 00000000..e644e4be --- /dev/null +++ b/meetings/notes-2023-10-12.md @@ -0,0 +1,358 @@ +# 2023-10-12 ECMA-402 Meeting + +## Logistics + +### Attendees + +- Shane Carr - Google i18n (SFC), Co-Moderator +- Richard Gibson - OpenJS Foundation (RGN) +- Ben Allen - Igalia (BAN) +- Eemeli Aro - Mozilla (EAO) +- Frank Yung-Fong Tang - Google i18n, V8 (FYT) +- Sean Burke - Mozilla (SBE) +- Yusuke Suzuki - Apple (YSZ) + +### 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: Not many changes since last meeting, did land offset timezones, substantial refactoring from Anba landed (structural headers, update to new ecmarkup version, made data types consistent. + +### 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. + +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. + +Incubator call link: https://github.com/tc39/Reflector/issues/508 + +SFC: I encourage everyone here to participate in this, either in the beauty contest or participating in the incubator call. Any questions for EAO? + +### Updates from Implementers + +https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking + +FYT: I did some changes, not for the proposal but for the PR that got consensus and moved. I have added some links in the PR section, no big update. One of the issues we have right now is that the Intl.Locale API and DurationFormat API have a lot of [missed word], V8 doesn’t have the latest. How do we address that? + +SFC: That’s what test262 is for, it establishes that the browser implementations are conformant, we should handle that based on test262 failures. We implement a proposal and make sure that all the test262 passes for that proposal. You’re right that that is somewhat coarse, but that’s okay. What we definitely should do have test262 for everything, which is something that we’re not 100% on, especially when there’s changes on proposals we need to make sure that we have test262 to reflect those changes. That’s one of the places where mistakes can sneak into implementations; we make a change at stage 3, we don’t get tests for those changes, and browsers ship with not the latest version. + +YSZ: We need to update, it’s also good if we have test262. I’m looking to write the update carefully to reflect changes, that’s the current status. + +SFC: Thank you for keeping up with this proposal, and the changes in DurationFormat. + +### 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. + +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. + +## Proposals and Discussion Topics + +https://github.com/tc39/ecma402/projects/2 + +### PR already discussed and agreed within TG2 about DurationFormat needs SOMEONE to present to TG1 soon. + +pull/172 (agreed by TG2 in 2023-09-07 https://github.com/tc39/proposal-intl-duration-format/pull/172#issuecomment-1710742356 ) + +pull/167 (agreed by TG2 in 2023-09-07 https://github.com/tc39/proposal-intl-duration-format/pull/167#issuecomment-1710742982 ) + +FYT: I was expected this to be presented in September, who is going to present it at the next TG1? + +BAN: I was planning on doing it. + +SFC: Process change: we should ensure in these meetings that everything that needs to go on the TG1 agenda goes on the agenda. Added some late last time, ideally we’d like everything is there before the deadline. We’ve largely been relying on proposal champions to make sure their stuff is added, but we should also have a double check on this call to make sure that things are actually added where they need to be. I’ll add a “review TG1 agenda” item to the template. + +#### Conclusion + +BAN will present these at the next TG1 call. + +### Locale with `-u-fw-` value other than 13 value will cause assertion + +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? + +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. + +SFC: I thought it throws for invalid calendars? + +FYT: No, Locale will not throw. It throws on syntax error, but not on this. { firstDayOfWeek: “mon123” } would throw, because it’s not one of those eight things. + +SFC: Yes, but it’s syntactically valid BCP 47 – CLDR says what the list of expected values and expected calendar values are. gegory1 is not valid according to CLDR but is according to BCP 47 – it’s syntactically valid but not semantically valid, it’s an unknown weekday to CLDR. + +SFC: Options we have for what to do here: + +1. Throw in the constructor. This would be a difference in behaviour from all existing subtags, because we always accept syntactically valid ones and report them back. That said, we do throw RangeErrors in some cases. +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`. + +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. + +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. + +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? + +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. + +FYT: If I have a string, and I want to see if it’s a syntactically valid locale, I can call the constructor Intl.Locale, and I can pass it from one place to another place without using anything about Locale, it’s GIGO, so long as it’s syntactically correct. So what I want to do is make sure it’s a valid locale id for forward-compatibility reasons. If we throw, we take away that ability. Because it will throw even when it’s syntactically correct. + +SFC: I advocate for either 3 or 5. I know I suggested 2, but that’s not a good idea because there’s an extra type that can be returned (integer, `undefined`, string). I don’t want to hurt the API for handling an edge case. 3 and 5 are reasonable because they don’t change the signature of the function, which already returns `undefined` unless there’s a value in that keyword, so it would be reasonable for it to return `undefined`. I am also fine with thinking it of resolving what the default would be, though I totally hear FYT’s point that if you want to infer the first day of week, we have that, we should be encouraging developers for using that facility again. FYT gave an argument against 1, I argued against 2? No one has advocated for 4. + +FYT: One thing I want agreement on, if we don’t throw we still need to return a toString. What will be that value? + +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. + +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. + +SFC: It was originally FYT’s proposal, I just rebranded it. + +EAO: Thinking about the toString part of this, it would overall make more sense if we keep it as a string if it’s not one of the recommended values, we could use it with stringify, it’s a tricky question. Every choice except throwing will lead developers to be surprised by our behavior no matter what that behaviour is. + +RGN: Have we considered separate fields, one containing the string or `undefined`, the other containing the integer if such a conversion is possible? + +FYT: Ideally the getInfo would return the value, but when we brought it to TG1 they rejected it. The other thing is already there in getWeekInfo + +SFC: So what FYT is bringing up is that we should go back to TG1 – we already have a getter that returns the integer. That already returns the integer value, then TG1 said that we want this to return the integer. We could go back and say that this really does have a specific meaning, it’s supposed to return the string value from BCP 47 and be more strong about that with TG1. + +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. + +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 + +BAN: +1 + +YSZ: +1 + +EAO: +1 + +EAO: If we go to DE and talk before TG1, that would make TG1 easier. + +FYT: I’ll try to contact him. I’ll craft a proposal and try to reach out to DE before November, and let him understand the difficult. I forgot to mention we have another field already returning what they’re asking, so that part is my fault. + +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. + +### Locale Extensions Update + +BAN: We have two versions of the proposal. In one, we identify what the most common sets are and only expose those, which is like MCM's approach for font sets. I'm personally increasingly skeptical of that approach because locale extensions and font sets are fundamentally different. The other is where we have only 3 tags and allow people to choose only 3 options for those tags: -u-hc, -u-nu, and -u-mu. + +SFC: How do we respond to arguments involving the exponential explosion? + +BAN: We just need to be careful about which tags we add. + +EAO: Is there data imaginable about when these sets of options might be chosen? Is it significantly more common to use celsius or fahrenheit if an option is chosen? So then one could imagine making an even smaller set, or making a 001 setting. + +YSZ: We've had some discussion on this. If one option takes two values, it increases fingerprinting by a factor of two. I agree strongly that this feature is useful, especially for the numbering system in Arab countries. On the other hand, I don't agree we should add all the options for all the locales because that is a danger for fingerprinting. We have strong support for adding this information for specific cases. At the same time, we'd like to avoid introducing a massive fingerprinting vector. Our position is we can get a good tradeoff with bucketing. + +RGN: I wanted to stay clear throughout that the decision of bucketing is different than how things are expressed. So, for example, we could forbid certain combinations even though they are syntactically valid. So we should specify this in a way that if they were allowed, we know how to handle them. So we can have a sparse side table that lists the allowable buckets. + +BAN: ?? + +EAO: One thing from what RGN mentioned… is there a possibility of considering a solution that addresses big, identifiable buckets without adding a generic solution that would allow smaller buckets? + +BAN: I think the plan is to pick an arbitrary smallish set. There's the further complication that you may already be identifying yourself by using an already-small locale. + +SFC: I would recommend crunching the data and seeing how many macroregions / buckets we end up with. + +BAN: The thing I'm expecting to see is that even for relatively small preferences, your anonymity set is still rather large as long as you are requesting en-US. + +YSZ: I would like to have more feedbac We're thinking that this feature is super important and we should get this benefit without causing fingerprint. The example raised by privacy folks is, IIRC, defining the number of, e.g., bucketing in the spec, and enforcing the browser to enforce that entropy. For example, defining all the buckets itself in the browser in the spec is not the ideal solution, because, e.g., we are creating a browser which is specific to Japanese people, and a lot of locales are not used by that user base. This kind of bucketing thing depends on each engine. One thing these folks proposed is defining a constant number of buckets and allowing each implementer to decide how to use the fields to construct the buckets. It's super great that we have good information and numbers first, to inform our understanding, but some browser may want to make different decisions. To make everything the same in terms of fingerprinting perspective, it would be good to define a concrete number in the spec and encouraging implementations to follow that number, to avoid including everything. + +YSZ: We also discussed… we agreed supporting/exposing this thing if the fingerprinting is not ??. We don't have a strong stance on supporting or not supporting whether we should use Client-Hint on exposing this to server side. We don't have a position yet on whether to expose to the server. Thank you so much for creating a great proposal. + +SFC: So it sounds like we can use CLDR to inform us how much entropy is needed, but not list the exact buckets in the spec. + +YSZ: Sounds good! + +EAO: Browsers have `navigator.languages` … + +BAN: The limitation on this is, if the user has something in Accept-Language, but they have a set of preferences different from localization language. + +#### 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. + +### 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. + +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.” + +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.” + +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. + +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. + +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. + +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. + +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. + +SFC: +1 + +#### Conclusion + +JGT will draft a PR with a recommendation based on Option C that we can discuss further. + +### Draft plan to align canonical time zone IDs across implementations #806 + +https://github.com/tc39/ecma402/issues/806 + +JGT: I’ll quickly summarize my understanding of what the questions are, and some suggestions for what we should do for each of these, and my guess for what we should do – I want to get feedback to see if they match everyone else’s. First, I’ll use the terms “primary” and “non-primary” timezone identifier rather than “canonical”/”non-canonical”. So the first question is which timezone id should be primary? The rules are that in IANA there’s a file called zones.tab, which has a mapping of every timezone to an ISO 3166 country code, and the idea that everything that’s in zone.tab should be a primary timezone identifier. This ensures that whatever decision IANA makes – they’re aggressively merging timezones – so that for example the timezone for Iceland resolves to Ivory Coast, Norway resolves to Berlin, and there are many other cases. Another reason, though, is that country boundaries are when timezone changes tend to happen – just because Iceland matches Cote D'Ivoire now doesn’t mean it’ll match later. This is, incidentally, how CLDR has worked since forever, but it’s a stake in the ground for how we’re going to differ from the default build options from IANA. + +The second part is that if CLDR thinks an id that’s in zone.tab is non-canonical, we should make that id canonical and essentially fix whatever’s in CLDR. So this number 1b in the issue here predates the changes that CLDR made, and what it says is “use the new IANA attribute” even though the first one that’s returned from ICU is going to be Asia/Calcutta, use the new API to get Asia/Kolkata. I assume neither is controversial, but I wanted to make sure. + +SFC: I’m slightly confused about what the difference is – is this what the timezone canonicalization proposal decided? Didn’t we already make these decisions? + +JGT: I don’t believe that we have spelled out in this level of detail, especially not in a normative way, what we want the behavior could be. I can look at the latest version of the spec. Also, it affected Temporal but I don’t think this has made any change to 402. + +SFC: My angle here on the followup is that I think this issue is sufficiently in the weeds on how the timezone database works that we should just make a PR and review the PR. I’m not sure how much feedback we can get on the issue, because we have discussed this issue or an issue very similar to it in a past meeting, and we all agree on the give-and-take here. Unless you have specific questions for the group, maybe this is better discussed in the form of a PR. + +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]. + +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. + +### Format of Negative Durations + +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. + +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. + +JGT: Question about number 2: I thought the text format was “three days ago.” for numerical inputs the leading sign as you have it in 2 is correct. + +SFC: We discussed a couple of years ago the different types of DurationFormat – there’s relative, anchored, absolute. This is absolute, this is not relevant to any point in time – we simply have a negative duration of this magnitude and want to display it, it’s not an “ago” but just a floating absolute value. + +JGT: So do we not have a way of saying 3 days, 2 hours, and 1 minute ago? + +SFC: There’s another preexisting API for that, but that’s a separate piece of work. This is specifically about formatting a non-anchored absolute duration. + +JGT: Option 1 is actively confusing, since if you see the sign on one element and not the others, you may think it’s a mixed duration. + +SFC: I like that: option 1 looks like it’s mixed when it’s not, so that’s a good reason to choose option 2. If we choose option 1, it introduces ambiguity. + +FYT: No no no, we have ambiguity here. What happens with 1 minute and 3 second? I’m not expressing support for any of the options, I’m just making sure we’re on the same page. + +SFC: I think we should do option 2. + +JGT: I think there’s another option, call it option 4, a word we could apply as a prefix or a suffix that marks it as a negative duration without putting signs before the text of each unit. + +EAO: Is this a problem we really need to solve? What is a context where a negative duration formatted like this is a reasonable thing to ask for, or is it just to handle an error case. + +SFC: Intl and Temporal can already have negative durations, we just have to decide how to do it. + +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. + +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. + +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. + +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. + +SFC: Are you advocating for 3? + +RGN: Definitely not. My inclination is toward 1. But I’m also wondering if it should be specified in that way at all right now? + +FYT: For example, parentheses + +RGN: Yes, there’s design space that we haven’t explored, and specifying all of them. + +JGT: Other languages have this concept of a phrase of time that’s negated – whether that’s earlier, later, it feels like there might be some language construction that’s clearer, that uses words rather than a minus sign. + +SBE: Is the potential ambiguity is that -2 days -2 hours might be seen as -2 days and positive 2 hours. That doesn’t seem like a distinct – that seems like a distinct representation but not a distinct [something]. If you resolve that underlying duration and only express the entire duration as negative, that seems like less of an issue. + +SFC: I think that – the problem with a key phrase is that it’s not clear that there is a good correct solution for a key phrase, and we have other solutions like the relative time format (“three weeks ago”), but this is not anchored and it would be difficult to convey to translators what an appropriate key phrase could be. I would much rather have just a numeric solution, especially since digital format is something in the specification and the one that we’ll most often see: just 1 hour and 4 minutes. This is the most common case, and we should be designing for that case in mind, and the rest follows from that – focus on the common case and let the less common cases follow. I think, unfortunately, this is something that’s in the scope of the DurationFormat proposal, since it’s built on NumberFormat and ListFormat, and we spent a lot of time arriving at what that’s supposed to be, and it’s important that we’ve got DurationFormat specified in that level of detail – there’s nowhere else with that level of detail – and that makes it easier to implement, write polyfills for, etc. the way to represent time is part of that. It’d be easy to say implementation defined, but I don’t think implementation defined is a viable option here. + +RGN: You touched on part of what I was going to bring up: there’s an issue, I think it’s still open, about the specification of DurationFormat and the way it uses NumberFormat and ListFormat uses definitively incorrect results for Hebrew. Are we going to have this same conversation for every language? I’m not sure even if we find the right solution for English + +BAN: The more I look at this, the more appealing option 4 (parentheses) is. The parentheses seem very unambiguous. + +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.” + +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. + +EAO: 4 is the only option for which I can be sure of its meaning. + +BAN: The thing that's interesting/complicated about the flight example is that it's context free, but it's also referring to two contexts, i.e. the two time zones