- Shane Carr - Google i18n (SFC), Co-Moderator
- Daniel Minor - Mozilla (DLM)
- Yusuke Suzuki - Apple (YSZ)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Louis-Aimé de Fouquières - Invited Expert (LAF)
- Richard Gibson - OpenJS Foundation (RGN), Editor
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Zibi Braniecki - Mozilla (ZB)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
FYT: Intl Enumeration is approved for Stage 4; ready for editors to merge
SFC: Intl Number Format v3 will go for Stage 4 in January
RGN: There was an off-by-one error in the spec. None of the implementations do what the spec says; it is purely a spec bug.
FYT: I agree. I didn't have time to review it by TC39.
LAF: This is the correct way of counting years.
TG2 consensus.
FYT: I oppose this; I don't think we need to or should do this.
SFC: I think that an option that takes a number should take all numbers that are sensible inputs, and this is a sensible input (with well defined behavior).
RGN: Will this be changing in Temporal, too?
SFC: It's about which end of the spectrum you're on. This one decreases the min from 1 to 0; the other increases the max from 3 to 9.
FYT: This could change the result of resolvedOptions. What you put in and get out is different.
RGN: What if we carried the 0 through to resolvedOptions?
FYT: Then I need to retain the diff between undefined and 0 for no purpose.
SFC: I'm convinced by FYT's argument. It's certainly a papercut, but it's perhaps not a papercut worth fixing.
RGN: Putting on my practitioner hat, I think there's a clear use case of using 0.
FYT: I can live with changing the behavior to accept 0-3, and return 0 in the resolved options. But that's not what this PR currently says.
RGN: It's a breaking change in the sense that users would observe 0 after the change and undefined before. I would support that, unless someone is explicitly relying on the alternative, which seems unlikely.
LAF: If you specify undefined, it should be a default value, and if the default value is 0, that's okay.
USA: I support the patch. A value of undefined behaves like 0 now. We could change it to bubble 0 through the spec, but that's a larger change. This proposal has the smallest possible spec diff. Either way, the implementation diff is going to be small.
SFC: If we go with FYT's proposed change, what's the impact on DTFs that format only year/month/day? Do we still get it in resolvedOptions? Undefined is a better value in resolvedOptions in that case. For example, we don't add hourCycle or hour in cases when this isn't relevant.
RGN: I don't support the current PR, but I do see value in allowing 0. I think it's fine to add fractionalSecondDigits even if not relevant.
USA: I think the best PR is one that bubbles 0 through the chain.
FYT: I think we should close this PR and let USA open a PR to do it the other way.
SFC: I think there is value in resolvedOptions being self-contained. There is also value in accepting 0 as an option. But I don't think one of these values is very strong, so we should just keep the status quo.
FYT: Temporal could make this change later if they want it. I don't see much value beyond being compatible with Temporal.
SFC: I'm not hearing a strong motivation for the change right now, but maybe it will have value when Temporal comes along.
RGN: If I provide input with fractional seconds, and it doesn't show up in the output, that would be surprising. fractionalSecondDigits=0 makes this more clear.
Put the issue on the backlog.
FYT: Setting 4-9 to undefined is bad.
RGN: I agree.
FYT: The second issue is that we're assuming we're going to support 4-9 for Temporal. If Temporal proposes that, I will say no. ICU cannot currently support this format. The first reason is that the API doesn't support any precision after 3 digits. The second reason is that currently the API passed to ICU is a 64-bit double, and the precision is only 1/100 microsecond. In order for ICU to support nanosecond precision, you need a totally new API to pass in this data in nanosecond precision. This is a big ICU change that might cause a 6 to 9 month delay in Temporal.
USA: I agree that setting 4-9 to undefined is bad. On the second point, I don't feel that ICU limitations should hold us back. I think it would be OK to perform a best-effort format.
SFC: I think we should put this issue back on the backlog, and in parallel upgrade ICU to support it.
RGN: Does DurationFormat need this?
FYT: It's completely different. I'm only talking about DateTimeFormat.
USA: DurationFormat uses NumberFormat in the underlying implementation, which doesn't have this issue.
FYT: For "best effort": there's an acceptable and an unacceptable best-effort. We don't want to render the wrong information. If someone tells us their digits are 234, and we display 000, that's not acceptable. If someone tells us to retain 6 digits, it means they care about those digits.
DLM: Concerns along the lines of what FYT said. We shouldn't add a feature that we cannot support. We shouldn't specify to what ICU is capable of, but we don't want to get stuck not being able to ship things.
USA: Given implementer feedback, it seems this is just not a great thing to do any more. We can bring this discussion back to Temporal.
SFC: Is it in the Temporal proposal?
FYT: No, it's not.
Revisit in the future.
RGN: Temporal introduces TimeZone instances that support numeric offsets, like "+01:00". These are fixed time zones relative to UTC, with no daylight savings time, etc. Currently, ECMA-402 requires named time zones, like "America/New_York". Currently the Temporal specification needs to implement overrides between 402 and 262. Things that are acceptable everywhere in 262 are not accepted in 402. It would be more convenient if 402 supported numeric offsets ahead of Temporal.
FYT: RGN could you please type in the string to see it more clearly?
SFC: We should be able to support:
new Intl.DateTimeFormat("en", { timeZoneName: "+01:00" })
FYT: No UTC? We currently support Utc/1 etc.
RGN: Precisely. That’s a valid IANA tz, but a pure offset is illegal in 402. Post Temporal, 262 will accept them however.
SFC: As far as I’m aware, CLDR definitely supports it, ICU should also support it. ICU4X also supports it despite missing on some other features. Therefore, I think there aren’t any implementation blockers.
FYT: The requirement is hour and minute?
RGN: It starts with a sign, two digits and optionally two digits followed by a colon.
LAF: And no seconds?
RGN: Yes. Temporal pushed for seconds in IETF and was declined. There are certain named time zones like in the Netherlands where they maintained a second offset from the reference time, but it's historical.
SFC: Are there any concerns with moving forward?
LAF: +1
YSZ: It seems fine to me.
DLM: Looks fine to me.
FYT: I need more time to think about it.
Move forward with a PR; no formal approval until we can review the PR.
tc39/proposal-intl-locale-info#65
RGN: This is introducing a mixture of getters and setters. Should we consider .getXXX for the ones that return objects? That makes it more clear for the user. If the property starts with get, then it's a function; otherwise it just returns the data.
DLM: Some support for the point RGN is making.
ZB: I'm not agreeing with the problem. Here's a snippet:
let x = new Map();
x.set("key", 1);
x.keys() == x.keys()
The answer to that is false, which is what you expect.
RGN: You're comparing a function that returns an object. The issue is that if this isn't explicitly a function call.
ZB: Do we have precedent for getters that return objects?
SFC: The reason this comes up a lot is that getter functions are relatively new and now we use them more in standards. The fact that this comes up now is that there are concerns for getters returning either frozen or new objects. So getters should always return primitives.
ZB: I pushed back on GetPrefix based on prior art. keys(), values(), entries() etc.
FYT: Just to respond to ZB, I had the same reaction. I see your point here. There’s two points: one, whether it needs a getter and the second is the function name. I see that we can add a “get” in front of it. I would love to hear others’ thoughts on this.
ZB: Do we have prior art for getter functions having “get” prefix?
RGN: Date prototype, etc.
ZB: Sounds like something we should escalate to TG1. I know there are a lot of Rust folks who were working on TC39 who have now been encouraging dropping the get prefix.
SFC: I can see arguments on both sides. I'll point out that we recently proposed getCalendar() and getTimeZone() in Temporal issue #1808.
FYT: Would anyone object to me adding the "get" prefix here?
ZB: I'd like to get further input.
FYT: Another benefit of "get" is it might resolve the side issue about time zones raised by Anba.
SFC: Was the "get" name actually presented in plenary?
FYT: No; it was only at a high level.
http://ptomato.name/talks/tc39-2022-11/#8
Continue discussion on the issue; tag in folks who may be opinionated. This group is OK with either conclusion.
romulocintra/user-locale-client-hints#3
SFC: We'd like to determine which preferences to be in the initial bucket.
FYT: You want to define buckets?
YSZ: Have you reached consensus on the mechanism to support these: a permission prompt, or make it explicit to the user that these preferences are exposed to the web? Just exposing the data is a non-starter. Do we have consensus on how to ask the users about it?
SFC: Different browsers may ask in slightly different ways, but it's a question of whether we should ask for permission for all of the settings together, or whether we should ask for each one individually.
YSZ: I believe right now, we also see internally that at some point we need a draft. At the very least, we need to give some choice to users whether to accept these or not. Basically, this is the most important thing. Offering many options doesn't work well. Keeping permissions to that bucket… I'd like to discuss that internally at Apple if this is good in terms of privacy.
FYT: I'm concerned about the way we approach this with one bucket. If we start with several buckets, we'll talk about how to group them in a meaningful way. If we talk about introducing a single bucket, then we talk about what's most important to expose. That might push the discussion in a direction that isn't best.
SFC: The downside of a single bucket is that we need to make a decision about what needs to be in the bucket or not. On the other hand, if we make each property its own bucket, we can abstract away the permissions stuff. If we did propose a single bucket, it would be safe to assume that it’d become the only bucket we’d have for the foreseeable future. But if we proceed with modularity, we’d have a better time moving forwards.
FYT: I think we should at least separate anything related to time and not related to time. For example, first day of week is related to time, and calendar, but not numbering system and collation. I think the privacy impact is different. For example, people may not want governments to know they prefer a certain script or currency.
SFC: Fair point. I believe that this is enough for us to bring back to Romulo. He will decide based on this feedback how to proceed. I also hear from YSZ whether a single or multiple opt-ins would be better from the privacy standpoint.
YSZ: That’s right. I’m already scheduling a meeting with the concerned folks at Apple so I should have more to share as early as the next meeting.
Pass this feedback to RCA, and YSZ will follow up.
USA: There are 2 questions here. First, how do we catch up with the existing set, and second, how to we keep caught up? Should we catch up completely, or do we come down here and decide what subset of the subtags we support?
SFC: We should support all subtags that influence the formatters that we have. Some might not be relevant for us but these two should definitely be supported. If they are reachable, we should add them and not otherwise.
FYT: We explicitly don't support cu, so we shouldn't support cf. See PR #581, https://github.com/tc39/ecma402/pull/581/files
SFC: If there's spec text that says what we should exclude, then that implies that the intent is that we support everything else.
SFC: So should we record a conclusion that we do want to go in a direction that we support what is in UTS 35?
USA: I support that.
OK to move in this direction.
tc39/proposal-intl-duration-format#108
SFC: +1 to make it numsys dependent.
USA: It will be technically locale dependent, due to the way the data is stored.
SFC: We can talk about the details in the PR.
ZB: From Wikipedia:
In France and Vietnam, the common separator between hours and minutes is the letter "h" (18h45, for example).[3]
In Finland[4] and Indonesia,[5] the common separator between hours and minutes is a dot (18.45, for example).
Interesting but not sure if applies to duration format
tc39/proposal-intl-duration-format#110
SFC: It's possible to implement this without requiring the use of IntlMV. But, the behavior should be equivalent to what would happen with IntlMV. NFv3 will be merged soon, so we can just leverage it then.
singular/plural consistency of property in "Table 1: Components of Duration Instances" against Temporal and Intle.DateTimeFormat #44
tc39/proposal-intl-duration-format#44
FYT: My concern is the resolvedOptions KEY. The key in the object returned by resolvedOptions.
FYT: We have 3 things. (A) Temporal.Duration.from takes a hours field. (B) Intl.DurationFormat has keys for the options of formatting. (C) The third thing is the unit name in smallestUnit, etc. We have 3 different things. (A) is plural, and (C) is singular. So the question is whether it's more important for (B) to be closer to (A) or (C).
RGN: I agree with that characterization.
SFC: Here are some examples; which type of consistency is more important?
tc39/proposal-intl-duration-format#44 (comment)
RGN: I find the first one the most compelling: consistency with Temporal.Duration.
FYT: I'm most concerned about consistency with NumberFormat.
SFC: For example, one may want to pass these options into NumberFormat, especially when writing a polyfill.
RGN: The constituency of polyfill authors is not what we should optimize for.
RGN: Assuming the current spec is internally consistent, there's no reason to change it.
(A) is plural; (B) is plural, which we believe to be the status quo; (C) is singular. Action item is to ensure that the spec is fully internally consistent.