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
To the extent we care about reducing calls to user-code, it's possible to not always get the Calendar's dateAdd and dateUntil if you know your not gonna need it for relative-rounding. The case where I've found it's unnecessarily being called is for when relativeTo is a PlainDate and the largest needed unit is <= day. You don't need to involve the calendar for that.
arshaw
changed the title
Fewer Calls: Calendar dateAdd/dateUntil and rounding w/ PlainDate
Fewer CalendarDateAdd/DateUntil calls during non-relative rounding w/ PlainDate
Feb 29, 2024
arshaw
changed the title
Fewer CalendarDateAdd/DateUntil calls during non-relative rounding w/ PlainDate
Fewer CalendarDateAdd/DateUntil calls during day-rounding w/ PlainDate
Feb 29, 2024
There's a tradeoff between complexity in figuring out in advance whether you need to Get the method, and unnecessarily Getting it. For sure at one point #2519 was more complicated in this regard than what it currently is. I think it'd be informative if we could see what the effect on the spec text would be.
In the current code, the place where this decision should be made is very close to plainDateTimeOrRelativeToWillBeUsed. Not literally using that variable, but making a similar variable very near that position.
After that point in the code, RoundDuration, (BalanceTimeDuration or AdjustRoundedDurationDays), and BalanceDateDurationRelative all expect calendarRecs, but if the refactor that #2792 proposes happens, new functions will be written and it'll lead to a much more natural point at which to short-circuit.
I propose we reassess this issue after further exploring #2792
After #2826, we can rewrite this to be an editorial change. At that point, none of the test262 tests should be affected. It looks like the only thing that changed in your diff above was user code calls.
To the extent we care about reducing calls to user-code, it's possible to not always
get
the Calendar'sdateAdd
anddateUntil
if you know your not gonna need it for relative-rounding. The case where I've found it's unnecessarily being called is for whenrelativeTo
is a PlainDate and the largest needed unit is <= day. You don't need to involve the calendar for that.I've removed the relevant calls from the test262 tests (might not be comprehensive):
Branch: https://github.com/fullcalendar/test262/tree/temporal-fewer-calls-rounding-day-pd
Diff: tc39/test262@main...fullcalendar:test262:temporal-fewer-calls-rounding-day-pd
Affects more than just Duration::round. Affects the since/until methods too.
The text was updated successfully, but these errors were encountered: