Rulează o aplicație într-un alt fus orar

Raportul care ajunge în ziua greșită, memento-ul care sună cu o oră mai devreme, marcajul de timp care se citește ca mâine - cea mai mare parte apare doar într-un fus în care nu te afli. Aici dai unui singur proces propriul decalaj, în timp ce fusul sistemului rămâne exact unde era.

De ce nu ajută răspunsurile obișnuite

Schimbarea fusului orar din Windows îl schimbă pentru tot - calendarul tău, jurnalele, ședințele - iar pe o mașină administrată s-ar putea să nu fie al tău dreptul de a-l schimba.
Setarea TZ funcționează pentru unele runtime-uri și pentru altele nu. O aplicație Windows nativă care citește GetTimeZoneInformation nici nu o va observa.
Uneltele de dezvoltator din browser suprascriu fusul pentru o pagină web, ceea ce este excelent și irelevant pentru o aplicație desktop.

Un proces, un decalaj

Sesiunea poartă propriul decalaj. Aplicația întreabă Windows în ce fus se află și primește acel răspuns, în timp ce fiecare alt program de pe mașină primește răspunsul real.

# Același moment, văzut de pe coasta de vest a Americii
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# Doar fusul - data reală de azi, ceasul altcuiva
chrono run "C:\apps\test.exe" --zone +09:00

Calculatorul răspunde celeilalte jumătăți a întrebării - cum se citește de fapt un anumit moment în altă parte. Conversia păstrează momentul și schimbă doar ceasul de perete, exact așa ajunge o dată în ziua greșită:

$ 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

Ora nouă dimineața în Europa Centrală este miezul nopții pe coasta de vest a Americii. Același moment, iar un raport zilnic care grupează după data locală îl pune într-o zi diferită în funcție de locul unde rulează.

Limite oneste, și contează aici

Fusul sesiunii este un decalaj fix, fără ora de vară.

O sesiune setată la +01:00 rămâne la +01:00 indiferent dacă ceasul ei arată ianuarie sau iulie. O rulare care trece peste o tranziție reală se abate deci cu o oră de la ce ar arăta de fapt acel fus, iar trecerea unei aplicații printr-o tranziție la ora de vară nu este ceva ce face încă acest instrument. Calculatorul de date o spune, în loc să ghicească.

Fusul se raportează drept „Chrono Session”, un nume pe care niciun registru Windows nu îl cunoaște. Orice mapează acel nume înapoi la un fus - printre ele TimeZoneInfo.Local din .NET - revine în schimb la decalaj, ceea ce este răspunsul corect. O aplicație care insistă pe un nume din registru nu va găsi unul.
Java preia fusul sesiunii ca decalaj. Fusul sesiunii nu are ora de vară și nici un oraș în spate, așa că Java îl numește după decalajul lui - GMT+05:30 pentru o sesiune la +05:30.
În modul Chromium și Electron, paginile citesc și ele fusul orar al sesiunii. Este aceeași decalare fixă: fiecare pagină și fiecare worker este mutat pe ea și verifică ce citește. Procesul principal al unei aplicații Electron rulează JavaScript în Node, la care sesiunea nu ajunge, deci păstrează ceasul real.
Decalajele merg de la -14:00 la +14:00, în minute întregi. Orice în afara acestui interval este refuzat, nu rotit pe tăcute.

Care dintre ele se aplică aplicației tale se poate măsura, nu ghici. Sesiunea își raportează propria acoperire →

Încearcă-l

Descarcă pentru Windows Citește FAQ-ul