test_runner: MockTimers does not support Temporal

從 node:test MockTimers API 開始，使用 issue 中的範例重現文件所述的 Temporal 失敗。檢視對 issue #63312 的依賴，並確定 Temporal.Now 應如何與 Date 共用模擬時鐘。完成的標準是：如描述所述，可以透過 MockTimers 選取、推進和凍結 Temporal，且列出的 Temporal.Now 方法能以決定性的方式運作。

What is the problem this feature solves?

As of Node.js 26, Temporal is enabled by default (#62526), and the platform is in the process of growing Temporal support across its APIs (#57891, #63154, #63312). One gap that doesn't seem to be tracked anywhere yet: node:test's MockTimers has no way to control Temporal.Now.

MockTimers.enable({ apis }) accepts 'setTimeout' | 'setInterval' | 'setImmediate' | 'Date'. Passing 'Temporal' (or any Temporal-related token) throws ERR_INVALID_ARG_VALUE. There is also no documented way to advance / freeze Temporal.Now.instant(), Temporal.Now.zonedDateTimeISO(), etc. via the mock clock.

Concretely, this means any code that reads "now" via Temporal.Now instead of Date.now() can't be tested deterministically with the built-in test runner. With Temporal now being the recommended way to do date/time work, this is increasingly the common case — code migrating away from Date loses its ability to use MockTimers for time-based assertions.

Repro

import { mock } from "node:test";

mock.timers.enable({ apis: ["Temporal"] });
// TypeError [ERR_INVALID_ARG_VALUE]: The property 'options.apis' must be one of:
// ['setTimeout', 'setImmediate', 'setInterval', 'Date']

mock.timers.enable({ apis: ["Date"], now: 0 });
console.log(new Date().toISOString());                 // 1970-01-01T00:00:00.000Z (mocked)
console.log(Temporal.Now.instant().toString());        // current real time (NOT mocked)

What is the feature you are proposing to solve the problem?

Extend MockTimers so that, when Temporal is in the apis list, the following are tied to the mock clock:

• Temporal.Now.instant()
• Temporal.Now.zonedDateTimeISO(timeZone?)
• Temporal.Now.plainDateTimeISO(timeZone?)
• Temporal.Now.plainDateISO(timeZone?)
• Temporal.Now.plainTimeISO(timeZone?)
• Temporal.Now.timeZoneId() (probably leave passthrough; only the clock should be virtual)

mock.timers.tick(ms) and mock.timers.setTime(ms) should advance Temporal's view of "now" the same way they advance Date.now(). The natural ergonomic is for 'Date' and 'Temporal' to be independently selectable but to share one underlying mock clock (so a test can mock both and have them agree).

This likely depends on #63312 (internal Temporal utils) landing first, since MockTimers would need a way to construct Temporal.Instants from the mock epoch ms without round-tripping through Date.

What alternatives have you considered?

• Userland: wrap Temporal.Now in a project-level abstraction that reads from a clock the tests can mock. Works but is viral — every consumer has to use the wrapper.
• Userland: monkey-patch Temporal.Now in test setup. Brittle and doesn't compose with mock.timers.
• @sinonjs/fake-timers has the same gap upstream, so dropping the built-in runner doesn't help.

Filing per discussion in nodejs/node#57891 (which explicitly scopes out test_runner/generic support) — happy to take this on if there's interest and #63312 looks close to landing.