Improve efficiency of date add/until

[sffc]

The specification algorithm is designed to be readable, but it is not fast, because it adds one month and one year at a time. There are two cases that can be optimized:

1. Adding 1000 months to a date requires running a loop for each year, and adding the number of days in each year until the month is in-range. For calendars with a fixed number of months per year, this is trivial to fast-path. For calendars with a variable number of months per year, this can likely still be fast-pathed, but more care needs to be taken.
2. Adding 1000 days to a date requires running a loop for each month, and adding the number of days in each month until the day is in-range. No calendar has a fixed number of days per month. But, a fast-path could be to add a years-worth of days all at once, and then to add multiple years at once, being careful about leap years, of course.

[robertbastian]

Adding 1000 days to a date requires running a loop for each month, and adding the number of days in each month until the day is in-range. No calendar has a fixed number of days per month. But, a fast-path could be to add a years-worth of days all at once, and then to add multiple years at once, being careful about leap years, of course.

It could be cheaper to convert to RD, add 1000, and convert back.

[Manishearth]

Yeah, that makes sense.

Adding years will always be cheap. When it comes to adding months, you have:

• For solar calendars this is entirely computable using a formula
• For Hebrew this is also computable with a formula
• For Hijri this is computable with a formula if you are outside of UAQ/simulated range. So you use the regular algorithm to get to the range edge and then apply a formula
• For Chinese this is approximatable by applying a mean synodic month length, and you can get the exact answer by then using the yearinfo for that year.

And for adding weeks/days we can just manipulate RDs.

At the moment, testing in V8, adding month/day values that keep us within Temporal range is not noticeably slow.

[tanishqshrivas]

can you assign me this @sffc

[Manishearth]

At the moment, testing in V8, adding month/day values that keep us within Temporal range is not noticeably slow.

I was wrong, there are some values which are super slow

#7206 (comment)

I think the code does not know in advance that this will be out of range.

[sffc]

I'd like to have more thorough tests in place before landing algorithm changes. #7215

[sffc]

I think the code does not know in advance that this will be out of range.

Let's fix this as part of #7076. If the DateDuration has a year number that will definitely exceed the pan-calendar year limit, then we can exit early.

[Manishearth]

Sounds reasonable!