Attendees:
- Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
- Shane Carr - Google i18n (SFC), Co-Moderator
- Felipe Balbontin - Google i18n (FBN)
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Richard Gibson - OpenJS Foundation (RGN)
- Philip Chimento - Igalia (PFC)
- Younies Mahmoud - Google i18n (YMD)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
RCA: We've had our first task force meeting. We've been looking at selectors and sub-selectors. We will formalize in the main meeting on which one to choose. We have a short list of the ideas we have. We are improving the process to have a clean proposal in each meeting. We are also planning the talk at the Unicode Conference.
SFC: We are making pre-recorded videos and joining via Zoom for Q&A. The talk is on October 16. We have room for a co-presenter.
FBN: Some of the issues have taken longer than expected to resolve, so I'll probably target November. I have PR #25 open for Frank to review.
FYT: What is the nature of the PR?
FBN: The spec didn't reflect what ICU was doing. The PR updates the spec to reflect ICU behavior.
FBN: I'd also like to discuss Issue #13, "Specify precision for collapsing range". Do you think this is something we should work on?
SFC: Is it a bug in ICU or a bug in the spec?
FYT: I think it's a bug in ICU. I think we should either spec out a fix, or write a Test 262 to demonstrate that the implementation is broken. Do you think we'll need to update the spec?
FBN: I don't think we'd need to update the spec.
SFC: I'll close Issue #13. I think we should wait for user feedback.
FYT: Are eras problematic? For example, what happens when crossing a Japanese era boundary? Or when crossing from BC to AD? I want to make sure your current spec handles this. If there's a bug, we should fix it in ICU.
FBN: That should be handled in the spec. I should verify.
SFC: I filed #27.
FYT: I think the main issue here is canonicalization. Anba wants language, script, and region to be canonicalized. I think language should be canonicalized, but not script and region. Anba's justification is that the script code in the ICU implementation will, for example, if you pass in "su", ICU responds with "ru". One problem is that UTS 35 only talks about canonicalizing the script in the context of the locale, so you can't canonicalize a script in a vacuum, according to UTS 35. According to the 402 spec, a code can return any string, so whether to canonicalize the region/script tags is not specified in the spec.
- Script: tc39/proposal-intl-displaynames#82
- Region: tc39/proposal-intl-displaynames#81
FYT: The other set of issues are enhancement requests. I'm addressing those in Intl.DisplayNames V2.
SFC: Would our hands be tied by web reality if, for example, one version of Chrome returned "Russia" for SU and another version returned "Soviet Union"?
FYT: It's just like any other string changing, like "United States" to "United States of America".
FYT: So should we continue working on #81, or propose for Stage 4?
SFC: I think problems arising from #81 are mostly theoretical in nature. I don't think we should block on it. We can respond to user feedback in future revisions.
JSW: I agree.
FYT: Do we have consensus for Stage 4
(silence)
Stage 4 consensus. FYT will add it to the TC39 agenda.
tc39/proposal-intl-datetime-style#40
JSW: I saw on Twitter that the user was trying to pass in the same option bag for both old browsers and new browsers, and have one piece of code to work for both. But now it doesn't work in Chrome because we throw an exception.
SFC: How do you do feature detection on dateStyle/timeStyle?
FYT: You can look at resolvedOptions.
SFC: I think the horse is already out of the barn with regard to this error. Chrome and Firefox are already throwing it.
FYT: Yeah. Several versions of Chrome won't throw, but the latest version will throw.
SFC: We should use this as a learning experience to think more about how users can write code that works across browser versions, before we make changes to the spec.
tc39/proposal-intl-duration-format#29
USA: Negative durations have been one of the big problems recently solved in Temporal. Durations now always have a direction, either negative or positive. Mixed-sign durations are not valid, so there is only a single unified direction for a duration. The question is, how do you represent in a locale-sensitive way a negative duration? Or even a positive duration, since durations have a sign now, instead of just being absolute? It raises questions about the boundary between Intl.DurationFormat and Intl.RelativeTimeFormat. Should we repurpose the proposal to improve Intl.RelativeTimeFormat instead of making a new class?
SFC: We considered adding durations to Intl.NumberFormat and Intl.DateTimeFormat, but we never considered putting it in Intl.RelativeTimeFormat.
RCA: I think including the duration together with RelativeTimeFormat is a good thing, but for discoverability, I won't find the API. But they fit well together. Maybe we should consider the alias? But documentation might be okay.
YMD: RelativeTimeFormat doesn't currently support Temporal.Duration. So maybe we should add the relative styles to a new class, and keep the old class for historical purposes.
FYT: RelativeTimeFormat is about a reference point. Durations don't have a reference point.
YMD: Durations support negative values.
FYT: What is a negative duration? That doesn't make sense. A duration is the amount of time between two points in time, which is always positive. There's nothing specific about when that duration happened. There's no such thing as negative time. Now we need to format it, but we shouldn't format something that doesn't exist.
USA: You get a negative duration when you take an earlier date and subtract a later date.
RCA: A format exists: "1 day ago".
FYT: "1 day ago" is not a duration; it requires a reference point.
USA: Absolute durations is exactly the way we represented durations, but this is a change in Temporal. Maybe PFC can elaborate?
PFC: The main motivation for changing it was that in the cookbook examples, we had to store a sign alongside a duration in code, because it was very common when dealing with durations that you needed to remember whether to add or subtract that duration.
FYT: How do you display "-1 hour" to the user?
USA: That's exactly the open question.
FYT: I think we shouldn't display it, because it doesn't exist. It shouldn't exist in the data model.
PFC: I think you could format it as "1 day ago".
USA: RelativeTimeFormat takes a unit and a reference point, which is implicitly today. Justin Grant suggested that the reference point should come in via the format style.
SFC: A signed duration is not a tangible concept until you apply a reference point. The reference point that RelativeTimeFormat applies is "now". That is the most common use case.
RCA: ???
FYT: I can see a use case: when scheduling an appointment, you might schedule it "3 hours before November 2 to 3 hours after November 2". But that's a duration with a reference point.
USA: I can think of 3 use cases/styles. (1) relative to now. (2) relative to an arbitrary point in time, like FYT pointed out. (3) unsigned; ignore the sign and don't take the direction into consideration.
FYT: For relative to an arbitrary point in time, we'd need to format it in one step. You can't simply concatenate "3 hours before" to a date string, because the order and inflections depend on language and context.
USA: We could say that we are adding support in RelativeTimeFormat of compound formatting via Temporal.Duration.
FYT: It sounds like you are dividing the problem into two pieces. The first is to support compound units in RelativeTimeFormat. The second part is taking a Temporal.Duration and giving another reference point. The first one you proposed is a reasonable enhancement to RelativeTimeFormat; it has nothing to do with durations. The second one you said is an interesting use case. But the third one is absolute duration, and that's probably the most important in terms of the use cases.
USA: We could break the project in two pieces. First, we continue Intl.DurationFormat on its current path, which is for absolute durations. Second, we work on extensions to Intl.RelativeTimeFormat, starting with compound units and extending to arbitrary reference points in the future.
SFC: If we have two classes, which one is used with toLocaleString?
FYT: Neither.
YMD: We could use Intl.DurationFormat on positive durations, and throw an exception on negative durations, to make Intl.RelativeTimeFormat more discoverable.
USA: In Duration.toLocaleString, I think it's fair to go with DurationFormat, which ignores the sign, but it's more correct than using RelativeTimeFormat.
FBN: So if we assume that "relativeToNow" and "relativeToEvent" are covered by RelativeTimeFormat, should we revisit unsigned formatting with Intl.NumberFormat?
USA: The problem is that (1) NumberFormat doesn't yet have nice support for mixed units, and (2) a full-fledged UnitFormat is a much bigger design space than the problem on the table that we're trying to solve.
FYT: How much precision do you display when formatting a duration?
USA: We are considering that case in DurationFormat.
FYT: I think this proposal should only focus on the unsigned case, and we should set aside the relative formatting. Once we solve the unsigned case, we could consider extending it to the relative case.
SFC: Which one do we call in toLocaleString?
FYT: I think we shouldn't have a toLocaleString on Temporal.Duration. Since we added a sign on Temporal.Duration, we fundamentally changed the data model, so we should remove toLocaleString.
SFC: I think toLocaleString is important for discoverability of i18n.
JSW: The problem is Object.prototype.toLocaleString exists, and returns this.toString(). So if you don’t have toLocaleString, you’re going to get ostensibly locale-sensitive stringifying support that isn’t actually locale-sensitive.
SFC: So it sounds like the proposal is to add Intl.DurationFormat as its own class to handle only the unsigned case, use it in toLocaleString, and throw a RangeError on negative durations?
USA: We'll bring these thoughts back to the champions group and discuss further.
tc39/proposal-intl-duration-format#33
YMD: (introduces problem)
SFC: We could fall back, or we throw.
PFC: My inclination is that we should throw.
JSW: I agree about throwing.
SFC: You don't know whether your duration has days until you get it and try to format it.
FYT: Why do we need the dotted format in the first place?
YMD: It's used in video games.
FYT: How do you pick between the three types of dotted formats, hm, hms, and ms?
YMD: They are all dotted.
FYT: I don't see where you specify the largest and smallest fields in the spec.
SFC: The Stage 2 proposal uses an array instead of largestUnit/smallestUnit.
FYT: I don't know what this looks like. I would like to see code samples to compare the behavior. You asked a question that's neither in the spec nor reflected in code. Look at the Unified NumberFormat proposal or DisplayNames. On issues, we post code to discuss.
tc39/proposal-intl-duration-format#16
FYT: How about "symbol"? Since we are using a symbol as the delimiter. Or "delimiter"? The difference is what shows up between the units: "4hr 3min" (short) or "4h 3m" (narrow) or "4:03" (for the new style).
JSW: "delimited"? Or (later) “concise”?
YMD: "digital"? It means only digits appear.
SFC: We should pick something that could also be used for coordinates (degree-hour-minute) and person height (foot-inch). However, I really like "digital". It is self-describing.
FYT: I like "delimited" or "concise".
USA: I also like "concise".
FYT: So "digital" refers to a "digital clock"?
SFC: Yes.
PFC: I'm not a huge fan of "digital" since it means a lot of things outside the context of digital clocks.
FYT: How about "digitalClock"?
SFC: Or just "clock"?
YMD: We can also think about what this looks like in terms of error messages.
SFC: Or "symbolic": instead of text-based units, we use symbolic units.
FYT: So the plan is to introduce this editorial change in 402 to set precedent for 262?
SFC: Yes.
FYT: Sounds good to me.
SFC: Let's discuss this in its own slot in TC39.
JSW: This makes it semantically simpler. You're not going through all the symbol lookups.
FYT: But it could break people?
JSW: It could break people who've gone out of their way to use hasInstance. It could break tests, but that's about it.
FYT: I feel a little time pressure to talk about this at TC39.
SFC: Okay then. Let's hold back on this PR to think about the consequences more and bring it up at TC39 in November. I don't think we're in a particular rush to bring it up.