Closed gibson042 closed 1 year ago
We may choose to change this behavior. But I think the current behavior may actually be consistent with other parts of Temporal, which also follow the following rules:
For example, the following code also doesn't throw:
Temporal.PlainTime.from({hour: 12, year: 2023, month: 2, day: 29})
What makes PlainMonthDay a bit weird is that "fields that contribute to the result" can vary more than other types. If there's a monthCode
present in the input, then monthCode
and day
are sufficient to calculate the result. But if there's no monthCode
, then month
can mean a different real-world month in lunisolar calendars if the month is later in the year than a leap month.
We could have designed the algorithm to only require a year
for only lunisolar calendars, or even more narrowly only in lunisolar calendars where month
is larger than the earliest possible leap month. But we chose to design it more restrictively so that code written for one calendar was more likely to work with code written for another calendar.
I wouldn't object to also validating the full date whether or not monthCode
is present, because prohibiting having an invalid date doesn't seem like it will hurt any valid use cases. But I also don't think we must make this change.
While working on #2466, I discovered this surprising and inconsistent behavior:
Since 2023 is not a leap year, both cases should result in a RangeError.
I'm expecting to fix this along with #2466, but it still merits a distinct issue.