Reference implementation has pathologically slow date difference case

[ptomato]

const a = new Temporal.PlainDate(2025, 9, 19, 'gregory');
const b = new Temporal.PlainDate(275760, 1, 1, 'gregory');
a.until(b, { largestUnit: 'months' });

The above script takes >10 seconds to execute!

This isn't a problem with the spec text, as the observable behaviour is all correct. But we should definitely cover this case in test262 (as it must not be covered or it would have been noticed earlier) and then additionally it would be nice to profile the reference implementation to figure out why it's so slow and improve that, so that we don't take +10 seconds on our test262 tests.

(I discovered this with the exhaustive test scripts that I'm writing.)

[nekevss]

Was this tested with any of the other implementations?

[linusg]

temporal_rs doesn't have this implemented: https://github.com/boa-dev/temporal/blob/8e509acb3b34cbbc078103957e4c041623539b49/src/builtins/core/calendar.rs#L387

[ptomato]

It isn't slow in the Firefox implementation. I'm pretty sure it's just a peculiarity of the reference implementation's reliance on reverse-engineering the calendar data from Intl.DateTimeFormat.

[nekevss]

temporal_rs doesn't have this implemented

Ah, yeah. So we need to double check icu_calendar when that is stabilized.

[gibson042]

PR: #3154

[ptomato]

Thanks for the fix! Going to reopen this for now, though, as we still have a similar pathological case in addition:

const a = new Temporal.PlainDate(2025, 9, 19, 'gregory);
const d = new Temporal.Duration(0, 3284811, 13);
a.add(d);

I'd also like to investigate ways to make it faster for non-12-month calendars as well.

[ptomato]

(Running the code snippet from the OP with a non-12-month calendar even crashes by exceeding the max number of Map entries.)