Attendees:
- Shane Carr - Google i18n (SFC), Co-Moderator
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Myles C. Maxfield - Apple (MCM)
- Leo Balter - Salesforce (LEO)
- Corey Roy - Salesforce (CJR)
- Eemeli Aro - OpenJSF (EAO)
- Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
- Erik Nordin - Mozilla (ETN)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Greg Tatum - Mozilla (GPT)
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Long Ho - (LHO)
- Yusuke Suzuki - Apple (YSZ)
- Zibi Braniecki - Mozilla (ZB)
- Justin Grant - Invited Expert for Temporal (JGT)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
LEO: TC39 has migrated from IRC to Matrix. Please join us!
https://matrix.to/#/#tc39-ecma402:matrix.org
RCA: We had some progress on the data model. Eemeli and Mihai implemented some prototypes. We also had our first debate about syntax.
EAO: Plenty of things in progress. We have some proofs-of-concept for data model variants.
LHO: (introduces PR)
SFC: What do you think of Anba's comment?
LHO: This lets the implementation choose different patterns for 12 hours versus 24 hours. For example, the 24-hour pattern could add an extra word that is not in the 12-hour pattern.
FYT: The impact of this PR is just BestFitMatcher, right?
LHO: Right.
FYT: So it looks like the PR is right, but Anba wants to make a bigger change. I support merging this PR, and following up to address Anba's concerns.
SFC: I agree with FYT. Let’s return to this when RGN is here.
RGN: I reviewed it after the last meeting. I think it's good.
LHO: Do we have consensus on this PR?
(silence)
Consensus on #571.
SFC: (introduces PR)
RGN: I looked at this and it's complicated but seems fine.
SFC: Any questions or objections on this PR?
(silence)
Consensus on #572.
FYT: (introduces PR)
SFC: So this is basically a spec bug, right?
FYT: Right.
USA: Note the spec bug that Ms2ger filed.
FYT: The original title mentioned it being editorial, but now we realize that this is normative.
SFC: Do we have consensus?
FYT: Does anyone have questions or objections?
(silence)
Consensus on #573
SFC: quickly explains TC39-TG2 process/conventions.
FYT: (introduces PR)
RGN: I strongly support this one. It looks like an oversight and the fix is correct.
SFC: Does anyone have any questions for Frank or would like more time?
FYT: Any issues or objections?
(silence)
Consensus on #577
JGT and SFC: (introduce proposed solutions)
FYT: Is this assuming the value of each field will already be handled and not changed? For example, if you have a duration, and you have different fields inside the duration, it will not be aggregated and converted?
SFC: We've flip-flopped on this many times. Currently I think we should not do arithmetic.
USA: The issue is that arithmetic does not always work, including rounding. For example, you can't round between months and days if you don't have a point of reference, and you can't provide a point of reference in this API since rounding happens implicitly.
JGT: I agree with USA because we have a robust set of tools in Temporal.
RGN: This is a reasonable position, but it's worth noting that it's different than NumberFormat.
USA: I'm motivated by the fact that rounding a number never fails.
SFC: For me, the difference between NumberFormat and DurationFormat for rounding is that NumberFormat rounding can be locale-dependent, but DurationFormat rounding is a developer decision.
RGN: If we go this direction, we should just explain it editorially in the spec.
LAF: +1 to RGN
FYT: If our position is that we don't do any arithmetic, then if we somehow specify that there are some fields that are not in the units list, what do we do?
JGT: That's the decision we need to make. SFC is proposing that the list is a minimal set, where additional fields are printed as well. What I proposed is that you get an exception if there are out-of-range fields.
USA: I personally like SFC's idea better because you define the set of units in the constructor far away from the format function, so you would need to carry this additional set of information about what units are allowed so that you can verify which units are allowed.
JGT: I don't feel strongly either way. But I would recommend that the digital format is where a lot of these problems are worst, so I would like to start with the digital format and make sure our choice is good for that.
RGN: Is it reasonable from an implementation perspective to add in extra units?
SFC: In my proposal, the implementation needs to always be prepared to format each unit, even if it's not in the units list.
FYT: I think that's probably okay. I think the main issue is what to do with the digital format.
JGT: Maybe we could talk about things around the edges to clarify which option would be better. To start, if the user requests hours with the digital form, should we add back the display name? I think not, and we should throw an exception.
ZB: I am softly opposing algorithms in Intl that try to be smart. Trying to do smart resolution of units is one of those. I think that if someone uses "hour" as the only required unit with digital, we should just display the number. For example, the app may have a different UI element to indicate that it is in hours.
JGT: We could also throw an exception.
FYT: I lost the context, which case are we talking about?
JGT: If in SFC’s proposal, if the array is a minimal set and the implementation can add extra units then you can have such weird cases like the one ZB talked about. So in my case, you can just throw during initialization.
ZB: To add, if someone comes to us where they have a use case where they want to display just hours, and this is how it should be displayed, it wouldn't be web-incompatible.
SFC: I prefer to throw in the constructor over throwing in the format function; we have discussed this previously as well in the context of NumberFormat. The burden then becomes, what do we do to handle the edge cases? My proposal is mentioned in the second-to-last line. If you give a non-digital unit, you can combine the digital form in the list. Therefore you can solve the digital problem and everything else is fairly straightforward.
ZB: Then my concern shifts to this. What if the user has a field that is just large enough to contain a digital string?
JGT: This makes sense. In case I have a larger duration, what’s the best way to let a developer know that there’s a bug in their code? Either we could crash or we could emit the string you have here.
ZB: could we ignore them and display a warning?
FYT: I’m not sure we can spec that.
SFC: three ways to deal with extra duration units:
Show them in best effort (perhaps in a way that makes less sense) Drop/ignore them Throw Do math to make sure they no longer exist
SFC: We eliminated arithmetic for reasons discussed earlier. I already stated that I prefer not to throw. Between the other two options, I have a preference for showing the additional fields in a best effort, because I'm worried that dropping the fields could cause hard-to-detect bugs, for example. But I would go with the drop/ignore option if this body prefers.
LAF: +1 to best effort.
FYT: If we follow the same pattern as DTF, we can safely ignore.
ZB: +1 to FYT
RCA: +1 to FYT
SFC: I see DurationFormat closer to NumberFormat than DTF, which is why I think it would be okay to diverge in behavior.
JGT: What's the best way to help the developer understand they made that mistake? If you just hide the data, it seems like it would be harder for the developer to discover the problem.
FYT: Would you display nanoseconds?
JGT: There's another issue I filed about subsecond values.
USA: You would have an issue here where there could be output that looks correct, but it's actually hiding information. So people could all show up at the wrong time for their vaccine appointment.
JGT: In Temporal, we throw exceptions in cases where we know the developer made a bug. RGN, how do you feel about that?
RGN: My inclination here is the same. If you provided invalid input, an exception is the correct behavior.
RCA: If you have formatToParts, how would you present the parts of that result?
LAF (via chat): Différentiate printing part of a duration (3 hours later another day) and a total number of hours (75 hours, i.e. 3 days + 3 hours). Using Temporal.Duration and displaying gives the information about what the developers is deemed to want. So, if data do not match, an exception seems accurate. Temporal.Duration (D. H,) = 3 D, 3H. Format (H) -> 3. Temporal.Duration (H) = 75 H (same as above), then Format (H) -> 75
FYT: To clarify. If the constructor has day and hour, and the input has nanosecond, you throw exception? Or if it has minutes, or years, it throws exception? But if the duration has only day, or only hour, or both day and hour, it would not throw exception?
RGN: Correct.
FYT: Okay, so that means that whenever we take a duration, we need to check all 10 fields to check for any non-zero fields that are out of range.
EAO: I prefer ignoring the additional fields, because that reflects what we're already doing with the options.
JGT: I have a mild preference for the exception, but I would also be okay displaying the extra data in a best effort. I'm not okay with ignoring the extra fields, because it causes bugs that are too hard to detect.
USA: How about another option, where we have special handling of the digital format.
JGT: I'm a little concerned about that, because if you change your UI, for example, if you're making a mobile display, you might use digital on mobile and long on desktop, and it would be weird to have one case crash and the other succeed. I think it's better to have one consistent behavior regardless of the style.
USA: In that case, I think we should do best effort. And if developers really want to check for out of range fields, it's on them to round into the range.
RCA: If I have 1 day and 3 hours, and the units list is hours, I expect the output to be 27 hours.
SFC: That's the arithmetic option.
FYT: We're just saying that you need to explicitly call the duration's round function.
GPT: +1 to best effort.
ZB: What's interesting about this conversation is that as our API becomes more intricate, the question is how we handle a user error in the format function. I'm not convinced by SFC's suggestion that we never throw an exception on the format function. Since we're passing in semantic objects that the developer can construct, we risk being too smart.
SFC: I agree, but I think that this is not always an error case. I think the best effort behavior is actually reasonable behavior.
SFC: If throwing an exception is the only way to make us converge, then maybe we should do the exception.
USA: I had two concerns with the exception. (1) if you throw exceptions, you now have durationformat objects that can fail, so you need to make sure that your input falls within the acceptable range and you need either additional variables or track that in application code (2), it's not a breaking change if the output of duration format changes; that's locale data.
FYT: I don't like to throw an exception, because there are so many cases where an exception could be thrown.
SFC: If you wanted to shield the format function from throwing, it's hard to check.
RCA: I think adding that code on the user to check is unnecessary.
EAO: For parallelism with DateTimeFormat, it seems we should have the same behavior. We declare in the constructor which fields we care about.
JGT: With DTF, it's common to say that you only want to see the date, or only the month, but with duration, those use cases are much less common or don't exist at all. So I think it would be valid to have different behavior.
JGT: Would it be helpful to do a straw poll?
Question: If the duration passed to Intl.DurationFormat.prototype.format has fields that were not in the list in the Intl.DurationFormat constructor, what should we do with those fields?
- Show them in best effort
- Drop/ignore them
- Throw exception
- Special handling for digital
Votes:
- USA: 4 > 1 > 3 >> 2
- SFC: 1 > 4 > 3 > 2
- YFT: 3 > 2 > 1 > 4
- ZBI: 2 > 3 > 1 > 4
- JGT: 3 = 1 >> 2 = 4
- JSW: 4 > 3 >> 1 >> 2
- EAO: 2 > 1 >> 3 > 4
- GPT: 1 > 3 > 2 (not sure I followed with 4)
- CJR: 1 = 3 >> 2 > 4
- LHO: 2 > 4 > 1 >> 3
- RCA: 2>4>1>>3
Ujjwal will continue iterating on this proposal offline.
tc39/proposal-intl-locale-info#37
FYT: (presents PR)
SFC: I'm happy with this change to the Locale Info proposal.
USA: Is there any precedence for this kind of check?
FYT: What kind of precedence?
USA: For using Array.prototype.sort as the compare function.
FYT: I originally said "simple lexicographic order", but Anba suggested switching it to Array.prototype.sort. There is a link in his comment.
USA: This looks good; thanks.
FYT: May I have consensus?
(silence)
Consensus on #37 on the Locale Info proposal.
tc39/proposal-intl-locale-info#36
FYT: (introduces proposal and PR)
FYT: Any questions? Do we have consensus to merge this PR to Intl Locale Info except for addressing Anba's comment about unique and lowercase?
Consensus on #36 as amended.
tc39/proposal-intl-enumeration#24
USA: If you want LocaleInfo to return all the time zones in Japan, you need both language and region. But here you only need a region.
FYT: Your language could be "und".
USA: And would it return the exact same thing?
FYT: Right. The time zones are decided by location, not by locale.
USA: So you're asking whether to remove the region code option?
FYT: Right, because Locale Info is now at Stage 3.
SFC: I agree with removing the region option.
USA: I'm slightly opposed, but I don't think it's a good idea.
SFC: My position is slightly dependent on the resolution to #23, because if we return arrays, we should give users a way to reduce the size of the arrays.
FYT: Note that users can already omit the region option.
Agreement to remove the region option.
tc39/proposal-intl-enumeration#23
SFC: I think that if we want to return iterators, then we should figure out how to return iterators. The issues that JHD and MM raised should not block our adoption of iterators.
FYT: I agree.
USA: Is there an implementation benefit?
FYT: Yes, I have prototyped this a bit in V8, and I can confidently say that I think we reduce memory usage. Because the strings for JS need to be converted to UTF-16. The conversion is simple, but you occupy memory, that's for sure.
SFC: I feel that users may want to collect these into DOM elements, or filter them before collecting them into an array, so the array is likely to just be thrown away.
JSW: I think arrays make sense. We're talking 5K or 10K memory for these arrays. That's small relative to everything else that's on a web page.
FYT: What is the benefit of arrays from your point of view?
JSW: Just simplicity. The data is all right there. If people want to do filtering, it's all ready. I think we're creating more complexity than we need to for this.
GPT: As a JavaScript developer, I like arrays because arrays have prototype filtering. Writing a React app, I don't think I care about memory usage.
JSW via Chat: Yeah -- JS writers are going to assume an array here, most likely. And JS doesn't have the same high-quality standalone iteration helpers like Python/Rust/etc. have, to make working with iterators easy. (Or at least, it doesn’t have them yet.)
LAF: I don't have a strong opinion. I'm okay either way.
LEO via Chat: for the records, I'm ok either way as well.
RGN via Chat: I'm also ok either way, but share Jordan's dispreference for introducing new iterator prototypes.
YSZ via Chat: I'm ok for Array too.
FYT: formatToParts returns arrays.
SFC: Yes, but this is a fundamentally different question than formatToParts.
LEO: I think developer experience is important. Via chat: Not any strong preference, but Arrays seems more intuitive for Developers Experience. In cases like this, I'd consult with JS Educators. https://twitter.com/laurieontech. Laurie helped with pretty good insights on other proposals, it might be the case here.
FYT: ???
FYT: So, if I change it from iterator back to array, other than Shane, does anyone else feel that is less desirable?
SFC: Is the ergonomic impact of spreading the iterator into an array acceptable for the JavaScript developers here?
LEO: I think we should reach out to educators, but my initial reaction is that this would be difficult. But I don't have a strong opinion one way or the other. Converting an iterator to an array is easy. Converting an array to an iterator is also easy. But what does that mean for an average developer? Most of the time, when we get a list of things, the list of things is an array. I think arrays are a more classic format of how we shape things. I would be more in favor of iterators if we were writing a whole language from scratch. But in this case, I think arrays are more consistent with the other things that ECMAScript provides.
SFC: Okay. I still have a preference for iterators, but I won't object if you change to arrays, given the feedback from developers on this call.
FYT to continue iterating offline.