Hebrew calendar - support or use a constant era?

[cjtenny]

trafficstars

Context: https://github.com/tc39/proposal-temporal/pull/1245#discussion_r570535413

Should the Hebrew calendar implementation consider a single era with value 'am' or 'ah', or should it not accept any era values?

cc @Manishearth, @justingrant

[Manishearth]

I think we should use am? But I'm not sure.

[justingrant]

Context: in tc39/proposal-temporal#1245, I added eras to all calendars where the current Date.prototytpe.toLocaleDateString('en-US-u-ca-...') displays an era in the output. Only Hebrew, Chinese/Dangi, and ISO don't display one.

[ptomato]

This seems like something that will always be controlled by each implementation's underlying locale data.

[justingrant]

This seems like something that will always be controlled by each implementation's underlying locale data.

This is correct. It's out of scope for the Temporal spec.

But we should decide what we want to do in the current polyfill where currently Hebrew and Chinese/Dangi have no eras. Should they have eras? Leave as-is? Should other calendars have no eras too? The current locale data we have access to via Date and DateTimeFormat is ambiguous about Hebrew because the era is present in Date.prototype.toLocaleDateString but is present in DateTimeFormat.prototype.formatToParts. (Referring to Node 15 output with default options.)

BTW, @cjtenny I've started opening up no-262-spec-impact issues that are solely dependent on locale data over in https://github.com/tc39/ecma402 instead of in the Temporal repo. I think it's OK to leave this issue here (unless @ptomato disagrees), but probably best to put future ones over there.

[ptomato]

I don't object to having it here, but do you mind if I move it over there so that they're all in one place?

[justingrant]

Personally, I'd prefer to move it so we can reduce noise and triage work in this repo.

[srl295]

Context: https://github.com/tc39/proposal-temporal/pull/1245#discussion_r570535413

Should the Hebrew calendar implementation consider a single era with value 'am' or 'ah', or should it not accept any era values?

cc @Manishearth, @justingrant

Ah? Don't think this calendar has ah just am

Are you thinking of another calendar ?

[srl295]

<calendar type="hebrew">
          <calendarSystem type="lunisolar"/>
          <eras>
              <era type="0" start="-3760-10-7"/>
          </eras>
        </calendar>

[srl295]

Ok now I see. Personally I think it could accept an era for orthogonality. Since an era could be visible.

[justingrant]

I think the question is what the era property should return for Temporal.PlainDate and other Temporal objects that use the Hebrew calendar. This came up because the default toLocaleDateString output for the en-US locale doesn't include any era, while all other ICU calendars (except Chinese/Dangi) include era in their default output.

[srl295]

@justingrant but by the same token, the gregorian calendar doesn't return a era in the default en-US locale either, although the era is AD. Similarly, for consistency, Hebrew should be AM.

I don't see the purpose of hasEra in the original implementation. Programmatically, just as you wouldn't want a currency amount without a currency ( 123.45 what? CAD? Bitcoin?), so also an era should be part of the data around a Date even if not visible in presentation. So I would propose always having an enumerated era, even if it's a 1-length enumeration.

[cjtenny]

(The suggestion for 'ah' only came from the last line in this wikipedia section and sounds like if an era is supported, 'am' would make more sense).

[srl295]

(The suggestion for 'ah' only came from the last line in this wikipedia section and sounds like if an era is supported, 'am' would make more sense).

OK, hadn't heard that, but yes it did confuse me with anno hijri. AM is the usual way it is written in English (well, Latin)