Attendees:
- Eemeli Aro - OpenJSF (EAO)
- Felipe Balbontin - Google i18n (FBN)
- Leo Balter - Salesforce (LEO)
- Zibi Braniecki - Mozilla (ZB)
- Shane Carr - Google i18n (SFC), Co-Moderator
- Philip Chimento - Igalia (PFC)
- Richard Gibson - OpenJS Foundation (RGN)
- Ross Kirsling - Sony, JSC (RKG)
- Myles C. Maxfield - Apple (MCM)
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Jeff Walden - SpiderMonkey/Mozilla (JSW)
Standing items:
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- RCA didn’t attend *
tc39/proposal-intl-DateTimeFormat-formatRange#21
EAO: Would the output be different if the input fields differed?
FBN: I need to double-check, but I think the output might be different, based on the pattern selection algorithm defined in CLDR.
EAO: If I take the resolvedOptions and plug it into a new DateTimeFormat, my expectation is that I should get the same result as the first time around.
FBN: If we add the fields to resolvedOptions, and re-create the DateTimeFormat, then the behavior of .format() will be different for non-range formats. So I think it boils down to the purpose of resolvedOptions.
EAO: My understanding is that resolvedOptions are the options I gave, but cleaned up.
FYT: I think resolvedOptions are the options of the particular DateTimeFormat object. It's not tied to the result. When you call formatRange, what field gets outputted depends on the range of the date. If you put in two dates in the same hour, you still only output minutes only. So calling resolvedOptions should tie to the object you create, not the result you create. We don't know what will be outputted until you pass in the range.
SFC: We could apply the same model as dateStyle/timeStyle: not all the information is present in resolvedOptions, as long as you are able to recreate the same object by passing in the resolvedOptions to the constructor. I'm stating this as an option; this is not necessarily my opinion.
EAO: They can use formatRangeToParts to get that information.
SFC: formatRangeToParts tells you that there is a month field, but it doesn't tell you if the month is numeric or spelled out.
FYT: Good point.
SFC: One option that anba suggested was to throw an exception if the range is too big, and we won’t have to change ICU in order to do that. But we still have issues when crossing from 11:30pm to 12:30am, which could depend on the time zone.
EAO: The expectation for the programmer is to have a string that has two times, and if they get something else, then it might look ugly.
FYT: I don't know if this is spec-compliant, but in V8, if you have two dates, and ???. So it may not be incorrect to throw an exception in that case IMO.
FBN: Isn't it problematic that you can have even a 1-minute range that crosses the date line? You need to add the day, adding other fields to properly represent that range. The objective of range formatting is to represent a range between two points in time.
EAO: as a human, if I read a time range that reads like “”, I can understand that it goes over midnight. I don’t need to see the dates to see if that’s the case.
FBN: true, but there are cases when it is not clear.
EAO: ???
???
FYT: I agree, in the example you mentioned, it is very ambiguous. Are those times a few minutes apart or a few years? You can’t tell.
EAO: how can I use this interface to format close times that span over midnight that doesn’t include adding a date component?
FBN: Currently the plan is to go ahead with asking for Stage 4 in September.
EAO: I don’t care about the default here.
FBN: Going with the easy approach, throwing an exception is simple. For anything more than that, we might need to update ICU.
SFC: one model we could consider is that by default fields that are greater than the specified options would be shown if required to differentiate between the two date times. So far, that’s basically what we have. It breaks down when you get to minutes, at least for Chrome, which seems odd. Perhaps one way to solve this is to say “in order to differentiate, you always add fields that are greater in size”. Idk what Chrome’s impl is doing, but we can make it compliant to that.
EAO:
???
FYT: Can we check if it’s a Chrome bug or a bug in ICU? Try to revisit the spec for that.
SFC: we’re spending a bit of time here, which is good for a stage 3 proposal. I want this to reach Stage 4 without having to completely redo how this is done in ICU and CLDR. Does what I said sound reasonable?
(silence)
SFC: We have a "Conformance" section which says that browser implementations are allowed to have options that are not in the spec: additional locale matchers, usages, styles, and a few other things; and still be spec-compliant. The question that anba raised was that this needs to be updated. Also, it is not aligned with some of the newer options we've added such as units, where we picked an exclusive list of allowed units. Do we want to extend the list of options where browsers are allowed to have extra ones? Or delete the list? I don't know of any browsers that actually implement any extra options.
MCM: If a browser decides to implement them, is that well-defined?
SFC: I don’t think so, no. Section 2 says that the extensions are "implementation-defined behavior".
MCM: I see two options: (1) remove this section entirely, or (2) have optional but well-defined behavior.
EAO: Are there any current implementation-defined behaviours for additional values of those properties?
FYT: I think we need to find out why this section was there originally. Usually it wouldn't exist until someone said that it was needed.
SFC: my guess is that this list probably originated from the original 402 in 2012 and it is an artifact of a time when we really needed this flexibility. But I think our expectations have evolved a bit since then and maybe this needs to be updated to reflect that.
ZB: I don't remember much about this section but I do remember that one of the people working on it at the time was strongly in favour of the ability to deviate from the spec in order to use the Windows internationalization APIs.
SFC: the path forward here is to check if deleting this list would go against the web reality. Otherwise, we can delete this whole list, while keeping the rest of the section.
LEO: I’d reach out to Caridy and make sure.
SFC: Great, thank you.
MCM: another possible outcome here is that an implementation might wilfully deviate from the spec, in which case we can both remove this and stick with the reality.
tc39/proposal-intl-displaynames#73
FYT: This is about Intl.DisplayNames. (introduces issue) A mandatory option is inconsistent with other options bags; options bags should be optional. Should we roll this back or keep it as a mandatory option?
RKG: There was another comment added this morning clarifying that we knew 'language' would be special in this way. My own rationalization is that there may be many things present or not in a locale string, but language is always present, so always available; and there is no precedent for requiring a non-empty options bag for an Intl constructor.
SFC: My opinion here is that we should make it explicit and I’ve documented my reasons in the thread. Yusuke also made a good point.
ZB: (on the chat) +1 to make it explicit.
RKG: I had a conversation with Yusuke and he expressed the "if we do A, then we should also do B" part.
SFC: Is there anyone who is concerned about this divergent behavior, that parameters are required in the Intl.DisplayNames constructor?
JSW: I don’t see a problem with it being different. Intl.DisplayNames is a different kind of class than the other Intl objects.
ZB: (on the chat) +1 to what Waldo said.
EAO: (thumbs up)
SFC: Overwhelming support to move forward with this, along with Yusuke's suggestion: make the parameters required instead of optional.
tc39/proposal-intl-displaynames#81
FYT: Anba suggested that we canonicalize the code, not just in terms of casing but in terms of aliases. The tricky part is canonicalizing the region code and script code. There isn't a mapping defined for this in UTS 35. If we do this, we need to have some way to spec it out clearly. Do we want to perform this additional mapping or just the casing change?
SFC: Why can't we say that the region code is canonicalized based on the locale? In other words, spec out the current behaviour? Is it because it's not defined in UTS 35?
FYT: It uses additional information (the language code) to canonicalize it. There's no standalone algorithm that we could spec out. It's tricky.
JSW: I think deprecated region tags are listed with a mapping?
SFC: Are there cases in practice where the mapping of a deprecated region code changes based on the language?
JSW: I think it is the case with ab-SU and ru-SU where they will canonicalize to ab-GE and ru-RU respectively.
FYT: I think SU maps to 13 different region codes depending on the language.
ZB: What would happen if we decided not to map at all?
SFC: Anba's point was that ICU doesn't support that behaviour right now.
ZB: Why? If you ask for a display name for SU will it return "Soviet Union"?
JSW: I think Anba said that they don't have any display names for SU at all.
ZB: So we would just return "SU", like any other well-formed region code that we don't have a display name for.
SFC: I'm fine with that behaviour if ICU supports it.
ZB: my thinking is: what will be the result of any attempt to specify this? This will be quirky because it’s bound to be. I don't expect it to be of value to users of the modern web. If your system has a display name for SU, it will return it, and if not, not. I'm not sure how ICU supports it.
SFC: I am fine with what ZB suggested.
FYT: I would prefer to stay with not mapping, just case-correcting, unless we can specify exactly what the mapping is.
JSW: I'm a little leery about this but I can't say anything specific just yet.
FYT: Which canonicalization step are we talking about?
JSW: I was assuming it was the same step as on the locale (...???)
SFC: I propose that JSW, FYT, and Anba should sync offline about this. I tend to agree with ZB that canonicalizing a region code in Intl.DisplayNames is fundamentally different from canonicalizing a region code in a locale.
FYT: This is not a proposal, this is an issue in the current spec. What happens right now is that date time format for all other fields allows limiting to a single field. This isn’t true for era or timeZoneName. You can't specify {era:'long'} and only get "Anno Domini" or {timeZoneName:'long'} and get "Pacific Daylight Time".
PFC: fwiw, this is a piece of feedback that we got for Temporal.
FYT: my worry is mainly about consistency. I do value usage also, it’s just inconsistent,
USA: The question is, is it inconsistent by design? If not, then we can just add it, because it wouldn't be breaking anything.
EAO: I can't imagine any useful use for getting more than the era if you just ask for the era.
USA: I agree to a certain extent, but you could say the same thing for just {minute:'numeric'}.
SFC: On the one hand, this is the job for Intl.DisplayNames, but on the other, FYT is right that this is inconsistent.
USA: Does anyone oppose just adding this?
EAO: I'm for it.
SFC: I wouldn't oppose it, but I think it's really more of a job for Intl.DisplayNames. I think it's weird that we have this behaviour in 402 of allowing you to format a second by itself. But I wouldn't oppose a PR to let you get the era or time zone name by themselves in Intl.DisplayNames.
JSW: I agree with SFC.
EAO: I revise what I just said.
USA: I think consistency is important. As a developer I wouldn't be able to guess that these two couldn't be individually formatted but everything else could.
EAO: In any case it's not well-documented.
SFC: I'll add this to the 2021 milestone and link the other issue about resolving DateTime ???
SFC: Anba says this section of the spec is too vague. The problem is that if you support zh-Hant-TW, does that mean you also support zh-TW? I think the answer is yes. I think it's fine to leave the spec as-is, but if we were to make it more specific, I'd say that we essay that supporting ll-Ssss-RR implies ll-RR.
RKG: It seems that both SpiderMonkey and JSC have a list of specific mappings and no-one is really sure where they came from. These mappings should probably get smaller, not bigger, and there's no way to see where they came from by looking at the spec.
SFC: Any other opinions?
RKG: V8 already had a corresponding step so this should be a matter of reflecting web reality.
SFC: i18n developers love to ask the question "do you support this locale?" but that's a really hard question to answer. For example, "en-DK"? It falls back to "en-GB". There's not always a straightforward answer because of the way that region fallbacks and script fallbacks work. I think the best we can do is try to spec this out a bit better. If you have opinions on this I'd love to talk more, because we were also having a similar issue in ICU4X. I will label this as "help wanted".
RGN: I am putting it on the TC39 agenda today. There are two Stage 3 blockers which I will resolve before the meeting. One is tc39/proposal-intl-segmenter#96 — the input to a list of segments is not just the string but also the segmenter object that it was created with. The reason this didn't advance before was a concern from SES and other security-oriented viewpoints about exposing a non-primitive slot value from a getter. My current take is to punt on these concerns by not adding a link back to the segmenter, and removing the link back to the string. You will have the ability to access segments but not walk back up out of the connected graph. This ties into the other issue tc39/proposal-intl-segmenter#116, where we add the input to the segment data object.
SFC: I agree with punting on the SES concerns. I don't see why we shouldn't have the string, but we can always add the segmenter later.
RGN: We could have the string, but it's a bit weird to expose part of the constructing data but not all of it. We can always add the string later as well.
FYT: So the plan is not to expose the segmenter or the string.
RGN: You can get the string as an iteration result by using the containing method or the next method.
FYT: I think what you plan to do is much better.
USA: This is a normative PR from FYT. This allows you to pass in collation as an option as well as a Unicode extension key. (???)
FYT: (???) This isn't defined in all locales, but it will make it more consistent.
No objections, we'll propose this to TC39.
USA: This is my PR, it comes from an issue that was filed by SFC. When you are dealing with currency and you set maximumFractionDigits to something less than 2, it throws a RangeError. This conforms to the spec but is weird. It happens because the minimum and maximum digits are both coerced to 2. There are still a few editorial comments on it which can be resolved before the plenary. It doesn't seem there are objections to the change itself.
No objections, we'll propose this to TC39.
FYT: Currently we have fractionalSecondDigits that can be 0, 1, 2, 3, or undefined as in not specified. This PR treats undefined as 0 and removes 0.
USA: Currently it accepts both 0 and undefined which both have the same behaviour?
FYT: The same output, but problematic in resolvedOptions() because you have to choose to return either 0 or undefined. That's why it's better to get rid of one of them. The purpose of this PR is to make the value in resolvedOptions() reasonable.
USA: I suppose this is not ready for TC39 yet, would you like to work this out with Anba offline?
SFC: This has been open for a year along with the dayPeriod one, and has been presented to TC39 already. I don't think we need to bring them back to TC39.
USA: We can finalize the change editorially, and then merge it, then.
FYT: The change requested by Anba is not purely editorial. I don't think we need to take this to TC39, but I need to resolve it with Anba. I will reflect the change in V8 and I think that we should wait for SpiderMonkey to ship it.
FYT: This is much more complicated because of formatRange() and I haven't spent enough time on it. It needs a lot of CLDR work.
USA: We'll do a status update in the next meeting.
tc39/proposal-intl-displaynames#82
FYT: I think if we don't map the region code, then neither should we map the script code. The usage of this is pretty minimum. It's a separate issue from #81 because the complications are different. No concerns with this.
SFC: This involves doing math. Is that something that is in scope for 402? I would appreciate comments on the thread.
ZB: A year has 12 months is internationalization information because it depends on the Gregorian calendar. Or a week having 7 days. But is a meter having 100 centimeters i18n information as well?
FYT: I think a week having 7 days is in 262.
SFC: Gregorian is defined in 262 but other calendars are implementation-dependent.
ZB: True, but I'm not sure how much of unit conversions are actually 402.
SFC: I think this is a high-demand use case and we have the data to do it, so we can say it is in scope. But there is a concern with separation of concerns. I propose that people leave feedback on the issue and we discuss this next month.
FYT: Do we have a sense of how many of these units we are talking about?
SFC: We would define what conversions are necessary between the units we already have.