You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
RangeError (same as overflow: 'reject')
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.
Something else?
My guess is that (2) is probably the best solution, although (1) is currently how #1245 currently works. Repro:
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.
@Manishearth brought up a problem in #1220 (comment) that's worth a separate issue.
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 ifoverflow: 'constrain'
, what should we do?Options:
overflow: 'reject'
)era
/eraYear
combination would be used to calculate ayear
, 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.My guess is that (2) is probably the best solution, although (1) is currently how #1245 currently works. Repro:
The text was updated successfully, but these errors were encountered: