test_runner: MockTimers does not support Temporal

Comece pela API node:test MockTimers e reproduza a falha documentada do Temporal usando o exemplo na issue. Revise a dependência da issue #63312 e determine como Temporal.Now deve compartilhar o relógio simulado com Date. Considera-se concluído quando Temporal puder ser selecionado, avançado e congelado por meio de MockTimers conforme descrito, com os métodos Temporal.Now listados comportando-se de forma determinística.

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.