Draai een app in een andere tijdzone

Het rapport dat op de verkeerde dag belandt, de herinnering die een uur te vroeg afgaat, de tijdstempel die als morgen leest - het meeste daarvan komt alleen voor in een zone waarin je niet zit. Dit geeft één proces zijn eigen offset, terwijl je systeemzone precies blijft waar hij was.

Waarom de gebruikelijke antwoorden niet helpen

De Windows-tijdzone wijzigen wijzigt hem voor alles - je agenda, je logboeken, je vergaderingen - en op een beheerde machine is het misschien niet aan jou om dat te doen.
TZ instellen werkt voor sommige runtimes en voor andere niet. Een native Windows-applicatie die GetTimeZoneInformation leest, merkt er helemaal niets van.
De ontwikkelaarstools van de browser overschrijven de zone voor een webpagina, wat uitstekend is, en irrelevant voor een desktopapplicatie.

Eén proces, één offset

De sessie draagt haar eigen offset. De applicatie vraagt Windows in welke zone ze zit en krijgt dat antwoord, terwijl elk ander programma op de machine de echte krijgt.

# Hetzelfde moment, gezien vanaf de Amerikaanse westkust
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# Alleen de zone - de echte datum van vandaag, de klok van iemand anders
chrono run "C:\apps\test.exe" --zone +09:00

De calculator beantwoordt de andere helft van de vraag - wat een gegeven moment elders werkelijk aangeeft. Omrekenen behoudt het moment en verandert alleen de wandklok, en zo belandt een datum op de verkeerde dag:

$ 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

Negen uur 's ochtends in Midden-Europa is middernacht aan de Amerikaanse westkust. Hetzelfde moment, en een dagrapport dat op lokale datum groepeert, plaatst het op een andere dag, afhankelijk van waar het draait.

Eerlijke grenzen, en ze tellen hier

De sessiezone is een vaste offset zonder zomertijd.

Een sessie die op +01:00 is gezet, blijft op +01:00, of haar klok nu januari of juli aangeeft. Een run die een echte overgang passeert, wijkt daarom een uur af van wat die zone werkelijk zou tonen, en een applicatie door een zomertijdovergang sturen is iets wat dit gereedschap nog niet doet. De datumcalculator zegt dat in plaats van te gokken.

De zone meldt zichzelf als “Chrono Session”, een naam die geen Windows-register kent. Alles wat die naam terugvertaalt naar een zone - waaronder .NET's TimeZoneInfo.Local - valt in plaats daarvan terug op de offset, wat het juiste antwoord is. Een applicatie die op een registernaam staat, zal er geen vinden.
Java neemt de sessiezone over als offset. De sessiezone heeft geen zomertijd en geen stad erachter, dus Java noemt haar naar haar offset - GMT+05:30 voor een sessie op +05:30.
In de Chromium- en Electron-modus lezen de pagina's de sessiezone ook. Het is dezelfde vaste afwijking: elke pagina en elke worker wordt erop gezet en controleert wat hij leest. Het hoofdproces van een Electron-toepassing draait JavaScript in Node, waar de sessie niet bij kan, dus het houdt de echte klok.
Offsets lopen van -14:00 tot +14:00 in hele minuten. Alles daarbuiten wordt geweigerd in plaats van stilletjes omgeslagen.

Welke daarvan voor je applicatie geldt, is meetbaar en niet te raden. De sessie rapporteert haar eigen dekking →

Probeer het

Downloaden voor Windows Lees de FAQ