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

How to handle dates before the start or after the end of eras that start or end mid-year? #1300

Closed
justingrant opened this issue Jan 16, 2021 · 2 comments

Comments

@justingrant
Copy link
Collaborator

@Manishearth brought up a problem in #1220 (comment) that's worth a separate issue.

Japanese eras may start mid-year:

> new Date("2019-04-31").toLocaleString('en-US-u-ca-japanese', {era: 'short'})
"4/30/31 Heisei, 5:00:00 PM"
> new Date("2020-05-31").toLocaleString('en-US-u-ca-japanese', {era: 'short'})
"5/30/2 Reiwa, 5:00:00 PM"
> new Date("2020-01-02").toLocaleString('en-US-u-ca-japanese', {era: 'short'})
"1/1/2 Reiwa, 4:00:00 PM"

This means:

  • Heisei 31 was a year with four months in it (we suspect "November 5, Heisei 31" would still be an intelligible string, however)
  • Reiwa 1 was a year with eight months in it, which started from May and ended in December

Furthermore, while Reiwa started on May 1 2019, eras can begin in the middle of a month (and from what I can tell, most do -- e.g. the first day of Jōkyō was February 21).

In this model, {month: 5, era: "reiwa", year: 1} is highly ambiguous -- it's either May 2019, or it's September 2019, and in both models you will have to mark a set of month numbers as invalid (which is fine, we have to do that for supporting lunisolar calendars anyway).

Regardless of which month properties we offer and what they're named, presumably there will be a way for a developer to ask for Feb 1, Reiwa 1, which doesn't exist because Reiwa started on May 1.

I assume that if overflow: 'reject' then that date should throw because it's invalid. But if overflow: 'constrain', what should we do?

Options:

  1. RangeError (same as overflow: 'reject')
  2. Consider it as Feb 1, 2019, because 2019 is first year of Reiwa. Internally, the era/eraYear combination would be used to calculate a year, and that signed year would be used to evaluate the month and day. In other words, (2) would make years and months unrelated to each other.
  3. Something else?

My guess is that (2) is probably the best solution, although (1) is currently how #1245 currently works. Repro:

Temporal.PlainDate.from({ eraYear: 1, era: 'reiwa', month: 2, day: 1, calendar: 'japanese' }, { overflow: 'constrain' })
@ptomato
Copy link
Collaborator

ptomato commented Jan 19, 2021

Consensus from 2021-01-19 meeting: month is defined as an index into the months of the signed (algorithmic) year. To the best of our knowledge, this matches the existing cultural practice for the Japanese calendar.

Closing this, as I believe it's the status quo — feel free to reopen if I'm wrong about that.

@ptomato ptomato closed this as completed Jan 19, 2021
@justingrant
Copy link
Collaborator Author

justingrant commented Jan 20, 2021

To clarify: the decision is (2) in #1300 (comment).

Repro:

Temporal.PlainDate.from({ eraYear: 1, era: 'reiwa', month: 2, day: 1, calendar: 'japanese' }, { overflow: 'constrain' }).getISOFIelds().isoMonth
// expected: 2

Temporal.PlainDate.from({ eraYear: 1, era: 'reiwa', month: 2, day: 1, calendar: 'japanese' }, { overflow: 'reject' })
// expected: RangeError

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