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.