`Temporal` behavior is not spec-compliant

[fabon-f]

Version

26.0.0

Platform

Darwin (redacted host name) 25.4.0 Darwin Kernel Version 25.4.0: Thu Mar 19 19:32:36 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T8103 arm64

Subsystem

No response

What steps will reproduce the bug?

bugs for iso8601 calendar which are already fixed in upstream:

// 1.
new Temporal.Duration(0, 1, 0, 0, 1).round({ smallestUnit: 'months', roundingMode: 'expand', relativeTo: new Temporal.PlainDate(2020, 1, 31) }).toString();
// 2.
Temporal.Instant.from('2020-01-01T00:00:00.1234567890Z');

incorrect behavior for non-ISO calendars:

// 3.
Temporal.PlainDate.from({ year: 2020, month: 1, day: 40, calendar: 'gregory' });
// 4.
Temporal.PlainDate.from({ year: -1, month: 1, day: 1, calendar: 'gregory' });
// 5.
Temporal.PlainDate.from({ year: 5786, monthCode: 'M05L', day: 1, calendar: 'hebrew' });
// 6.
Temporal.PlainDate.from('2026-05-01[u-ca=chinese]').year;

How often does it reproduce? Is there a required condition?

always, without any conditions

What is the expected behavior? Why is that the expected behavior?

1. "P2M"
2. RangeError is thrown
3. RangeError is not thrown
4. RangeError is not thrown
5. RangeError is not thrown
6. 2026

What do you see instead?

1. "PT0S"
2. RangeError is not thrown
3. RangeError is thrown
4. RangeError is thrown
5. RangeError is thrown
6. 4663

Additional information

I tested Temporal test cases in test262, and Node.js failed for many cases, mainly due to wrong behavior for non-ISO calendars. I suspect this is because Node.js uses outdated temporal_rs and ICU4X (but I haven't confirmed my guess yet).

[Renegade334]

We never did land a cargo updater after #61151. (cc @legendecas)