- Shane Carr - Google i18n (SFC), Co-Moderator
- Ujjwal Sharma - Igalia (USA), Co-Moderator
- Ben Allen - Igalia (BAN)
- Justin Grant - Invited Expert for Temporal (JGT)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Yusuke Suzuki - Apple (YSZ)
- Chris de Almeida - IBM (CDA)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
N/A
N/A
https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking
FYT: One update on Intl.LocaleInfo. Planning to propose advance to stage 4 in November or January, but not now. Changes to come.
SFC: No update on Era Codes. Will try to get it on agenda for July or September TC39.
JGT: Asking for stage 3 on timezone canonicalization
USA: Has consensus from TG2
USA: Needs Test262. I assume there is no Test262? This is conditionally approved by the committee
FYT: The thing about test262 is twofold. If there’s already tests asking for a particular order, those tests need to be changed. Second thing is that we should add a test to validate it if there is no such thing. There is no need to need additional tests – I believe there is already something, but we don’t know the input. That’s not sopmething that should be stopping this.
USA: Do you want to not go to TG1 until we have the tests?
FYT: No, not at all. Someone needs to change the tests, but it’s not worth blocking. If there’s something breaking, we have to change the test and so that’s how we’ll be able to test. It’s not a blocking issue.
USA: Removed “needs discussion” label, added “has consensus”
FYT: If we add this support, do we also need to change Intl.Locale? This is a bigger issue – all of the other things we have options for, we have a getter in Intl.Locale.
USA: So this needs to also make the corresponding changes to Intl.Locale.
YSZ: I discussed internally about this sentence breaking feature, we are comfortable with this correction.
FYT: I support adding it, but we need to discuss whether we should add it together with Intl.Locale support. I don’t think we discussed that part – we discussed the other part, but we didn’t discuss adding a getter for Intl.Locale
USA: I think for consistency reasons it makes sense to do it in one PR.
YSZ: Are we having a getter for all these extensions in Intl.Locale right now?
FYT: For whatever’s supported, yes.
YSZ: This sounds like we should add it.
USA: We can record conditional consensus, or just consensus on the behavior but not the PR,
FYT: Did we already add it? I didn’t see it since BAN added the changes, I’ll need to review it.
USA: We can tentatively call this TG2 consensus, but in the one week FYT and YSZ can take a look and we can discuss it further in plenary if there’s any comments.
FYT: LGTM
FYT: Temporal changed courses dramatically after the last time we discussed this.
JGT: We’re introducing a normative PR to move it to minutes.
SFC: I think we were mostly happy with that last month – are there any updates to make to the PR to reflect that?
JGT: I haven’t looked at this one yet.
SFC: Since RGN isn’t here, let’s hold it for the September TG1.
Use Etc/Unknown (like ICU does) to handle the case when the OS's time zone is unrecognized by ECMAScript #25
JGT: Default state is that nothing is happening here, I can spend two minutes polling the group. The issue: sometimes the OS will know about a timezone identifier that ECMAScript doesn’t. Let’s say on Windows, Windows Update was applied and “kiev” has changed to “kyiv”. They’re in an environment that doesn’t know about “kyiv” yet, so that could be an error. This is an uncommon case – it’s on servers, that tends to be UTC on servers, so it’s a client issue. This can also be seen in an out-of-date Electron app. Currently there’s a section that [anba] did research about. (scroll down). In the case that ECMAScript is unaware of what the time zone is, in all cases UTC is assumed. Current behavior: SM, JSC give UTC time, node and Chromium behave differently.
JGT: This is a user problem, but it would be great if programs could detect the error message and prompt. I don’t like the way that SM, JSC do it, because it’s silent. In Chromium that identifier can’t be used anywhere. If you try to use it, it will produce an error. I had a PR that proposed a solution, which was to make Etc/Unknown a first class citizen, essentially a time zone that’s supported by ECMAScript, you can get it out, you can put it back in without producing an error, but the idea is that the ID is unique and programs can understand what’s going on. Last time we discussed this, YSZ, you didn’t agree on the plan for the PR, don’t remember what other feedback was, that’s kind of where we left it. If folks are okay with the Etc/Unknown as first-class identifier, or we should table it?
YSZ: Largest question I had is that Etc/Unknown is not in any IANA database, which means that we can make it work in the ECMAScript world, but that doesn’t mean we can make it work with Python, C++, etc. – those will throw an error if Etc/Unknown is used. Pick an ID from the IANA database?
JGT: Your suggestion, if I’m reading it correctly, is that we should have some kind of new API to let us know if the system tz is unrecognized?
YSZ: Yes, correct
JGT: Since this is such a rare circumstance, I’m not too worried about passing it to other things, my perspective is that what you want to be able to do is let the ECMAScript developer know that something has gone wrong, so that they can prompt the user to solve the problem.
YSZ: In this case we were already returning a UTC and making it work. A change breaking these tools would not be great right now.
SFC: Refreshing my memory of where the conversation had been: One question, which I’m not sure if I asked, is that if we reach Etc/Unknown, how does that get rendered? [..] Another option is to display an offset timezone, but so long as the display name is Unknown, that’s fine
FYT: The source of this Etc/Unknown is coming from UTS 35. There’s a private use in. [...] The reason we have them returning from [...] Basically: it’s coming from that, and there are also localization for that zone ID, inside ICU. In the spec and the CLDR too. In CLDR they have localization for that zone name, for whatever we cannot recognize.
FYT: Let’s look at a locale, kw, there are timezone names for that. So what are the English names? It just says “Unknown”. There are definitely localizations for this, but it’s not part of the name. So if it’s not in there, what do we do?
JGT: Both SFC and FYT are in favor of Chromium’s current behaviour, YSZ is in favour of the current Safari behaviour, so I think unless one you changes your position…
YSZ: We’re fine if it’s included in the IANA database
FYT: To clarify, that’s not my position, I was just showing where it comes from. The tricky thing is how can we represent something that is not representable? Once you put that in the IANA database, then it’s in the IANA database, and then we need another thing to represent what’s not in there. If you put the code to represent that something isn’t in set A in set A, that’s in set A so you need something new to represent things that aren’t in set A.
YSZ: We’re fine with it, this is kind of like an error condition propagated, user can pass something wrong, you can see Etc/Unknown at some poitn. This might be because UTC doesn’t understand the time zone code coming from somewhere, the error propagates, it’s fine. Same if user explicitly gives Etc/Unknown. I think it’s fine, so long that it’s not used as like an actually associated timezone to some reason. [ JGT: Given that ICU in the links that we sent out, even though the spec talks about IANA, in reality ECMAScript depends on ICU for all major implementations. Since ICU already has this, are you okay with treating it as a first-class timezone?
SFC: This reminds me of the question we were talking about in Temporal for some time, the ISO string format, we had proposed some extensions and there was no standard we could point to. In order to solve this problem we were half on the IANA spec, half on CLDR, etc., what we ended up doing was saying that we’re blocking the proposal from being advanced until we have a standard to adhere to, since we don’t want to be the ones to set it. This seems to be the same sort of thing that YSZ is talking about – there is no standard for Etc/Unknown. My sense is that this is such a small thing that it’s all right if we go ahead and be the standard. If we can point to someone else, is there room to stick it into ixdft. Status quo is CLDR is already deviating a little from what IANA recommends for zone aliases, etc. Could be that CLDR is who standardizes it, UTS 35 just says “implementations can define the string Etc/Unknown”, there are other standards bodies we can go to.;
JGT: I agree with SFC and that UTS 35 is a good place to put it, because all ECMAScript implementations depend on CLDR and the string is already in there. This can avoid the complexity of getting IANA to do things, which as far as I can tell is pretty hard.
FYT: Two things for YSZ. Currently, if you look at IANA database it does not have a lot of things. It doesn’t have GMT+1,00. It has GMT+1, it does not have GMT+1 and after that, minutes. If we follow the mandate that it has to be in IANA, every single minute offset in the day would have to also be in IANA. We currently only have UTC from -14 to +12, all the hours are there. The second thing, it’s already UTS 35, we don’t need to add it, it already exists, is clarified, and is there. I think there are two places, and that other parts have it.
YSZ: I have two things, basically. Onee is that if we’d like to use this thing, we should explicitly state in the spec that instead of IANA database, we will prefer this thing and that we don’t explicitly sync with IANA database. But why I’m having concerns about this thing is that it is already known that browsers don’t accept Etc/Unknown. The question is how to avoid these things.
JGT: YSZ, it’s an interesting question, because if the time zone is unrecognized then no matter what it’s broken. The question is should it be broken so that it throws, so that it displays differently so that users get a sense of what’s broken, or should it be masked so that the program and user could not know it was broken and send bad data. The choice I like the most is the middle one – we don’t crash, but we allow the programmer in the ID and the end user in the localized text that there’s something wrong, so that they can choose to fix it. I see this as better than the extremes.
YSZ: If there’s a solution which doesn’t break things, which is just add an API to tell whether this is accepted or not, I don’t see why we don’t do that. That avoids crashes in currently working implementations, and it’s also a good way to know what is happening.
JGT: My worry is that because this is such a rare circumstance, without the user being able to notice that something’s wrong without the programmer writing extra code, I don’t think it’s likely that any program would notice this situation. I don’t think it’s a bad idea to create an additional API, but I’m skeptical about whether it’d be used that mush. Most developers wouldn’t be able to see that this would be a problem in advance.
SFC: My comment is that I’m trying to understand YSZ’s concern about breakages. If browsers or engines throw right now if they get this string, that’s something the proposal should be explicitly fixing. After it lands, there shouldn’t be browsers throwing exceptions when this happens. I don’t understand what you mean about what is breaking and what is susceptible to breaking.
YSZ: Browsers, if not throwing right now for any unknown string, it is nice if we could make the spec say as input we accept broader things, and for output we let out specific things. Anything adjacent with timezone string from the browser or JS engine and feeding it to C++ or something, it is already known that this Etc/Unknown is not accepted by these tools, but UTC can be just accepted. The question is as JGT said, if it’s possible that a programmer will not change or fix something, this is showing the difference. Right now, JGT says that if we add a new API and a programmer doesn’t notice and doesn’t fix it, well, that’s because it is working. In terms of breakage, there’s a severe difference – it’s kind of strange introducing a new crash that doesn’t happen to force a programmer to do some work.
JGT: It doesn’t look like we’re heading toward consensus today, and so I think I’ll leave it here. The only thing I’d say is that crashing is not the only kind of breakage. Today, if your tz is unrecognized and you get UTC back as an identifier, you care going to be sending bad data to everyone. If you live in Ukraine and you’re using UTC, all your times are going to be off by an hour or two. I don’t think that’s worse than the case where you’re crashing because you’re sending output to C++.
YSZ: Basically this tools thing is the largest concern to me. In terms of the user pov, a program that works is better. I don’t think that a crash and using the UTC is in the same bucket, or whether that UTC is worse than crashing applications.
JGT: Sounds like we’re not going to have consensus, not going to accept the PR, current state remains as it is.
SFC: Is the status quo that if we don’t merge this PR, it remains implementation-dependent?
JGT: Status is that the current behaviour of every implementation remains the same: Chromium returns Etc/Unknown and crash if used as input, SM and Safari return UTC.
YSZ: My concern is returning Etc/Unknown as output string. No problem with it as an input string.
SFC: It was my understanding at Stage 2 that we’d solve this problem, I don’t know if I’d like to go to Stage 3 without fixing this problem.
JGT: Everything we’re working on here gets worse when Temporal goes out. Trying to fix all the things we can.
SFC: Yeah, I like that.
JGT: Super short summary of what I’ll present in two weeks. Goal: identify anything that anyone in this room might block. Going to focus on those parts of the proposal and skip the rest. We did get to stage 2 last time – only notable thing is that this proposal removes canonicalization from some cases, but does not change case normalization. If you send in america/los_angeles -> America/Los_Angeles. This allows programmers to store tzs as an enumeration.
JGT: Obsolete name thing, we’re familiar with, removing obsolete names, that could cause problems, we know === is unreliable for comparing tz ids across engines and times, and Temporal makes it worse. Currently you have to use an obscure API to get tzid, but for Temporal you’ll see them everywhere – anytime you toString(), toJSON(), so many ways these will be put in front of developers. Developers are already complaining today, when it’s hard to get these tzids, but there will be much more once Temporal hits. Added PRs to 262 and Temporal, goal after the July plenary meeting is to get the 402 PR merged as well. Spec is complete, tests are complete, polyfills are there, thumbs up from stage 3 reviewers, hopefully I’ll add a bullet point saying TG2 is okay. Reminder: proposed solution: stop returning canonical IDs when programs provide non-canonical inputs, and using Temporal.TimeZone.p.equals to compare IDs, replacing ===.
JGT: Observable impact, spec is complete, 15 changes and one little note, tests are complete and they’re passing. Recommendations for implementors: part of it is done and seems like it’s on-track, which is a guideline for how to handle renaming in the future. We’ve taken an idea from Android: when a new tzid is added, take two years to make it canonical, this gives time for rest of ecosystem to catch up. If you’re sending it to someone else, it’ll be two years before you send people the new name. What’s not on track is this last piece, which is to help implementers converge on implementations. I’ve kicked this out of the proposal because it’s not advancing on the same timeframe. Support CLDR/ICU work, continue discussing in GitHub issues, later propose ECMA402 changes.
FYT: I reject. The current spec you have is not acceptable. Click on your proposals page, there’s two big problems. 1. SystemTimeZoneIdentifier(). This proposal, the rest are in Temporal, this is not in Temporal.
JGT: The PR to limit time zones to minutes has to make the same change, I’m planning on taking this out if the normative PR to reduce time zone to minutes goes through. It’s only here as a backstop in case the Temporal PR is not approved. In the Stage 3 editor’s review I noted that as well.
FYT: So you’re saying section 1.1 will be removed?
JGT: It’s an overlap with a normative PR that Temporal is doing, so assuming that is accepted it will be removed.
FYT: If you remove it, that’s good, but the current shape is not acceptable.
JGT: I have another PR that I’m working on now to catch up, there was an editorial PR that just merged into Temporal that replaces this AO with another one, there’s another PR I’m working on right now to catch up this proposal with the editorial change in Temporal.
FYT: My point is I can’t give consensus on something that’s not there. The if clause is also a problem, it bans everything below the minutes, which I can’t support.
JGT: I understand your objection. There is an editorial PR in progress to catch up with the changes in Temporal that have made this one line invalid, and this entire change here will be rendered moot if the normative changes to Temporal are accepted. By the time we actually get in front of the committee in ten days or so, every link in here and spec text will match what’s happening on the Temporal side, hopefully by tomorrow that will be the case, and the change itself is redundant with the Temporal PR. I’m confident that we will be able to resolve your concerns.
FYT: What is the part in this proposal? –
JGT: Hold that thought, I’ll go through the slides to continue. Slides have planned spec text change, mostly it’s about not canonicalizing in several different functions/AOs. A more complex piece is adding canonicalization to TimeZoneEquals so that we can compare Asia/Kolkata and Asia/Calcutta, and adding a new API which exposes TimeZone.p.equals, and the final piece is to add editorial prose about the waiting period after IANA renames. Here’s the current state of the line in the PR, which is to use these methods (from Temporal) that should work correctly, that’s how this particular line is going to change. The other change to the PR, TimeZoneEquals got a little longer because of changes to the Temporal side mostly dealing with offset identifiers, but nothing else will change as a result of the Temporal changes that merged last night.
JGT: There are two non-Temporal changes: the two-year waiting period that we got from Android, changing it to 18 months or a year would okay, but we have definitely documented problems that had happened around the Kyiv thing that we want to prevent next time, tehn the other non-Temporal chagne is the change to IntializeDateTimeFormat to not do the canonicalization. Are there other concerns that folks have with the changes to the proposal some time.
FYT: My main concern is the InitializeDateTime thing, from a V8 POV I want to see if it’s implementable or not implementable. But after Stage 3 we can still have implementor feedback. My concern, though, is I don’t like to see a proposal needing a lot of change going to stage 3. I’m unhappy that Temporal went to stage 3, I spent months on implementation and when it changes I have to work to catch up. There’s time that we have to change things. Also with DurationFormat – if when people are implementing a thing there are so many moving pieces that there’s different versions of it. Likewise my proposal, LocaleInfo, rushing to stage 3 causes problems. I think it shouldn’t go to stage 3 until all changes are narrowed down, stabilized, and that people can look at it and say if nothing happens things won’t be changed.
SFC: Sorry to interrupt, but I’m going to say if these concerns are still here when we meet in Bergen in a couple of weeks, we could discuss them then. I would like to move on to other topics, because I know that there’s several people on the call waiting to discuss their topics.
JGT: Other than FYT’s concerns, which will addressed before we meet, are there other concerns with the proposal as such?
YSZ: LGTM. In general we are supportive of this change. It will avoid random string comparisons, which could cause catastrophic issues in the future.
JGT: Other concerns, especially blocking concerns? And as a note, I do want to acknowledge FYT’s concern about seeing lots of changes. For this proposal in particular there haven’t been normative changes since Stage 1. We have considered things, but not added to the scope at all. The only spec text changes that have happened have been to catch up to upstream editorial changes. I apologize for not being as fast as I could with this, but everything will be current by the time we get to Bergen. Couldn’t get it done in time for this meeting, and I apologize for that.
USA: So the expectation is that everything should be discussed by our meeting once before it goes to the other group. Looking to document this as best we can. I’ve also been told that the way that we do normative proposal – presenting them at the end of the editor’s update and asking for consensus on all of them – is not correct. So what I did was I took the two normative PRs that we discussed and already had consensus on and added it here, in a new section (Needs consensus) for us. You may see that needs consensus in links to 262, the point is that all of the normative changes to 262 are done in this section, and we need to do ours as well. Going forward I will add each individual item here. Right now I’ve listed them to myself as presenting them, but I would also encourage you to all to present your own PRs if you’re there. I’ll ask BAN, we don’t have anyone from Mozilla on the call, but I can reach out to everyone behind the scenes so that it doesn’t have to be here.
SFC: Comments on process: for the PRs it’s good to list them.
USA: The idea of consensus is present here, I agree that we should leave things, but on the other hand there’s the idea from folks from TG1 who would like some kind of deliberation for everything that is brought to plenary to happen here. What about a requirement that says that everything Intl-related that’s brought to plenary is discussed here, but not necessarily a clear-cut outcome.
SFC: The actual thing we can check and enforce is that any PRs and proposals have a discussion recorded in the minutes of TG2.
USA: I don’t think it needs to be super strong, maybe it would make sense to talk to others from the TG1 side about how strongly they care about reported approval rather than asking for it to be discussed. Personally, I’m happy with the idea that every time we talk about this we can use a label saying “ready for TG1” or something.
SFC: Process-wise, we can figure it out. It sounds like the actual proposal is that we must have discussed things here before bringing them to plenary, that can be enforced with “is there a discussion in the meeting notes”
USA: If anyone has major concerns, they can bring it up at plenary. That sounds great to me, if no one objects to it.
CDA: Only two minutes for each of those?
SFC: Rule of thumb: five minutes on each one?
USA: I was discussing with the ECMA staff and they proposed an activity report, I didn’t like it but I’ve put together one.
“The task group has developed and maintains the ECMA-402 specification, which deals with additions to the ECMAScript standard library to facilitate internationalization.”
tc39/proposal-intl-duration-format#158
USA: Real quick: two normative PRs to Intl.DurationFormat. First, align ToIntegerIfIntegral with Temporal. Whichever proposal hits stage 4 first will add it to the spec, we’re changing this here to match Temporal. I intend to present this, let me know if you have any concerns.
tc39/proposal-intl-duration-format#150
USA: Next, what I believe is the last change for DurationFormat. This change is because we had consensus on the wrong change – misunderstood the consensus, presented to plenary a solution that’s not aligned with our consensus. Now it is.
SFC: That looks right to me – aligns with my expectations. No opinion on 158 – if [Anba] and BAN like it, I’m okay.
USA: It’s pretty much the only option – we’re copying a PR that exists in Temporal, if we don’t the behaviour on our side would be different.
tc39/proposal-intl-locale-info#68
FYT: One thing we discussed last time was allowing the extension for -u-fw to be accepted, meaning that if you have UTS 35 and you have an fw keyword there, you can specify which day is the first day of the week (sunday, monday, saturday), then that will impact the locale because the reason we talk about right now is because in our proposal we have WeekInfoOfLocale, which returns the first day. That’s why we’re adding a PR to make -u-fw as a relevant extension key for Intl.Locale. That’s the first change, which is not controversial. So therefore we should add that in our options bags, right? So that’s the second thing we’re trying to add. In the Intl.Locale API, we have an options bag, which should also accept first day of week. Because Unicode Locale Extensions and this should be synced, according to UTS 35. The other thing is for consistency.
The last part, though, is that because of that literally we will have three different ways to represent a day of week. Before this point we only have two: the Date object has a getDate in 262, returns Sunday as 0. In Temporal, Sunday is 7. IntlLocale.firstDayOfWeek /* -u-fw-sun` in locale {firstDayOfWeek: “sun”) => “sun”. We will have a three-letter code that cannot be changed to a number. In BCP 47 this thing has to be a code with three to eight letters, it cannot be a one letter or one character code. Now we have three different representations: the question is, what should we do with a part that we’re turning to weekday? Currently we’re using numbers, in both cases we’re synchronized with Temporal by using 1 to 7. If we return the three letter code, are we supposed to still return the number, or do we also change the firstDay and weekend thing to string?
SFC: I’ll attempt to answer: I think that we should set the value to Temporal numbers. This is not unlike what we do with other extension keywords. In terms of this API, we should have numbers. That’s the rule of thumb I prefer.
FYT: I don’t have a strong preference, I just think that we should discuss it.
JGT: Consistency is important, I like SFC’s proposal.
SFC: If you take the number mod 7 of the two numerical representations they’re the same. So there is an easy way for developers to convert back and forth. In the case of hourCycle, we use the strings throughout the API, so that’s not a problem so much. In terms of other extension keywords–
FYT: For example, we’re not using 24 or 12, we’re using “hc11”, “hc12”. Before we go down to that part, are we okay with this? If option bag were taking string code, would that be okay? And for firstDayOfWeek, returning the string code, is that okay?
JGT: I don’t think I know enough to have a strong opinion, other than that I align with SFC’s opinion as before: if the input and the output are the same, that’s easier for developers. If we want to also be permissive and allow the string codes, I wouldn’t object to that, but I do think that the documented way for the input should match the output.
SFC: This may also be a good question for us to bring up with ZB. I’ll ping and see if he can join an upcoming call. It looks like, though, that we don’t have precedent for when the ECMAScript representation of a thing is not in the same namespace as BCP 47. As I see it, things that belong to BCP 47 should be in the BCP 47 namespace and everything else in the ECMAScript namespace. This is, though, an interesting problem and there’s no precedent for how to handle it. This is not an Intl problem, it’s something we could escalate to TG1.
FYT: I have a PR that has that included, would you support me if I just remove this change and go to TG1 to ask for consensus? I included it knowing that we should remove it, but I wanted to show you the changes.
SFC: Let’s schedule a half hour in Bergen to discuss with TG1
FYT: Another quick question: it hasn’t been added yet, we’re supposed to have this option bag named firstDayOfWeek.
SFC: If they’re in different namespaces, it’s probably good that they’re different.
FYT: Agreed! I’ll remove that part from my PR and ask for consensus for the rest.
SFC: Sounds great!
Presenter: Ben Allen
BAN: (presents slides)
FYT: What does "auto" mean?
SFC: It's just a placeholder; maybe it should be undefined.
FYT: I love this proposal, by the way.
YSZ: It's nice that all the content in the repository… we need to discuss this internally with the privacy/security folks. Right now I don't have a position.
FYT: With this proposal, you can be fingerprinted as one of a Xillion people, not one of ten or a hundred.
BAN: It's all about reducing the minimum size of the anonymity set. So we can for example allow users in bigger locales to have more options than users in smaller locales. There's clearly a tradeoff there.