タイムゾーン詳細 (DST) — IANA TZ の現在 offset と切替日を確認

タイムゾーン情報とシステム設定情報の機微性

タイムゾーン情報の確認が必要になる場面は、分散システムの設計・デプロイ・デバッグです。複数リージョンに展開するサービスで「どの TZ で何時に処理が走るか」を確認する際、その情報はインフラ構成・スケジュール設計・障害対応手順と密接に関係します。DST の切替による cron の誤動作を調査する場面では、サービスのスケジュール設定・バッチ処理の構成・データパイプラインの時刻依存部分が対象になります。

タイムゾーン名 (America/New_York, Asia/Tokyo など) 自体はオープンな IANA データですが、「このサービスはどの TZ を使っているか」「DST の切替でどのバッチが影響を受けるか」という組み合わせは内部のシステム設計情報です。タイムゾーン確認のために業務システムの設定情報を外部ツールに送ることは不要です。

「ブラウザの現在地」ボタンとデバイス情報の扱い

本ツールには「ブラウザの現在地」ボタンがあり、Intl.DateTimeFormat().resolvedOptions().timeZone でブラウザが報告するタイムゾーンを入力フィールドに自動入力します。この情報はデバイスの OS から取得されるもので、実際の物理的な位置情報 (GPS) とは異なりますが、その端末がどの地域の時間設定を使っているかを示します。

本ツールでは「ブラウザの現在地」で取得したタイムゾーン名を含め、すべての情報がブラウザのページ内でのみ処理されます。タイムゾーン名をサーバーに送信することも、Geolocation API で位置情報を取得することもありません。

Intl.DateTimeFormat だけで DST 検出から切替時刻まで完結する

このツールは ECMAScript 標準の Intl.DateTimeFormat API のみを使って DST の検出と切替時刻の特定を行います。1 年の各日について Intl.DateTimeFormat(tz).format(date) から UTC offset を計算し、前日と異なる日を切替候補として抽出します。その日内を 1 分間隔で二分探索して切替時刻を特定します。tzdata ファイルのバンドルも外部 API の呼び出しも必要ありません。

すべての計算がブラウザの JavaScript エンジン内で完結します。業務システムのタイムゾーン設定・DST 影響の調査・バッチスケジュールの確認を、内部の設定情報を外部に送ることなく行えます。

分散システムの DST トラブルシューティングと設計確認に

cron 系のスケジューラーで DST 切替の前後に誤動作が起きた場合、本ツールで対象タイムゾーンの切替時刻・方向 (前進 / 後退) を確認するのが出発点になります。「春の時刻ジャンプ」(2:00→3:00) では 2:30 に設定した cron が飛ばされ、「秋の時刻後退」(2:00→1:00) では 1:30 のジョブが 2 回実行されます。複数タイムゾーンをまたぐシステムの設計では、影響を受けるリージョンの切替タイミングを事前に把握することがトラブル防止につながります。

IANA tz database と Olson データベースのバージョニング

「America/New_York」「Asia/Tokyo」のような IANA タイムゾーン名は、IANA Time Zone Database (旧名 Olson データベース) で定義され、年に数回 (2024a、2024b、2025a のような版番号) で更新されます。各国の DST 政策変更・法改正・歴史的補正がこの更新で反映され、たとえば 2024 年にメキシコ・チワワ州が DST を恒久廃止、ヨルダンが恒久夏時間に移行、といった改定が tzdata2024a などに記録されています。ブラウザの Intl.DateTimeFormat はこのデータをブラウザビルド時に組み込んでおり、Chrome / Firefox / Safari でリリースサイクルが異なるためバージョンが揃わないことがあります。

本ツールの DST 検出は、Intl.DateTimeFormat(undefined, { timeZone, timeZoneName: 'short' }).formatToParts(date) で各日付の UTC オフセットを取得し、前日との差分を二分探索で 1 分粒度まで絞り込みます。ブラウザに組み込まれた tz データの版番号が古い場合、最近の政策変更を反映していない可能性があるため、本番システムでの正確性が要件であれば OS 側の /usr/share/zoneinfo (Linux) や tzdata パッケージのバージョンと突き合わせるのが安全です。Intl.supportedValuesOf('timeZone') で対応 TZ 名のリストも取得できます。

サーバー側 cron / Kubernetes CronJob の TZ 設定のばらつき

スケジューラーごとに TZ の扱いが大きく異なる点も実装上の落とし穴です。Linux の cron は伝統的に /etc/localtime 依存で、TZ=Asia/Tokyo 環境変数を crontab に書けばジョブ単位で TZ を切り替えられます (cron 実装による)。systemd timer は OnCalendar= に明示的に Asia/Tokyo 等を書けますが、デフォルトは UTC ではなくシステムタイムゾーンです。Kubernetes CronJob は 1.27 で spec.timeZone フィールドが GA となり、それ以前は UTC 固定でした。Quartz Scheduler (Java) は @CronSchedule に zone 属性を渡せますが、Spring Boot のデフォルトは JVM の user.timezone です。

DST 切替の影響を回避する設計の定番は「サービス全体の cron を UTC で書いて、DST のあるタイムゾーンに依存しない」というものです。AWS EventBridge、Cloudflare Workers Cron Triggers、GitHub Actions のスケジュールトリガはすべて UTC 固定で、これは意図的な選択です。本ツールで自社の業務 TZ (例: Asia/Tokyo) と AWS 側の UTC オフセットの差を確認しておくと、「朝 9 時に動くはずのバッチが UTC 0 時で書かれて DST 期間中だけ 1 時間ずれた」という典型的な事故を避けられます。Asia/Tokyo は DST がないため固定の +09:00 ですが、America/* 系・Europe/* 系を扱う場合は本ツールで毎年の春・秋の切替日を確認するのが運用上の保険になります。具体的な日時を別 TZ に翻訳したい場合は timezone-convert が、UTC 基準の epoch との往復は unix-timestamp が同じくブラウザ内で完結します。