How should calendars expose calendar-specific date and time properties?

[sffc]

Examples of such properties:

• isLeapYear, weekOfYear, dayOfWeek, daysInMonth, daysInYear (currently ISO-based computed properties on Temporal.Date)
• yearType (such as "kesidran", "chaser", "maleh" in the Hebrew calendar)
• Possibly other interesting Calendar-specific computed properties

I suggested the following possible change, creating a new object for accessing these properties (name bikeshedding aside):

// Current
d.weekOfYear
d.isLeapYear

// New
d.dateProperties.weekOfYear
d.dateProperties.isLeapYear

[littledan]

Do we have a sense of how how finite this set is? If it's just a few things, could we keep adding them as getters to Temporal.Date.prototype?

[kaizhu256]

why use getters instead of methods?

[pipobscure]

I think we need to come up with a list of things that are intrinsic to a date/datetime and things that are related calendaric information.

For example: The month number is intrinsic to the date. Whether the date is in a LeapYear is purely calendaric.

I suggest we think about moving purely calendaric information to the calendar objects and only have intrinsic date information accessible directly from the core object.

See #290 for more details

[sffc]

Could we spec some kind of forwarding mechanism? Like, you call .weekOfYear on a Temporal.Date. The Temporal.Date receives the request for the property, and since the property doesn't exist, it "forwards" the call to its calendar slot. Then, if the field doesn't exist on calendar, undefined is returned.

[gibson042]

Relevant JSR-310 design document found by following links from Rust (thanks @jasonwilliams!): https://github.com/ThreeTen/threeten/wiki/Multi-calendar-system

[sffc]

From 2020-02-19 Temporal call: calendar-specific properties should be accessor getters on the Temporal [Date][Time] objects. These getters should have behavior roughly equivalent to:

get foo(...args) {
  return this.calendar.foo?.(this, ...args);
}

In the spec, the getter should access the string property "foo" of the internal slot [[Calendar]].

There should be built-in getters following this pattern for all properties of the full ISO calendar in 262; conforming 402 implementations should add additional properties required by 402 calendars. Custom calendars are welcome to modify Temporal.prototype to add conforming getters corresponding to any additional fields they need.

Due to the conclusion in in #290, .year, .month, and .day will also follow these semantics.