Run an app in another time zone

The report that lands on the wrong day, the reminder that fires an hour early, the timestamp that reads as tomorrow - most of it only shows up in a zone you are not sitting in. This gives one process its own offset, while your system zone stays exactly where it was.

Why the usual answers do not help

Changing the Windows time zone changes it for everything - your calendar, your logs, your meetings - and on a managed machine it may not be yours to change.
Setting TZ works for some runtimes and not others. A native Windows application reading GetTimeZoneInformation will not notice it at all.
The browser developer tools override the zone for a web page, which is excellent, and irrelevant to a desktop application.

One process, one offset

The session carries its own offset. The application asks Windows what zone it is in and gets that answer, while every other program on the machine gets the real one.

# The same moment, seen from the American west coast
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# Just the zone - today's real date, someone else's clock
chrono run "C:\apps\test.exe" --zone +09:00

The calculator answers the other half of the question - what a given moment actually reads as somewhere else. Converting keeps the instant and changes only the wall clock, which is exactly how a date lands on the wrong day:

$ chrono calc --base 2027-01-15T09:00:00 --zone +01:00 --to-zone -08:00
Chrono Mock - date calculator
  base:    2027-01-15T09:00:00
  step 1:  zone -08:00  -> 2027-01-15T00:00:00
  result:  2027-01-15T00:00:00
  formats:
    ISO date      2027-01-15
    ISO datetime  2027-01-15T00:00:00-08:00
    US            01/15/2027
    PL            15.01.2027

Nine in the morning in central Europe is midnight on the American west coast. Same instant, and a daily report that groups by local date puts it in a different day depending on where it runs.

Honest limits, and they matter here

The session zone is a fixed offset with no daylight saving.

A session set to +01:00 stays at +01:00 whether its clock reads January or July. A run that crosses a real transition therefore drifts an hour from what that zone would actually show, and forcing an application through a daylight saving transition is not something this tool does yet. The date calculator says so rather than guessing.

The zone reports itself as "Chrono Session", a name no Windows registry knows. Anything mapping that name back to a zone - .NET's TimeZoneInfo.Local among them - falls back to the offset instead, which is the right answer. An application insisting on a registry name will not find one.
Java does not pick the session zone up. The wall clock and elapsed time are covered, the zone is not. It is a known gap, stated rather than hidden.
In Chromium and Electron mode the zone follows the host. The instant is faked, the local-time getters are not.
Offsets run from -14:00 to +14:00 in whole minutes. Anything outside that is refused rather than quietly wrapped.

Which of those applies to your application is measurable rather than guessable. The session reports its own coverage →

Try it

Download for Windows Read the FAQ