Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CalendarDateToISO: Constrain behaviour for regnal years? #2865

Open
anba opened this issue May 27, 2024 · 2 comments
Open

CalendarDateToISO: Constrain behaviour for regnal years? #2865

anba opened this issue May 27, 2024 · 2 comments

Comments

@anba
Copy link
Contributor

anba commented May 27, 2024

It'd be nice to have some more detailed information how constraining should work for regnal years in the Japanese calendar.

  1. Dates before the start of the era (from SpiderMonkey WIP implementation):
js> Temporal.PlainDate.from({calendar: "japanese", era: "reiwa", eraYear: 1, month: 1, day: 1}).toString()
"2019-05-01[u-ca=japanese]"
js> Temporal.PlainDate.from({calendar: "japanese", era: "reiwa", eraYear: 1, month: 1, day: 1}).era
"reiwa"
js> Temporal.PlainDate.from({calendar: "japanese", era: "reiwa", eraYear: 1, month: 1, day: 1}, {overflow: "reject"}).toString()
typein:1:20 RangeError: calendar field "eraYear" is too large: 1

Whereas the spec polyfill changes to the previous era (for both constrain and reject overflow behaviour):

js> Temporal.PlainDate.from({calendar: "japanese", era: "reiwa", eraYear: 1, month: 1, day: 1}).toString()
"2019-01-01[u-ca=japanese]"
js> Temporal.PlainDate.from({calendar: "japanese", era: "reiwa", eraYear: 1, month: 1, day: 1}).era       
"heisei"
  1. Dates after the end of the era (from SpiderMonkey WIP implementation):
js> Temporal.PlainDate.from({calendar: "japanese", era: "heisei", eraYear: 100, month: 1, day: 1}).toString()
"2019-04-30[u-ca=japanese]"
js> Temporal.PlainDate.from({calendar: "japanese", era: "heisei", eraYear: 100, month: 1, day: 1}).era
"heisei"
js> Temporal.PlainDate.from({calendar: "japanese", era: "heisei", eraYear: 100, month: 1, day: 1}, {overflow: "reject"}).toString()
typein:1:20 RangeError: calendar field "eraYear" is too large: 100

Spec polyfill has (for both constrain and reject overflow behaviour):

js> Temporal.PlainDate.from({calendar: "japanese", era: "heisei", eraYear: 100, month: 1, day: 1}).toString()
"2088-01-01[u-ca=japanese]"
js> Temporal.PlainDate.from({calendar: "japanese", era: "heisei", eraYear: 100, month: 1, day: 1}).era       
"reiwa"

Questions I've asked myself:

  • Does overflow behaviour affect era/eraYear?
  • If yes, does constrain overflow constrain to the start/end of the era?
  • If yes, does reject overflow reject dates before/after the era?
anba added a commit to anba/test262 that referenced this issue May 30, 2024
See also <tc39/proposal-temporal#2865>
requesting for more information how this case should actually be
handled.
@justingrant
Copy link
Collaborator

Meeting 2024-05-30:

  • For constrain we'll treat each era "proleptically": dates before the era starts are mapped to the previous era (without changing the ISO date due to constraining), and dates after the era ends are mapped to later era (again without changing ISO date).
  • For reject, throw if it's before or after the era boundaries.

@gibson042 to make a PR. Because current behavior is unspecified, this will not be a normative change.

@anba
Copy link
Contributor Author

anba commented Jun 19, 2024

I've just found tc39/ecma402#540 which actually wants a different behaviour for reject, namely that reject doesn't throw for dates after the end of the era. I don't know if this should imply that reject should also not throw for dates before the start of the era, though.

ptomato pushed a commit to anba/test262 that referenced this issue Jul 25, 2024
See also <tc39/proposal-temporal#2865>
requesting for more information how this case should actually be
handled.
ptomato pushed a commit to anba/test262 that referenced this issue Jul 25, 2024
See also <tc39/proposal-temporal#2865>
requesting for more information how this case should actually be
handled.
ptomato pushed a commit to tc39/test262 that referenced this issue Jul 25, 2024
See also <tc39/proposal-temporal#2865>
requesting for more information how this case should actually be
handled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants