- Shane Carr - Google i18n (SFC), Co-Moderator
- Justin Grant - Invited Expert for Temporal (JGT)
- Ben Allen - Igalia (BAN)
- Yusuke Suzuki - Apple (YSZ)
- Richard Gibson - OpenJS Foundation (RGN)
- Eemeli Aro - Mozilla (EAO)
- Frank Yung-Fong Tang - Google i18n, V8 (FYT)
- Discussion Board
- Status Wiki -- please update!
- Abbreviations
- MDN Tracking
- Meeting Calendar
- Matrix
RGN: Cut the release and sent it off to ECMA!
FYT: Is there a tag for the release?
RGN: There's a branch in the repo and a folder in the gh-pages branch.
RGN: FYT raised some suggestions about naming.
FYT: I'm fine with whatever attribute change.
RGN: Cool, so I'll merge this in today, and I'll rebase any other PRs that we decide to accept.
BAN: I think I'll take RGN's suggestion to split this into smaller work items.
FYT: Why do we want to reorder this?
RGN: The ordering of the fields isn't great, but it would be a definite improvement to group the fields by category.
FYT: Are we just swapping their position?
RGN: Yes; that's the observable change. There are 2 commits; one is editorial and the other is normative.
FYT: Only normative part is in the resolved options?
RGN: Yes
SFC: This is something that could have been in the NumberFormat v3 proposal itself, we decided to hold it until we merged the PR. This is a very new section of 402, so I think that it’s appropriate to make this change, and to make it sooner rather than later. This is a very small bugfix from the v3 proposal, I support both the editorial and normative parts.
FYT: I’m okay with this, but we should list all the past test262 tests will be impacted.
SFC: We can record that we have agreement from the group that we want to ask TG1 for consensus on this PR.
FYT: Suggestion for title: we should say “swap” instead of “reorder”, since we’re really just swapping two things.
RGN: It’s the placement of one item in a list.
FYT: It’s not a big deal, I just thought looking at the tag might make it seem more scary than it is.
JGT: Quick reminder and overview of the time zone canonicalization issue, particularly with regard to three open issues. One of the things I’m planning to do if this meeting goes well is to ask for Stage 2 in upcoming TG1 meeting, and will talk about what exactly the changes in the spec would involve. Summary and reminder
Problems we’re solving: implementations diverge. For example, Europe/Kiev in Chrome, Safari vs. Europe/Kyiv in Firefox. When canonical IDs change, you could have existing code that breaks. For example, automated tests that expect Europe/Kiev in output. In 2022 that test in firefox would work, in 2023 that test would break. Tests should be resilient, but knowing the real world, it’s an issue. If we don’t change, users complain about us showing obsolete names for where they live. Final problem, which is an umbrella problem, is that using === to compare time zone identifiers is a bad idea. One of the goals is to encourage developers to not use === to compare time zone identifiers. Temporal makes this worse, since IDs are going to show up everywhere you serialize a ZoneDateTime. My guess is that it will be one to two more orders of magnitude more discoverable to developers.
Proposed solutions:
- Clarify for implementors how TZDB work. If we can get that data out of CLDR, we can still expose the same set of canonical IDs. The next Kyiv that gets renamed, developers will have a sense of what to do
- Reduce observable impact:
- Stop returning canonical IDs whenever we can. If users provide non-canonical IDs, give that non-canonical ID back.
- If we were to do the first part, how can developers know that time zones are equivalent (kiev and kyiv the same). Add new Temporal.TimeZone.p.equals to compare IDs, replacing ===
How do time zone IDs get into ECMAScript?
- Program input: Temporal.ZoneDateTime.from(‘2023-05-04[Europe/Kyiv]’)
- The OS
- ECMAScript itself
I’ve split it into four cases, the first ones being user input split into two. This is the core of the proposal: we’ll stop providing canonical IDs when the user has provided the ID.
Second case: you can add your own time zone and get it back from .resolvedOptions(), I believe this is more rare than not specifying a time zone and wanting to know what the time zone is. We’ll have a discussion slide about this.
Similarly, is forgetting the system time zone. Third, if you have an enumeration of a time zone list, choose the one that’s canonical.
First discussion item: Should we canonicalize resolvedOptions().timeZone? Bunch of reasons for, bunch against.
Reasons for:
Retains backwards compatibility. There’s an asterisk, since we don’t have current compatibility – if I ran the same code in Firefox vs. Chrome, I’d get a different result. Compatibility is less of a concern now, because we don’t have it now.
Provides appropriately non-discoverable canonicalization API. We don’t want to make it easy for people to get to the canonicalized ID because of dependency it introduces.
Reasons not: Same reasons as in Temporal.
Ensures code behaves the same across engines Prevents browser/Node updates from changing how ES code behaves Doesn’t unexpectedly change user input or break automated tests. Minimizes disruption if V8/JSC start using IANA’s canonical IDs (like FF) Respects user choices: e.g. Russian vs. Ukrainian developers. Reduces differences in parse/serialize round trips Aligns with Temporal, though alignment with Temporal isn’t necessarily important since resolvedOptions() is about the time zone used to create localized test.
SFC: Clarifying question. There’s canonicalization and normalization (i.e. normalized case, make it the form in the IANA database), and when you say not canonicalize are you saying we should at least normalize?
JGT: Yes. It would be inefficient to store direct string input, normalize the case so you can store an index into the list of strings.
RGN: We should add an intro slide describing terms for the presentation, since canonicalize means different things in different contexts.
SFC: One question I’d have to follow up is that IANA does add aliases and time zones regularly, so what’s the existing behavior and what’s the proposed behavior for when the user-provided time zone is not yet known by the engine.
RGN: There’s a discussion of that a little forward. When this happens you get an error: it breaks. This happened with Kyiv – if you have an updated server or updated client, the one that’s never heard of it would complain. On Android, they add the new entry as soon as possible, but don’t make it canonical for two years.
FYT: You list here why and why not, but I’m not quite (as RGN mentioned) sure I’m understanding about where the boundary line drawn here? Are we talking about why change time zone from user input, or are we saying we have to make it a canonicalized form following a specific spec. A consideration is runtime memory for the object. In our implementation we don’t remember the exact string the user puts in. On the system you only have one of the singleton. That means if you have 30 different Intl.DateTimeFormat, we only need one pointer for each. The memory cost of that per object will be helping to reduce the footprint with that process. The memory usage needs to be listed on the slide.
RGN: I’ve got a slide specifically about performance issues – let’s dig into that, since there’s multiple questions. Fewer than 600 IDs, growing slowly. No need to store user-entered strings, be indexes into a short table of ID strings. To give your example, if you have a fixed list of ICU objects with a pointer, it should be straightforward to provide a mapping between the canonicalized IDs and ICU. No memory requirements except for a tiny mapping table, not per-instance but global. Further, there’s no expectation that the TZDB updates during the lifetime of the agent, or at all between installations. Can be hard-coded to make it as runtime efficient as possible.
FYT: You’re proposing adding a table with about 600 entries, each entry would have the case-normalized string?
RGN: No. If an implementation, dependent on how they want to prioritize their work between performance, memory, and developer time, the memory requirement is 10 bits, to get to those 10 bits you need to have a mapping table from the index to your list of IDs, but that’s a tiny global mapping table. Not the place of the spec to tell developers how to implement things, but 10 bits is a minimum.
FYT: Reasonable, but should be mentioned that there will be an increase of 10 bits per object?
JGT: No. THere’s already a time zone slot, and the minimum memory requirement for that is 10 bits. The built-in time zone slots.
RGN: So that’s an existing cost.
JGT: Yes, this will not necessarily increase that.
EAO: I think that this is an issue of semantics that we’re dealing with: two terms, canonicalization and ID. These are kind of, in the way commonly used, communicate immutability – the canonical thing will be canonical forever. ID is effectively a unique identifier for a thing, but these names are not. Fundamentally, they are closer to localized human text, and they change, as we’re talking about with Kiev/Kyiv. I would think that given that the vast majority of the Intl.Formatter APIs, although they do produce strings in many cases, we highly recommend that people don’t rely on those strings staying the same from now to eternity. My preference is to allow these names to change but work around the semantics. Calling them “names” or “preferred names” rather than “identifiers” and calling the process “canonicalization.” This may make it easier to be okay.
JGT: Richard and I have gone back and forth on the right names, we don’t have a clear idea. Could open an issue in the repo to essentially say “what should we call these things to better reflect the reality that it may change.”
EAO: The word “name” came to mind first, but I’m not attached to anything. Happy to file an issue.
JGT: One thing with “id” vs “name” is that we originally called them “name” but changed to “id” later on, because “name” might imply that they’re not computer-readable. “Code” could be another choice, but we didn’t want to imply that it’s a localized name that would change across locales, but instead that it’s an identifier that’s computer readable.
RGN: There’s only a small degree to which change is possible. ID has been exposed to consumers of ECMA-402 for quite some time and cannot be reverted. Internally the language could be changed, but external interfaces are pretty much set.
FYT: My undersatnding is that that means that if this proposal goes forward, you would need to mention how to case-normalize this thing. That will still be needed.
JGT: Correct.
FYT: Case-normalization is tricky
RGN: That’s coming from IANA, so that’s what’s expected. There’s not an algorithm to follow to convert arbitrary strings: it’s just “look it up and use the form in the official data”
JGT: Every implementation ships with a hard-coded list of 600 strings, and you do an ASCII-case-insensitive comparison to each, and if there’s a match return one of the items from that hard-coded list.
FYT: And that’s not canonicalization?
JGT: The term we’re using is case normalization. Any term is fine as long as we have a clear distinction between case-normalization and changing the actual words.
RGN: But even things like Kiev/Kyiv don’t have a conversion algorithm: it’s just a case-normalized list defining the possible outputs. The spec at least will say that it’s a lookup table, and implementers are free to implement it however.
JGT: So what are opinions on what to do?
FYT: Another question: my understanding is that in the past, about two years ago ZB proposed that anything going to stage 2 has to pass three tests, and for process reason I ask that your slides include those three criteria.
SFC: I’ll pull those up, but this is not just a 402 proposal even though we’re discussing it in this body. I think this proposal likely satisfies these three.
FYT: We should mention it.
JGT: It seems we’ve already satisfied it.
FYT: I agree, I just think we should explicitly mention it.
JGT: Will follow up to address it.
SFC: In TG2 we don’t have stage-advancement powers, will discuss in TG1
JGT: So should we canonicalize this one, or not?
SFC: As long as the implementers are okay with it, you’re bringing me over to your side. I will be very clear here that by “non-canonicalize” we mean “normalize only.” the two choices are “canonicalize fully” or “normalize but not canonicalize.” I think it would be good and make sense to normalize it only.
FYT: Well “normalize” is a loaded term, why not say “case normalize?”
RGN: Assume that the terms are standarized so that there’s no confusion when you get to these point. Will not accept user input with arbitrary casing, the question is whether we stop with case normalization or go farther.
EAO: My preference is case-normalization.
RGN: that is also ours.
SFC: I’m convinced. I think this is the position we should take at stage 2
FYT: I’m okay with that. Let me put it this way, though: I’m okay with this, but I have some doubts that the difference between case-normalization and true canonicalization is small. The advantage of saying “people aren’t going to use this for an API,” I think that part is not that strong. Unless you hit the cases where case-normalization and canonicalization, people will think it does canonicalization.
JGT: I think that today everything is canonicalized and it produces many complains from the affected countries. “Why are you calling it Calcutta instead of Kolkatta when the name changed a long time ago?” We have the ability to set user expectations, and this proposal the idea is to reset these expectations to something more in line of what Ukrainian, Indian, and Vietnamese developers expect.
FYT: Yes, but if people want to misuse it, they’ll still misuse it.
JGT: Do we have consensus?
FYT: +1
SFC: It sounds like we have agreement that this is a good direction, we’ll get consensus in two weeks.
JGT: Next issue: what should DefaultTimeZone return when OS time zone ID differs from ECMAScript canonical ID. THere are three cases today:
- The OS adds a new canonical ID, but ECMAScript doesn’t recognize it.
- Kiev/Kyiv. If I’m in Ukraine and I have a local server, and I want to set it to Europe/Kyiv and then I run a node.js app that doesn’t know about it, that would result in an unknown time zone in ECMAScript. Rare in browsers, but it is a problem in server apps.
- Not sure there’s a great solution – Android solution, to very quickly add new aliases when they show up but not change the canonical ID for a while so that everyone can catch up seems like a reasonable approach. But if you’re still running node 12 and will be running it for a decade, there’s nothing we can do to make sure the new TZID is recognized. This is not a problem we solve, but it’s a problem to solve separately.
- Case 2: OS has new canonical ID, but ECMAScript considers it non-canonical.
- E.g. OS: Asia/Kolkata, ECMAScript: Asia/Calcutta
- ECMAScript has new canonical ID, but un-updated OS still uses old one.
- Variation: sysadmins keep old OS ID for compatibility or political reasons (i.e. Russian and Ukrainian developers disagreeing on what the time zone should be called).
Discussion: in cases 2 and 3, should DefaultTimeZone return OS ID or ECMAScript canonical ID. One more pro/con: there are some libraries on mobile devices where ECMAScript has the ability to call into native code, which in turn calls into the OS to get OS ID. Even in browser ECMAScript is self-contained, that’s not true in all ECMAScript environments, particularly in mobile devices or servers. This is one argument for not canonicalizing OS ID.
EAO: Why are we considering this? Isn’t this quite clearly outside of the scope of what we need in the spec? Isn’t this quite directly an implementation detail?
JGT: Goal is to reduce impact and breakage of ECMAScript code when canonicalizations change. This would be one more way that we could reduce the dependency of ECMAScript code on the canonical values baked into ECMAScript. Puts the responsibility to update to whoever’s responsible for the OS rather than the TG2 committee to decide the canonical versions.
RGN: This is in-scope because it would be a problem for the spec if the DefaultTimeZone output were not recognized as valid input. If relying on OS, when it returns something out of bounds it needs to be processed or recognized as valid.
JGT: We can’t solve case 1. If we don’t know what the ID is from the OS, we have to throw up our hands.
RGN: but “throw up your hands” is necessary to specify
JGT: I agree. The spec should describe what we do in case 1, even if we can’t solve it.
RGN: Sets up constraints that are recognized to abide by.
SFC: Question about case 2: I don’t understand case 2. Why would ECMAScript consider it non-canonical? What I’m thinking is that under what condition, assuming there is no version skew, under what condition would case 2 occur?
JGT: In browsers everyone updates quickly, but if we were to change V8 and JSC to catch up with latest canonical values in IANA, for browsers this wouldn’t happen. Most likely case is a relatively old server app running on older version of node with older set of canonical IDs, and the canonical value changes in the OS. Then the question is should we report back what the OS says. ANother example is a corporate enviornment where they don’t update their evergreen browsers – though that might be case 1. The time you would have a new canonical ID where ECMAScript would… SFC, I think I agree with you. If we make a change to JSC and V8 to catch up with IANA, case 2 goes away.
SFC: I think so. Let’s focus on case 3. ECMAScript makes the engine figure out what to do on each host.
JGT: Let me take back what I had to say about case 2. If we decide that changing the canonical ID as soon as IANA change it is problematic when ECMAScript programs are sending IDs that no one has seen, then the Android solution (add, but don’t canonicalize right away), that’s where we get case 2. Case 2 would be what happens in the middle.
SFC: That makes sense. Case 2 and 3, what happens here is the ECMAScript engine should paper over what’s on the OS level, my code shouldn’t care, it should just pick a canonical ID and return it, if it maps from old to new it should return ECMAScript canonical ID. If we wait two years before updating the canonical one, that’s great, but we should not specify what happens.
JGT: What that does mean is that you can, if your code, dumbly, has a hard-coded dependency on a particular ID and uses === to see if it’s the ID you want, if that changes (ECMAScript or OS), your code is going to break. For people who write code that way, do we want the OS updates to break them or the ECMAScript engine updates to break them?
SFC: ECMAScript?
RGN: Or does ECMAScript not have an opinion on this, at least not a normative one.
SFC: If I’m running node 18, I want it to have the same behavior regardless of OS. I think that would be good. I think it would be good to reduce that variance as much as possible. It’s a job of the ECMAScript specification – the only one – is to provide a platform that you can build apps against and then run them in any environment where ECMAScript is supported. In terms of code that relies on === for TZID, we solve most of those problems by doing case-normalization. Every user is going to have a different default time zone, it’s easy to change, that’s not something that apps can/should rely on. Also locale IDs. There’s also cases where locales change (Hebrew, changed the name, Norwegian…). The matter is that it’s not really something that I see as a, it’s an expectation that DefaultTimeZone can change at any time. Sometimes it’s hard to avoid people relying on the wrong invariants.
JGT: What do you think of idea from Android of react native app that can call into native libraries that in turn give the OS value. ECMAScript vs. the native libraries could give different answer as to what the ID of the system is.
SFC: I would rather have ECMAScript version give same results in all environments. Others can disagree, I’m nimble on that position, but that’s my position coming into this.
YSZ: Probably to say I have a different stance than SFC, because we’re focusing on smooth integration into rest of OS, so we’d rather see consistent result in one platform rather than one ECMAScript version. In terms of implementation, JSC doesn’t have case 1 or case 2 problem. If we go to implementing a hard-coded list of strings, case 1 and case 2 in JSC would be broken. iOS also gets very frequent updates of time zones, so time zone information in OS is more frequently updated than in JSC. In terms of this problem this would be a regression. The problem is, this is my opinion, is that these things can happen in various OSes, is that JSC not using same values as V8 or system. I wonder if we should more strongly prevent this === thing, since we don’t have much control of the version of the OS. Updating frequently doesn’t help much.
EAO: To reiterate, I think making any reference to the host’s opinion about the time zone or other facts should be beyond the scope of the ECMAScript spec. It’s a real problem, but it shouldn’t be solved at this level. I really like making explicit the requirement that if returning a DefaultTimeZone ID that we should also be able to accept it. That’s a valid restriction, but I wouldn’t go any farther than that – allow implementation to keep allowing new canonicalizations as they see fit. I don’t see that this would lead to real problems, because the issue of changing the canonical name before others are likely to accept it would lead to the same problems that Android is working around. It’ll be fine, and we don’t need to fix everything at this level.
JGT: I’m realizing the core decision here is that do we want an ECMAScript program on same engine to run identically, or do we want on an individual device have all ECMAScript programs (regardless of version or engine) run the same.
EAO: JS gets used in so many different ways/implementations/places that there is no one right answer, and we shouldn’t be trying to provide one.
SFC: My response: we face the second question a lot with locale data, for example, and different engines have different strategies for sourcing locale data / time zone. Every version of Chrome works the same on all OSes, because they ship their own locale data. I don’t think we can make it a normative requirement, best we can do is say in prose what a reasonable goal should be. Focus on outcomes, rather than engine vs. OS. Outcome along the lines of “we will eventually migrate to new IANA IDs about two years later.” That’s something we can point to and say that the expectation is that engines start returning the new IDs about two years after they’re created. In terms of what they do with the OS, that’s not in the realm we can control.
JGT: Common thread: spec should be explicit that we’re not mandating a specific behavior, we have some guidelines but engines must make the right decisions for them. The consequence is that the same code on the same device with different engines/versions of engines could differ, and ECMAScript programs should not assume that the same value is being returned in all cases.
SFC: In terms of the ECMAScript perspective, correct. It cannot make an assumption that things are already stable. These TZIDs are a living thing, they change, there is no way a program can rely on the stability of these things.
JGT: Throwing this out for consensus: I am hearing this consensus that we will provide high-level recommendations (like the two year thing), say explicitly that this is implementation-defined, and in documentation call out to ES developers that they should not assume the same value will be returned on every engine and every version of that engine.
EAO: If there’s a specific time frame recommended, we should go to the Android guys and see if the logic they’re thinking, and if a different number (other than two years) is better, we should find that.
JGT: WIth that caveat, does that sound like what we’re agreeing to?
EAO: Sure!
SFC: No one else on the queue.
SFC: Getting started with discussion slide 3.
JGT: Previous were about APIs should behave, this one is about what canonicalized values should be in the first place. Firefox matches IANA as soon as possible, V8 and Safari matches ICU behavior, which is “first time ID is introduced, it’s the ID forever,” which is how we get Kolkata and Saigon sticking around for decades. Reason to match IANA: respect developers offended by their country is called by a colonial name they don’t like. Heads up: there is a project on the CLDR side to enable CLDR to expose IANA canonical IDs, ES engines could leverage that if possible. Reasons to match ICU: backwards compatibility, ensuring that IDs never change. Or we could try to agree to disagree, where we have backwards compatibility between versions but not necessarily between engines.
SFC: Seems like last question: we want to get guidelines for when engines should adopt updated canonical IDs. What else is there to discuss?
JGT: If the answer coming out of this slide is that engines should introduce new IDs after an amount of time, that’s great. Right now it’s infinite for V8 and Safari and zero for Firefox. Having agreement across engines that we should change at all and also that we should wait some time before changing would be a great outcome.
EAO: My only concern is that given that all these IDs are originally coming from IANA, the spec-level matter, how I’d phrase it, is that everything’s valid so long as it’s coming from IANA, and in the prose around it a recommendation to keep it up to date, maybe with a delay.
JGT: I would be very happy if that were the conclusion.
SFC: One possible timeline: three phases in terms of adopting new canonical IDs. First phase is that the canonical is the old form but we know what the alias is, phase 2 is OS and other environments return different things, phase 3 is new ID is canonical form now. We can give recommendations, but each engine can use slightly different timelines, under the expectation that we’ll eventually get to phase 3, and that engines start in phase 1. No strict normative requirement of exactly how long these phases last.
JGT: That sounds great. Do we have consensus?
EAO: +1
SFC: How do you feel, FYT/YSZ
FYT: Let’s say I have a calendar app, and let’s say I make an appointment to remember my mother’s birthday for the next 20 years. I set a time zone from a menu populated by canonical IDs, and I pick a time zone, and then I store it. What would happen if in year 15 the canonical ID changes, and the menu doesn’t have it. I store the ID that maps to localized text. The ID points to an item in the list, or the menu, key is canonical ID, value is localized text. Now my key part is no longer something I have stored in the database.
JGT: That problem exists today in firefox. The way to resolve it is to not use === in logic, but instead .equals() method to ensure that what’s in the database reflects the time zone.
FYT: But what if the list does not have the item you store.
JGT: That’s already a problem today. Consider the case of Kyiv – if I rebuild today, Europe/Kyiv is not in the list. You do the matching by the API telling you whether Europe/Kiev and Europe/Kyiv are the same time zone. The proposal on the table is that the guideline we’d have in the spec is that engines should add new IDs as aliases as soon as available, and then eventually in phase 3 switch from the old one to the new one. Today, that amount of time (between phase 1 and phase 3) is zero for Firefox and infinite for V8.
FYT: Why doesn’t Firefox have the issue of breaking things?
JGT: It does, people run around dealing with it. The only time you break anything is when using ===. The goal of this proposal is to give developers in places that have been renamed that we will eventually catch up to the current modern ID for those time zones. In order to do that, we need to provide a method to compare time zones for equality.
FYT: How could we ever say “you have to migrate to the new one?” Not sure that’s enforceable.
JGT: Do you mean engines or ECMAScript
FYT: Engines. If I only see risk of breaking things by changing, I don’t see a strong benefit.
JGT: The benefit is that we’re no longer offending developers in some of the most populous places in the world by telling them that the name of cities in their country is a name that they haven’t chosen in a long time. Every other system (OS, Java, anything that’s not ES), I’ll get a different answer. The longer we wait to switch over, the more it’s a problem of different answers between ES and everyone else.
SFC: Here’s what I think you should do, JGT. Agenda deadline is tomorrow, I think you should make the proposal we discussed on the agenda before the deadline, which will give everyone a chance to evaluate it and we can get actual formal feedback about whether this is a good approach. We need to have the proposed timeline well-motivated, and for it to be clear what the motivation is.
YSZ: Can we separate out ID and actual string representation? The problem I’m seeing is showing is the program using the string as an ID. Could just check if ID is equal, and it’s not necessary for it to be a string form shown to users?
JGT: Yes, this is all developer-facing.
YSZ: If we have a string representation, we have more of a chance to use the modern canonical string representation separate from === comparison of ID. Do we have any thought about these things?
JGT: Making a new kind of identifier, that’s not an IANA time zone name?
YSZ: Do we have a pros and cons on these things?
JGT: Bar is pretty high to introduced a new TZID, industry has standardized on IANA, so from a computer-readable representation of time zone, I think the IANA identifiers, despite the problems discussed here, are the industry standard, and I’d be concerned if ECMAScript were to try to introduce a new one.
FYT: There’s a five-character one, but I don’t know if we’d like to use that.
EAO: Yes, we could have a new global symbol registry, but that means we still rely at root on IANA but differ on string representation. Not for consideration today.
JGT: Status: planning to ask for stage 2 in May, Normative changes:
Temporal.TimeZone.p.equals API: true if canonical IDs match, false otherwise. Simlar to ZoneDateTime.p.equals, PlainDate.p.equals. Don’t canonicalize IDs (But do case-normalize) before storing internal slots. TimeZoneEquals will change (canonicalize first, then compare) Also canonicalize in resolvedOptions().timeZone Remove canonicalization requirement from DefaultTimeZone. Agreement is to leave it up to the engines what happens there. Canonicalization in FormatDateTimePattern, or implementation-defined?
SFC: That’s an internal editorial detail, don’t think that matters.
JGT: Will plan on not changing that, will add a note that implementations that care need to canonicalize it. We have agreement on the first draft, will include text about phase 1, phase 2, phase 3. I see this proposal stacked on top of Temporal stage 3. Ideally what would happen is if Temporal isn’t at stage 4 by the time this gets to stage 3, we’d make a normative change in Temporal.
tc39/proposal-intl-locale-info#68
FYC: My concern is – I want to see other peoples’ feelings – is that this proposal is already stage 3. If we do this, we have to list extension keywords, currently it is not. Second thing is that we need to add a getter to return this value. Third thing is that we should actually read the option, probably called firstDayOfWeek, from option bag, similarly to hour cycle. That changes the spec at this stage 3 level, which I’d hesitate on unless everyone says it’s a good idea. Will give update in two weeks about Intl.LocaleFormat. Could put it in there to get agreement from TG1 about adding additional changes, but wanted to see what peoples’ opinions are, since this is a relatively big change for stage 3.
SFC: This could be a change after we land, similar to the one we made from RGN earlier in the call (ordering of fields in resolveOptions). If you want to do it that way we can, but I do think we should write down the guidelines about extension keywords in the style guide itself. The problem is that the style guide states (or will state) that all extension keywords that are relevant to the APIs should be accepted by the APIs. Inconsistent with the style guide that we don’t have this – I see this as a spec bug. We should fix – I don’t feel too strongly if we do it now or wait until it lands at stage 4 and then fix it. No strong opinion so long as it’s in for ES2024.
FYT: We are very early in the timeline for 2024, might not be a good idea to put this in the proposal. Would like to hear that other people support it.
SFC: When do you plan to bring it?
FYT: I think Q4, not soon.
SFC: If you were asking in May or July, I’d say wait for this to land, if it’s November, get normative PR on agenda for May meeting. In terms of timeline, I’d like to fix this.
FYT: I may not be able to make it to May as a PR, but July is manageable.
SFC: Perhaps at the live meeting in Bergen in July.
FYT: I’d like to see what YSZ or anyone from Mozilla has to say.
YSZ: To me, it’s fine to have it integrated in June or July, probably we’ll implement it a bit later. The proposal looks like the right thing, and once it’s integrated into the spec then we’ll eventually implement it, not sure when, but probably not too much later.
Conclusion: Plan to propose it as normative PR in July.
https://github.com/tc39/issues/574
FYT: This could be considered an editorial bug – currently it’s just undefined. This should have that section, but I can’t find it.
SFC: Assigned to BAN.
Intl.supportedValuesOf('timeZone') for UTC, Etc/GMT*, and other non-contintent/non-ocean time zone identifiers #778
JGT: Quick question for the group: what should be in supportedValuesOf for non-location-based time zones?
EAO: What it claims to me: these are the values I can understand if you throw them at me.
SFC: Do we return both the canonical and non-canonical forms?
JGT: Currently only canonical. Main use case for this API is to show dropdown of all time zones. I don’t see value in having Kiev and Kyiv show up as two items in a dropdown with the same localized text.
SFC: Clarifying question, what are these…?
JGT: FIrefox has a weird way of getting its values, assume they’re coming from IANA and marked as canonical in IANA.
EAO: If you’re asking what time zones those are, they look like Eastern European Time, Central European Time…
JGT: We should ask [Anba] for that. Should all the UTC and Etc/GMT* time zones be returned from this method?
SFC: my sense is that UTC and Etc/GMT* should be returned, but not these weird ones.
JGT: One piece of logic would be: UTC is already special cased, if it’s Etc/GMT* then we retain it. That’s the worst logic, there may be better.
FYT: One problem with Etc/GMT* is that we see 24 of these here, but they don’t have the half-hour ones. Once we open this, should we have GMT +5,30. That was used in India.
JGT: That doesn’t matter, the half-hour ones don’t exist. The purpose of these time zones is to support areas (for example) in the middle of the ocean. It’s not to substitute for offsets, but rather these are IANA time zones that are not under the jurisdiction of any county.
RGN: The IANA database does not contain any name that doesn’t look like Ect/GMT- followed by a number.
SFC: This comes up a lot in these type of discussion where I see the job of the specification is to encode invariants that developers can rely on. If this is an invariant that we can agree on, we should put it in the spec. We’re out of time, though.