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
While everyone in 2020 mostly agrees with the concept of a solar day, months and years are concepts that are inherently calendar-dependent.
Any date-time arithmetic that is rooted in the ISO calendar involving months and years is bound to give unexpected results that will carry over poorly to other calendars.
TL:DR; any arithmetic with units larger than days cannot be satisfactorily done in a calendar-agnostic way.
We cannot have our cake and eat it too.
What are our options?
What even is Temporal.Calendar?
Mechanism to allow arbitrary calendar systems to be implemented on top of Temporal.
This will be taken care of for most users out of the box, and doesn't require any extra know-how.
Can be used to implement non-built-in calendar systems.
Plan to expose non-ISO, commonly-used regional calendars via ECMA-402.
How will it work? (using Temporal.Date as an example)
Previously, Temporal.Date had three internal slots: year, month and day.
Now, it has four slots: [[IsoYear]], [[IsoMonth]], [[IsoDay]] and [[Calendar]].
The corresponding fields on Temporal.Date.prototype should forward requests to the calendar.
Calendars can add calendar-specific accessors, eg: yearType for the Hebrew Calendar.
An instance is expected to have stateless behavior; i.e., all methods should be deterministic.
(There would be no mechanism to enforce this for userland calendars, but the author should ensure this in order to prevent unexpected behavior such as lack of round-tripping.)
What even is Temporal.Calendar?
How would people use it?
letdate=Temporal.now.date();// a Temporal.Dateconsole.log(date.withCalendar("iso").month);// 11, i.e. Novemberconsole.log(date.withCalendar("hebrew").month);// 2, i.e. Heshvanconsole.log(date.withCalendar("japanese").era);// "reiwa"