Setting process.env.TZ inside Jest does not change the time zone

Symptom

A suite with day-boundary cases — 22:00 UTC on 31 August is already 1 September in Central Europe — is green on every developer machine. The project "pins" the zone in a setup file:

// jest.config.json: "setupFiles": ["<rootDir>/config/jest/tz.js"]
process.env.TZ = 'Europe/Prague';

Run the same suite with the parent process in another zone and it goes red: in our projects six tests failed, and nine once the date helper was switched back to UTC. A console.log inside the test even shows process.env.TZ === 'Europe/Prague' — while new Date(2026, 0, 1).getTimezoneOffset() still returns the parent's offset.

Cause

Jest runs each test file in a sandbox whose process object is a copy, and its process.env is a separate object filled from the real environment (jest-util, createProcessEnv: a proxy populated with Object.assign(proxy, process.env)). An assignment in a test, in setupFiles or in setupFilesAfterEnv lands in that copy; the real environment of the process never changes, so neither does its time zone.

globalSetup runs in the parent Jest process before the test files run. An assignment there changes the real environment, and worker processes started afterwards inherit it.

Measured with the parent in America/New_York, the same one-line test (expect(new Date(2026, 0, 1).getTimezoneOffset()).toBe(-60)):

With no TZ on a machine that already runs in Central European time, all six rows pass — which is exactly why nobody noticed.

Fix

// config/jest/global-setup.js — referenced as "globalSetup" in the Jest config
module.exports = async () => {
  process.env.TZ = 'Europe/Prague';
};

• Assert the zone in the test, by offset. expect(new Date(2026, 0, 1).getTimezoneOffset()).toBe(-60) fails loudly when the pin does not work; reading process.env.TZ proves nothing, because the sandbox copy says whatever was written into it.
• Run the day-boundary suite at least once under a foreign TZ. A pin that was never tested against another zone has never been shown to work.
• On Windows, set it from PowerShell ($env:TZ = 'America/New_York'). In our Git Bash for Windows, TZ=America/New_York node -p "process.env.TZ" printed undefined — the variable did not reach the native node process, so a "foreign zone" run from there silently used the machine's zone.

Notes

• The alternative to globalSetup is the environment that launches Jest (TZ=Europe/Prague jest in a POSIX shell, $env:TZ in PowerShell); anything set later, inside the test runtime, is too late.
• Setting process.env.TZ does not affect Dates (jestjs/jest #9856)
• Related: A test outside the release command guards nothing · DateTime: write full ISO, derive days locally