Should JS Temporal accept undefined or a generic string for the primary era?

[sffc]

I think the answer to this question is "no". If you want the extended year, use year instead of eraYear. If you list eraYear, you must list a valid era scoped to the calendar.

Make sense? @ptomato @justingrant

[Manishearth]

I kind of think this is fine but it's not really necessary either way.

ICU4X accepts None here but that's more because it's trying to have an API work for eraYear and extendedYear simultaneously.

[justingrant]

IMO it's clearer if there are (only) two choices:

• Supply year
• Supply both eraYear and era.

So I think the right answer is "no".

That said, what is extendedYear ?

[Manishearth]

I think here extendedYear is year, I don't remember what the Temporal names are.

[sffc]

"Extended year" is a CLDR term coming from https://unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table

Description	CLDR Name	CLDR Symbol	Temporal Name
The year number within a specific era	Calendar year	y	eraYear
The year number encompassing all supra-year fields	Extended year	u	year

[ptomato]

Discussion in Temporal meeting 2025-04-03: In past discussions we've come down strongly in favour of what Justin said in #28 (comment): either year or era+eraYear, not era and eraYear individually.

[sffc]

TG2 approval: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-04-03.md#should-js-temporal-accept-undefined-or-a-generic-string-for-the-primary-era-28

[sffc]

Note: I think this issue implies that the no-era calendars (chinese, dangi) simply will never accept nor return an era or era year.

[ptomato]

Closed by #39