アプリを別のタイムゾーンで実行する

誤った日に着地するレポート、1 時間早く鳴るリマインダー、明日として読まれるタイムスタンプ。こうした問題の多くは、自分がいないタイムゾーンでしか現れません。これは、1 つのプロセスに独自のオフセットを与え、システムのタイムゾーンはそのままにしておくものです。

よくある対処法が役に立たない理由

Windows のタイムゾーンを変更すると、すべてに影響します。カレンダー、ログ、会議のすべてです。管理されているマシンでは、そもそも自分に変更する権限がないこともあります。
TZ を設定する方法は、効くランタイムと効かないランタイムがあります。GetTimeZoneInformation を読むネイティブの Windows アプリは、まったく気づきません。
ブラウザーの開発者ツールは、Web ページのゾーンを上書きできます。それ自体は優れていますが、デスクトップアプリには無関係です。

1 つのプロセスに、1 つのオフセット

セッションは独自のオフセットを持ちます。アプリは Windows に自分のゾーンを尋ねるとその答えを受け取り、マシン上のほかのプログラムは本物の答えを受け取ります。

# 同じ時点を、アメリカ西海岸から見たところ
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# ゾーンだけ - 今日の本物の日付と、他人の時計
chrono run "C:\apps\test.exe" --zone +09:00

電卓は、問いのもう半分、つまり特定の時点がほかの場所では実際にどう読まれるかに答えます。変換は瞬間を保ち、壁時計だけを変えます。日付が誤った日に着地するのは、まさにこのためです。

$ 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

中央ヨーロッパの午前 9 時は、アメリカ西海岸では午前 0 時です。同じ瞬間でも、ローカルの日付でグループ化する日次レポートは、動作している場所によって別の日に振り分けます。

正直な制約。ここでは重要です

セッションのタイムゾーンは、夏時間のない固定オフセットです。

+01:00 に設定したセッションは、時計が 1 月を指していても 7 月を指していても +01:00 のままです。そのため、実際の切り替えをまたぐ実行は、そのゾーンが本来示すはずの時刻から 1 時間ずれ、アプリを夏時間の切り替えに通すことは、このツールではまだできません。日付電卓は、推測するのではなくそのことを明記します。

ゾーンは自身を「Chrono Session」と名乗ります。どの Windows のレジストリにもない名前です。その名前をゾーンに対応づけ直すもの、たとえば .NET の TimeZoneInfo.Local などは、代わりにオフセットにフォールバックし、それが正しい答えです。レジストリ上の名前にこだわるアプリは、それを見つけられません。
Java はセッションのゾーンをオフセットとして取り込みます。セッションのゾーンには夏時間も背後にある都市もないため、Java はオフセットにちなんだ名前を付けます。+05:30 のセッションなら GMT+05:30 です。
Chromium と Electron のモードでも、ページはセッションのタイムゾーンを読みます。同じ固定オフセットで、各ページとワーカーがそこに置かれ、自分が読む値を確認します。Electron アプリケーションのメインプロセスはセッションが届かない Node で JavaScript を実行するため、実際の時計のままです。
オフセットは -14:00 から +14:00 までの、分単位の整数です。それを超える値は、黙って丸められずに拒否されます。

そのどれがあなたのアプリに当てはまるかは、推測するものではなく、測定できるものです。セッションは自分のカバレッジを報告します →

試してみる

Windows 版をダウンロード FAQ を読む