開発者ツール · Unix タイムスタンプ コンバータ
タイムゾーンはオフセットではありません: IANA tz データベースとそれが重要な理由
· 背景
タイムスタンプ タイムゾーン ブラウザ API
オフセットは数値です。タイムゾーンは数値の履歴と、数値が変更されるときのルールです。この投稿では、その違いを説明し、それをエンコードする IANA tz データベースを紹介し、コンバーターがローカル読み取りにこのデータベースに依存する理由を示します。
1 時間移動した会議 - +02:00 の保存されたオフセット。これは 7 月には正しく、12 月には間違っていました
7 月の会議の横に保存された固定の `+02:00` は、その瞬間の忠実な読み取り値である可能性がありますが、12 月のルールとしては依然として失敗します。オフセットは 1 つの結果です。ゾーンは、異なる日付で結果を生成できるルール コンテキストです。一方をもう一方であるかのように保存すると、スナップショットがフリーズします。
ToolAcre のローカル行は、Intl に各日付のフォーマットを要求し、短い数値オフセットを要求します。エポックに構成定数は追加されません。この設計により、環境に適用されるルールがすべての瞬間に個別に影響を与えることができます。
オフセットとゾーン — UTC からの固定距離と DST ルールおよび変更履歴を備えた名前付き地域
オフセットは、レンダリングされたクロックがある瞬間に UTC からどのくらい離れているかを示します。名前付き領域には、一連のオフセット ルールと履歴変更を含めることができます。時代自体にはどちらも含まれていません。アプリケーションがイベントと場所ベースのスケジュールの両方を必要とする場合、これらの概念は別のフィールドを占有する必要があります。
不変イベントの場合は、インスタントを保存するだけで十分な場合があります。 「このリージョンで毎日 09:00 にオープン」の場合は、今後のインスタンスを実時間から解決する必要があるため、名前付きゾーンを保持します。昨日のオフセットを再利用すると、動的ルールが永続的な数値プロパティとして扱われます。
IANA tz データベース — 地域/City の名前、それが政治的決定の記録である理由、および更新頻度
このワークブックには、IANA データベース、政治的起源、更新頻度が指定されています。この実装では、`resolvedOptions()` から IANA スタイルのゾーン名が報告されますが、データベースのバージョン、更新スケジュール、またはソース パッケージは公開されません。それらの詳細はここでは主張しません。
この制限は再現に影響します。古い日付の出力がマシン間で異なる場合は、ゾーン文字列とプラットフォームのバージョンを記録します。時計だけからどちらのルール セットが新しいかは主張しないでください。名前付きゾーンによって問題は改善されますが、コンバーターはタイムゾーン データ インスペクターではありません。
再現可能な履歴出力を必要とするアプリケーションは、ゾーン データの依存関係を制御し、代表的な日付をテストする必要があります。不特定のブラウザ環境に依存すると、その再現性が損なわれます。
名前付きゾーン ルールの来歴と更新頻度は、この実装では公開されません
ToolAcre はブラウザーにローカル ゾーンを要求し、国際経由でフォーマットします。リポジトリは、ルールがオペレーティング システム、ブラウザ バンドル、または別のランタイム コンポーネントからのものであるかどうかを確立しません。内部アーキテクチャを公開するのではなく、障害を検出して安全にフォールバックします。
したがって、「ローカル」とは、変換時にブラウザによって選択された環境を意味します。デバイス設定を変更すると、エポックを変更せずに出力を変更できます。監査証跡の場合は、UTC と raw カウントを保存します。正規のストレージではなくローカル表示をコンテキストとして使用します。
フォーマッタ障害時の ISO へのフォールバックはインスタントを保持しますが、要求されたローカル プレゼンテーションは失われます。消費者は、これを変更された日付ではなく、縮小された表示コンテキストとして扱う必要があります。
ブラウザはローカル ゾーンを選択してフォーマットします。そのルールのソースは明示されていません
`2025-01-15T12:00:00Z` と `2025-07-15T12:00:00Z` など、6 か月離れた 2 つの UTC インスタントを選択し、それらを秒に変換し、1 つのデバイス上のローカル行を検査します。数値オフセットが異なるかどうかを記録します。観察は、表示されているゾーンと環境に対して有効です。
ワークブックでは Europe/Berlin オフセットが規定されていましたが、それらの名前付きゾーン ルールは実装から読み取られませんでした。この再現可能な演習では、サポートされていないテーブルを回避しながら、同じ区別 (1 つのゾーン クエリ、2 つのインスタント、および潜在的に 2 つのオフセット結果) を教えます。
オフセットが一致する場合でも、観測結果は有益です。つまり、その構成されたゾーンは、その環境で選択された瞬間に季節差を露呈しませんでした。
有効な例: ベルリンのルールをハードコーディングする代わりに、2 つの日付で 1 つのブラウザー ゾーンを観察します。
パネルは `timeZoneName: "shortOffset"` を要求します。これは、地域の略語よりも GMT+1 などの数値関係を優先します。この選択により、コンテキストによって意味が異なる可能性があるラベルへの依存が軽減されますが、正確な Intl 形式はプラットフォーム出力のままです。
保存されたデータの場合、表示略語ではなく、アプリケーションが選択したライブラリによって定義された正規のゾーン識別子を使用します。ユーザー向けの短いラベルは役立つ場合がありますが、将来のスケジュールを再構成する鍵になるべきではありません。
数値オフセットは、ある時点では算術として明確なままです。その制限は、ルール ID が欠落していることであり、その 1 つのクロック読み取り値を UTC にマッピングできないことではありません。
保存されたデータでは略語は避けられます。フォーマッタは短い数値オフセットを要求します
今後の定期的なスケジューリングには、このコンバーターでは提供されないギャップ、オーバーラップ、およびポリシー処理が必要です。解決された日付またはエポックから始まり、それをレンダリングします。繰り返される 2 つのローカル時刻のどちらかを選択したり、存在しないローカル時刻を修復したりすることはありません。
動作が要件に合わせてテストされているゾーン対応スケジューリング ライブラリを使用し、役立つ場合はここで解決されたオカレンスを検査します。解像度をディスプレイから分離することで、単純なコンバータが未定義のエッジ ポリシーを備えた偶発的なスケジューラになることを防ぎます。
スケジューラの出力は、将来の再計算や説明のためにゾーンと元のウォールタイム インテントを保持しながら、実行用のエポックとして保存できます。
要点: 瞬間をエポックとして保存し、場所をゾーン名として保存します。また、Unix タイムスタンプ コンバーターがローカル読み取りのためにブラウザーのゾーンをどのように使用するかについても説明します。
インスタントを明示的なエポック単位または標準 UTC 文字列として保存し、場所自体が重要な場合は名前付きゾーンを保存します。説明のために出力にオフセットを付けることはできますが、どちらのフィールドの代わりにもなりません。 ToolAcre の UTC 行とローカル行は、その分離を示しています。
ローカルの結果に驚いた場合は、データを変更する前にゾーン ラベル、インスタント、オフセットを確認してください。固定オフセット パッチでは、ある日付が正しく見え、別の日付が間違っているように見える可能性があります。耐久性のあるモデルはイベントを安定に保ち、検証されたゾーン ルールがその文字盤を提供できるようにします。
このモデルは旅行もサポートしています。ユーザーは、イベントを書き換えたり、元のスケジュール コンテキストを失ったりすることなく、新しいローカル ゾーンに保存された 1 つのインスタントを表示できます。