"useFakeTimers is not supported in this environment" when testing timezone-dependent Intl formatting

Short answer

Two separate things are being conflated. The useFakeTimers is not supported in this environment error is about missing timer globals in your test environment, and jest.setSystemTime() was never designed to change time-zone resolution — it only moves the mocked "now". For your stated goal (an explicit timeZone: 'America/New_York' option), fake timers plus setSystemTime are sufficient once the environment problem is fixed; TZ is only needed when code relies on the default zone.

1. When the "not supported" error appears

The error is thrown when the active test environment does not expose the timer functions (setTimeout, setInterval, clearTimeout, clearInterval) that @jest/fake-timers needs to replace. The standard node and jsdom environments in Jest 27–29 expose these, so fake timers work there out of the box. The error typically shows up when:

• A custom testEnvironment omits the timer globals from its global object.
• An ESM or otherwise nonstandard setup builds a global without them.
• The environment is misconfigured (e.g. an old or third-party environment package).

Likely explanation, not confirmed: since you did not post your jest.config, the most common cause is a custom or overridden testEnvironment. Check for a testEnvironment key and, if it points at a custom class, verify it assigns the timer globals. Also confirm your Jest major version: Jest 26 and earlier default to legacy fake timers, where setSystemTime does not exist at all. Jest 27+ defaults to the modern implementation (backed by @sinonjs/fake-timers), which mocks Date and supports setSystemTime.

2. setSystemTime and Intl time zones

setSystemTime() only changes what the mocked Date reports as "now". It does not touch the process time zone. Intl.DateTimeFormat resolves the default zone from ICU / the host environment, independently of Jest's clock mock. So:

• Explicit timeZone option (your case): deterministic with fake timers alone. The instant is frozen by setSystemTime and the zone is fixed by the option, so host TZ is irrelevant.
• Default zone: set TZ before the Node process starts, e.g. TZ=America/New_York jest in the test script (use cross-env on Windows). Setting process.env.TZ inside a test is unreliable because ICU resolves and caches the zone at process startup.

3. Verifying the mock is applied

Inside the test, assert the clock first, then inspect what zone the runtime actually uses:

jest.useFakeTimers();
jest.setSystemTime(new Date('2026-10-12T00:00:00Z'));

expect(new Date().toISOString()).toBe('2026-10-12T00:00:00.000Z');

// Which zone does the runtime think it's in?
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone);

// Deterministic regardless of host zone:
const fmt = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'short', timeStyle: 'short',
});
expect(fmt.format(new Date())).toBe('10/11/2026, 8:00 PM');

A second cross-check: run the suite once with TZ=UTC and once with TZ=America/New_York. If results differ, some code path depends on the default zone and TZ must be pinned in the test script.

Caveats worth flagging

• Version assumptions here (Jest 27+ modern-timer default) are from general knowledge, not live verification — confirm against your installed version's docs.
• Node builds with small-icu or system ICU may lack full time-zone data, causing formatting differences between machines even with TZ set. Full-icu Node (the default official build) avoids this.