Bir uygulamayı başka bir saat diliminde çalıştırın

Yanlış güne düşen rapor, bir saat erken çalan hatırlatma, yarın gibi okunan zaman damgası - çoğu yalnızca oturmadığınız bir saat diliminde ortaya çıkar. Bu, tek bir sürece kendi kaymasını verir; sistem diliminiz ise tam olarak olduğu yerde kalır.

Olağan cevaplar neden işe yaramaz

Windows saat dilimini değiştirmek onu her şey için değiştirir - takviminiz, günlükleriniz, toplantılarınız - ve yönetilen bir makinede değiştirmek size ait olmayabilir.
TZ ayarlamak bazı çalışma zamanları için işe yarar, bazıları için yaramaz. GetTimeZoneInformation okuyan yerel bir Windows uygulaması bunu hiç fark etmez.
Tarayıcı geliştirici araçları bir web sayfası için dilimi geçersiz kılar; bu mükemmeldir ve bir masaüstü uygulaması için ilgisizdir.

Bir süreç, bir kayma

Oturum kendi kaymasını taşır. Uygulama Windows’a hangi dilimde olduğunu sorar ve o cevabı alır; makinedeki diğer her program ise gerçeğini alır.

# Aynı an, Amerika batı kıyısından görüldüğü gibi
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# Yalnızca dilim - bugünün gerçek tarihi, başkasının saati
chrono run "C:\apps\test.exe" --zone +09:00

Hesap makinesi sorunun diğer yarısını yanıtlar - belirli bir anın başka bir yerde gerçekte nasıl okunduğunu. Dönüştürme anı korur ve yalnızca duvar saatini değiştirir; bir tarihin yanlış güne düşmesinin yolu tam olarak budur:

$ 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

Orta Avrupa’da sabah dokuz, Amerika batı kıyısında gece yarısıdır. Aynı an ve yerel tarihe göre gruplayan günlük bir rapor, nerede çalıştığına bağlı olarak onu farklı bir güne koyar.

Dürüst sınırlar ve burada önem taşırlar

Oturum dilimi, yaz saati uygulaması olmayan sabit bir kaymadır.

+01:00’a ayarlanmış bir oturum, saati Ocak’ı da gösterse Temmuz’u da gösterse +01:00’da kalır. Gerçek bir geçişi aşan bir çalıştırma bu yüzden o dilimin gerçekte göstereceği saatten bir saat sapar ve bir uygulamayı yaz saati geçişinden geçirmeye zorlamak bu aracın henüz yaptığı bir şey değildir. Tarih hesaplayıcı tahmin etmek yerine bunu söyler.

Dilim kendini “Chrono Session” olarak bildirir, hiçbir Windows kayıt defterinin bilmediği bir ad. Bu adı bir dilime geri eşleyen her şey - .NET’in TimeZoneInfo.Local’ı dahil - bunun yerine kaymaya döner; bu doğru cevaptır. Bir kayıt defteri adında ısrar eden bir uygulama onu bulamaz.
Java oturum dilimini bir kayma olarak alır. Oturum diliminin yaz saati uygulaması ve arkasında bir şehir yoktur; bu yüzden Java ona kaymasından bir ad verir - +05:30’daki bir oturum için GMT+05:30.
Chromium ve Electron kipinde sayfalar da oturum dilimini okur. Aynı sabit farktır: her sayfa ve worker ona alınır ve okuduğunu denetler. Bir Electron uygulamasının ana süreci JavaScript'i oturumun erişemediği Node içinde çalıştırır, bu yüzden gerçek saati korur.
Kaymalar -14:00 ile +14:00 arasındadır, tam dakikalar halinde. Bunun dışındaki her şey sessizce sarılmak yerine reddedilir.

Bunlardan hangisinin uygulamanız için geçerli olduğu tahmin edilemez, ölçülebilir. Oturum kendi kapsamasını bildirir →

Deneyin

Windows için indir SSS’yi okuyun