Attendees:
- Shane Carr - Google i18n (SFC), Co-Moderator
- Romulo Cintra - CaixaBank (RCA), MessageFormat Working Group Liaison
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Felipe Balbontin - Google i18n (FBN)
- Younies Mahmoud - Google i18n (YMD)
- Long Ho - Dropbox (LHO)
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
- Erik Nordin - Mozilla (ETN)
- Zibi Braniecki - Mozilla (ZB)
- Myles C. Maxfield - Apple (MCM)
- Yusuke Suzuki - Apple (YSZ)
- Justin Grant - Invited Expert for Temporal (JGT)
- Eemeli Aro - OpenJSF (EAO)
- Leo Balter - Salesforce (LEO)
- Philip Chimento - Igalia (PFC)
- Richard Gibson - OpenJS Foundation (RGN)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
RCA: We’ve been working since the last meeting in closing some open points, like having consensus on external selectors meanwhile we had good results and internal consensus moving topics like dynamic references among the task force participants.
The current work is focused on the data model and it includes review and normalizes the 4 different proposals, choosing and presenting the schema definition "language", at moment we are using typescript to prototype and represent the schema.
Before the next monthly meeting, we would also work on the 2021 roadmap.
https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/
ZB, LEO, and FYT to review tc39/proposal-intl-DateTimeFormat-formatRange#34 and tc39/proposal-intl-DateTimeFormat-formatRange#25
FBN: Consensus for Stage 4?
SFC: +1
LEO: There is precedent for minor editorial changes after Stage 4. So this is alright.
tc39/proposal-intl-duration-format#16
digital: ZB, JGT, YMD, SFC, EAO
clock: LAF
LAF: I prefer "clock" because it is easier to translate.
SFC: The identifier does not need to be the same if identifiers were translated.
SFC: I think we need to discuss each proposed type on its own merits before Stage 2.
tc39/proposal-intl-displaynames-v2#4
JGT: We can do this already. What is the advantage?
ZB: I think there is an ergonomic benefit. Intl.DisplayNames is already here. We shouldn't force people to go awkwardly through Intl.DateTimeFormat. I think the use case of getting month names without going through DateTimeFormat is a compelling case.
JGT: Another issue is that the name of the Hebrew month is different depending on the year it's in.
SFC: We should focus on the merits of this feature in the context of Intl.DisplayNames.
FYT: We shouldn't assume anything about Temporal until it reaches Stage 3.
ZB: We already ship the data. So it seems low cost to add.
JGT: The problem is that (1) there's already a solution and (2) the Hebrew month name issue.
SFC: We would need to design a complicated Intl.DisplayNames API to properly handle leap years. Going from month code to display name may not seem very useful by itself.
ZB: Another use case is display context. But I guess we could also add display context to Intl.DateTimeFormat.
RCA: This is a use case in many of our applications. We need an easy way to get month names.
LAF: Is this a problem with CLDR? We could make easier access to CLDR information.
ZB: This is basically what Intl.DisplayNames is doing. We need a semantic API since CLDR is not stable. "Give me the name of the first month in the Gregorian calendar."
FYT: SFC says that Temporal is "Easier with Temporal", but it's still harder than DisplayNames. The second point is that in SFC's example code, the month names are different from year to year.
SFC: What is the use case we're optimizing for? Getting a list of all months in a certain year, or given a particular month, get the display name for that month?
RCA: I listed some use cases in tc39/proposal-intl-displaynames#46
JGT: The hard part of the problem is not mapping from code to string; the hard part is figuring out which code you want. In Hebrew, even if you have the code, you still need the year, because the string could be different based on the year. So you need to either solve the end-to-end problem, or you need to depend on SFC's code sample.
EAO: I agree. Other thoughts: if this makes sense for month names, then it probably also makes sense for weeks and other units. I don't agree with having an API only for month names when we are just looking at a database (?). And some of this discussion is dependent on how strong we can understand Temporal to be. So should we wait for Temporal to advance before deciding for sure?
LEO: Is there a way you can ???
SFC: The problems we're discussing are largely limited to month names, not weekday names.
JGT: Right
LAF: If we have months and weekdays, why not eras?
ZB: We shouldn't be thinking about it that way.
SFC: I think LAF has a point. The way we're thinking about it, getting month names is useful for Gregorian. But getting era names is important for Japanese.
ZB: I'm skeptical about numberingSystem.
FYT: Should we also remove calendar?
SFC: No, I think calendar has higher value.
SFC: What's the status on time zones?
FYT: There are some open questions that we can answer in Stage 2.
ZB: If we drop month, then shouldn't we also drop weekday? Because does it make sense to have one without the other? The use cases seem to be the same.
SFC: I think weekdays and months are both justified, but months have problems that weekdays don't have.
ZB: We shouldn't add a half-baked idea that would imply for us to add month names later.
MCM: ZB's idea makes a lot of sense to me. Design features that satisfy the use case.
SFC: I think weekday name indexes are pretty stable. It's not a half-baked idea.
FYT: Why don't we just remove all the datetime features from DisplayNames and hand the problem fully to Temporal?
EAO: +1
JSW: +1
FYT: Should we remove time zones, too?
SFC: This is the only way to format time zones. So I think we should keep time zones. Weekdays, too.
PFC: It's awkward to get weekdays from formatToParts.
SFC: Well, technically speaking, we can get time zones from formatToParts, too.
FYT: Should we go to Stage 2 with just unit and calendar?
SFC: I think unit and calendar carry their own merits and are an improvement of 402.
EAO: +1
USA: I'm satisfied with those two, and in a post-Temporal world, we can revisit the datetime questions.
YSZ: +1
ZB: Why do we need calendar?
SFC: 402 doesn't currently expose calendar display name strings. They are useful for calendaring apps.
Consensus: go to Stage 2 with only calendar and unit.
Normative: Do not allow duplicate variants within the tlang component of a transformed_extensions #429
SFC: This has been shipped in Firefox and Chrome, but we have never formally recorded consensus.
JSW: (pitches the PR)
SFC: Sounds good to me
FYT: The PR is labeled normative, but most of the PR is editorial, right?
JSW: Right, but the editorial changes are required to make the normative change
JSW: Also see: https://github.com/tc39/test262/pull/2858/commits/d603eecb7959adfd050b72a93fe6cfb930a7fc1c
SFC: Do we have consensus?
FYT: +1
Consensus recorded.
FYT: Anything blocking us merging this PR now?
SFC: Does it need MDN?
JSW: Theoretically.
FYT: I think we probably don't need MDN.
RGN: Does anyone have concerns over the normative aspects of this PR?
FYT: I'm not opposed, but I don't know if the change justifies the risk.
SFC: Can someone from the JSC team comment?
YSZ: I think this is observable only if we're using a user function constructor and changing the prototype in ES5, pre-ES6 way. So given that, the risk seems low. Right?
FYT: I agree that the risk is low, but what is the benefit?
RGN: The benefit is that it's less work for the implementation to execute the operations, which is true. Which could lead to more operations per second observed by users.
FYT: So this is a performance improvement?
SFC: Would it be useful to bring this up to the TC39 meeting?
RGN: Probably not.
RGN: I'm not generally in favor of normative changes.
SFC: Can we tell Alexey that we will not accept this PR unless they can demonstrate a concrete performance improvement?
FYT: What is the SpiderMonkey position?
JSW: I'm not too worried about it. It's more simplicity, better hygiene. So basically, why not?
SFC: I think the simplicity, better hygiene, and perf improvement on
Consensus.
https://github.com/tc39/proposal-intl-locale-info
SFC: Stage 2? Do we agree on the scope?
ZB: +1
YSV: +1
Consensus on Stage 2.
https://github.com/FrankYFTang/proposal-intl-extend-timezonename/
SFC: Stage 1? Do we agree on the problem space?
FYT: I've done some work to mitigate the space problem.
ZB: I've not heard requests for other time zone name widths. But I'm comfortable with the level of extension. So if others feel there is user demand for these features, I'm in support.
SFC: I think being able to display "Pacific Time" rather than "Pacific Standard Time" is useful in calendaring applications.
USA: +1
RGN: +1
Consensus on Stage 1, but FYT to write up more detail on use cases before Stage 2.
tc39/proposal-intl-numberformat-v3#10
JSW: It seems vaguely useful.
ZB: It could be a separate option, not a sign display option.
FYT: +1
EAO: +1
SFC: Okay, so are we okay with allowing implementations to collapse ranges if the digits in both sides of the range are equal, and after they collapse, allowing the implementations to add an approximately symbol?
RGN: +1
EAO: +1 except that if the numbers are the same before rounding, should we hide the approximately symbol?
SFC: No, the behavior should be the same even if the numbers are the same before rounding. If you want to have different display, you can check a === b before you call formatRange.
EAO: SGTM
https://github.com/tc39/proposal-intl-duration-format
USA: (introduces problem)
Tentative agreement:
- Continue having Intl.DurationFormat
- Default to width short
- Display a minus sign on the first number for negative durations
Still some open questions in the repo.