Most of methods of Temporal.PlainDate requires a fresh new Calendar instance for each Temporal.PlainDate

[Constellation]

The current spec creates a fresh instance for each Temporal.PlainDate. Since most of fields of Temporal.PlainDate touches calendars, Temporal.PlainDate almost always requires two objects per instance.

This fresh object is meaningful only when the user adds adhoc method to these created calendar instances after creating Temporal.PlainDate. But the use of custom calendar can be cleanly achieved by passing an optional calendar parameter to the Temporal.PlainDate constructor.

So, how about removing necessity of creating a calendar object for known calendars for performance and memory saving?

[justingrant]

At the Champions meeting this morning, we discussed the naming options mentioned above. Consensus was that there were only two acceptable options for the property names of time zone and calendar properties in Temporal:

• calendarId / timeZoneId - Note that xxxID is not OK because it conflicts with W3C casing guidelines, which we don't have to follow...but we don't want to confuse web platform developers either.
• calendarCode / timeZoneCode - If we must change the name, aligning with the existing MDN docs of Intl.DisplayNames.p.of (which use code) seems like the best choice.

If we were starting from a blank slate then either of these would be OK.

But given that we're late in Stage 3 with implementations underway, we're concerned about the additional work that a name-change would require, because if we go with the xxxCode names, then we also must rename the id properties of Temporal.Calendar and Temporal.TimeZone, which magnifies the scope of the breaking change.

Before asking @ptomato and all implementers to do a lot more work for a name change that none of us are convinced will add value to userland developers, we'd first like to have a (hopefully short!) plenary discussion to verify that all this additional work is worth it.

Therefore, in January's plenary we'll plan to split discussion of this issue into two parts: one about the overall changes in #2482, and a second discussion at the end where we'll go over the naming choices. Our hope is that there can be plenary-wide consensus that the less-work option is OK. I encourage everyone to keep an open mind and to stay pragmatic! :-)

Thanks!

[ptomato]

Closed by #2482.

[justingrant]

Really closed by #2482. :-)