René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"test_runner: MockTimers does not support Temporal","articleBody":"### What is the problem this feature solves?\n\nAs of Node.js 26, `Temporal` is enabled by default ([#62526](https://github.com/nodejs/node/pull/62526)), and the platform is in the process of growing Temporal support across its APIs ([#57891](https://github.com/nodejs/node/issues/57891), [#63154](https://github.com/nodejs/node/issues/63154), [#63312](https://github.com/nodejs/node/issues/63312)). One gap that doesn't seem to be tracked anywhere yet: `node:test`'s `MockTimers` has no way to control `Temporal.Now`.\n\n`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.\n\nConcretely, 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.\n\n### Repro\n\n```js\nimport { mock } from \"node:test\";\n\nmock.timers.enable({ apis: [\"Temporal\"] });\n// TypeError [ERR_INVALID_ARG_VALUE]: The property 'options.apis' must be one of:\n// ['setTimeout', 'setImmediate', 'setInterval', 'Date']\n\nmock.timers.enable({ apis: [\"Date\"], now: 0 });\nconsole.log(new Date().toISOString());                 // 1970-01-01T00:00:00.000Z (mocked)\nconsole.log(Temporal.Now.instant().toString());        // current real time (NOT mocked)\n```\n\n### What is the feature you are proposing to solve the problem?\n\nExtend `MockTimers` so that, when `Temporal` is in the `apis` list, the following are tied to the mock clock:\n\n- `Temporal.Now.instant()`\n- `Temporal.Now.zonedDateTimeISO(timeZone?)`\n- `Temporal.Now.plainDateTimeISO(timeZone?)`\n- `Temporal.Now.plainDateISO(timeZone?)`\n- `Temporal.Now.plainTimeISO(timeZone?)`\n- `Temporal.Now.timeZoneId()` (probably leave passthrough; only the clock should be virtual)\n\n`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).\n\nThis likely depends on [#63312](https://github.com/nodejs/node/issues/63312) (internal Temporal utils) landing first, since `MockTimers` would need a way to construct `Temporal.Instant`s from the mock epoch ms without round-tripping through `Date`.\n\n### What alternatives have you considered?\n\n- 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.\n- Userland: monkey-patch `Temporal.Now` in test setup. Brittle and doesn't compose with `mock.timers`.\n- `@sinonjs/fake-timers` has the same gap upstream, so dropping the built-in runner doesn't help.\n\nFiling 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.","author":{"url":"https://github.com/ethanresnick","@type":"Person","name":"ethanresnick"},"datePublished":"2026-05-16T20:40:00.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/63369/node/issues/63369"}