Eine App in einer anderen Zeitzone ausführen

Der Bericht, der am falschen Tag landet, die Erinnerung, die eine Stunde zu früh feuert, der Zeitstempel, der wie morgen aussieht - das meiste zeigt sich nur in einer Zone, in der Sie nicht sitzen. Dies gibt einem Prozess einen eigenen Offset, während Ihre Systemzone genau dort bleibt, wo sie war.

Warum die üblichen Antworten nicht helfen

Die Windows-Zeitzone zu ändern ändert sie für alles - Ihren Kalender, Ihre Logs, Ihre Besprechungen - und auf einem verwalteten Rechner steht Ihnen das womöglich nicht zu.
TZ zu setzen funktioniert für manche Laufzeiten und für andere nicht. Eine native Windows-Anwendung, die GetTimeZoneInformation liest, bemerkt es überhaupt nicht.
Die Entwicklerwerkzeuge des Browsers überschreiben die Zone für eine Webseite, was hervorragend ist und für eine Desktop-Anwendung irrelevant.

Ein Prozess, ein Offset

Die Sitzung trägt ihren eigenen Offset. Die Anwendung fragt Windows, in welcher Zone sie ist, und bekommt diese Antwort, während jedes andere Programm auf dem Rechner die echte bekommt.

# Derselbe Zeitpunkt, von der amerikanischen Westküste aus gesehen
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# Nur die Zone - das echte Datum von heute, die Uhr von jemand anderem
chrono run "C:\apps\test.exe" --zone +09:00

Der Rechner beantwortet die andere Hälfte der Frage - was ein gegebener Zeitpunkt anderswo tatsächlich anzeigt. Das Umrechnen behält den Zeitpunkt und ändert nur die Wanduhr, und genau so landet ein Datum am falschen Tag:

$ 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

Neun Uhr morgens in Mitteleuropa ist an der amerikanischen Westküste Mitternacht. Derselbe Zeitpunkt, und ein Tagesbericht, der nach dem lokalen Datum gruppiert, ordnet ihn je nach Ausführungsort einem anderen Tag zu.

Ehrliche Grenzen, und sie zählen hier

Die Sitzungszone ist ein fester Offset ohne Sommerzeit.

Eine auf +01:00 gestellte Sitzung bleibt bei +01:00, ob ihre Uhr nun Januar oder Juli anzeigt. Ein Lauf, der einen echten Wechsel überschreitet, weicht daher um eine Stunde von dem ab, was diese Zone tatsächlich zeigen würde, und eine Anwendung durch einen Sommerzeitwechsel zu schicken, kann dieses Werkzeug noch nicht. Der Datumsrechner sagt das, statt zu raten.

Die Zone meldet sich als „Chrono Session“, ein Name, den keine Windows-Registry kennt. Alles, was diesen Namen auf eine Zone zurückführt - darunter .NETs TimeZoneInfo.Local -, fällt stattdessen auf den Offset zurück, was die richtige Antwort ist. Eine Anwendung, die auf einem Registry-Namen besteht, findet keinen.
Java übernimmt die Sitzungszone als Offset. Die Sitzungszone hat keine Sommerzeit und keine Stadt dahinter, deshalb benennt Java sie nach ihrem Offset - GMT+05:30 für eine Sitzung bei +05:30.
Im Chromium- und Electron-Modus lesen auch die Seiten die Sitzungszone. Es ist derselbe feste Versatz: Jede Seite und jeder Worker wird darauf gesetzt und prüft, was er liest. Der Hauptprozess einer Electron-Anwendung führt JavaScript in Node aus, das die Sitzung nicht erreicht, sodass er die echte Uhr behält.
Offsets reichen von -14:00 bis +14:00 in ganzen Minuten. Alles außerhalb wird abgelehnt, statt stillschweigend umzubrechen.

Was davon auf Ihre Anwendung zutrifft, lässt sich messen statt erraten. Die Sitzung meldet ihre eigene Abdeckung →

Ausprobieren

Für Windows herunterladen Die FAQ lesen