Uruchom aplikację w innej strefie czasowej

Raport, który ląduje w złym dniu, przypomnienie odpalające godzinę za wcześnie, znacznik czasu czytany jako jutro - większość tego widać dopiero w strefie, w której nie siedzisz. To daje jednemu procesowi własny offset, podczas gdy strefa twojego systemu zostaje dokładnie tam, gdzie była.

Dlaczego typowe odpowiedzi nie pomagają

Zmiana strefy w Windows zmienia ją dla wszystkiego - kalendarza, logów, spotkań - a na zarządzanej maszynie może w ogóle nie być twoja do zmieniania.
Ustawienie TZ działa w niektórych środowiskach uruchomieniowych, w innych nie. Natywna aplikacja Windows czytająca GetTimeZoneInformation w ogóle tego nie zauważy.
Narzędzia deweloperskie przeglądarki nadpisują strefę dla strony internetowej, co jest świetne i nieistotne dla aplikacji desktopowej.

Jeden proces, jeden offset

Sesja niesie własny offset. Aplikacja pyta Windows, w jakiej jest strefie, i dostaje tę odpowiedź, a każdy inny program na komputerze dostaje prawdziwą.

# Ta sama chwila, widziana z zachodniego wybrzeża USA
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# Sama strefa - dzisiejsza prawdziwa data, cudzy zegar
chrono run "C:\apps\test.exe" --zone +09:00

Kalkulator odpowiada na drugą połowę pytania - jak dany moment naprawdę czyta się gdzie indziej. Konwersja zachowuje chwilę i zmienia tylko czas ścienny, czyli dokładnie tak, jak data ląduje w złym dniu:

$ 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

Dziewiąta rano w Europie Środkowej to północ na zachodnim wybrzeżu USA. Ta sama chwila - a dzienny raport grupujący po dacie lokalnej wrzuci ją do innego dnia w zależności od tego, gdzie się wykonuje.

Uczciwe ograniczenia - tu ważą najwięcej

Strefa sesji to stały offset bez czasu letniego.

Sesja ustawiona na +01:00 zostaje przy +01:00 niezależnie od tego, czy jej zegar pokazuje styczeń, czy lipiec. Przebieg przecinający prawdziwą zmianę czasu rozjedzie się więc o godzinę z tym, co ta strefa naprawdę by pokazała, a przeprowadzenie aplikacji przez zmianę czasu nie jest czymś, co to narzędzie na razie robi. Kalkulator dat mówi o tym wprost, zamiast zgadywać.

Strefa przedstawia się jako „Chrono Session", czyli nazwą, której nie zna żaden rejestr Windows. Cokolwiek mapuje tę nazwę z powrotem na strefę - w tym TimeZoneInfo.Local w .NET - spada na offset, co jest właściwą odpowiedzią. Aplikacja upierająca się przy nazwie z rejestru jej nie znajdzie.
Java nie podchwytuje strefy sesji. Zegar ścienny i czas trwania są objęte, strefa nie. To znana dziura, powiedziana wprost, a nie ukryta.
W trybie Chromium i Electron strefa idzie za hostem. Fałszowana jest chwila, a nie funkcje czasu lokalnego.
Offsety mieszczą się od -14:00 do +14:00, w pełnych minutach. Cokolwiek poza tym jest odrzucane, a nie po cichu zawijane.

To, które z nich dotyczy twojej aplikacji, da się zmierzyć, a nie tylko zgadnąć. Sesja raportuje własne pokrycie →

Wypróbuj

Pobierz na Windows Przeczytaj FAQ