開発者ツール · Unix タイムスタンプ コンバータ
ブラウザが Date と Intl を使用してエポックを現地時間に変換する方法
· 仕組み
タイムスタンプ JavaScript ブラウザ API
ブラウザ コンバータには、独自のサーバー クロックやタイム ゾーン データベースがありません。これは、Date オブジェクトと、オペレーティング システムによってサポートされる Intl API に依存します。この投稿では、そのパイプラインとその制限について説明します。
ブラウザはどこから「ローカル」を取得しますか? — 同じ部屋にあるラップトップと電話では、同じ時代が異なって表示されます
構成されたローカル ゾーンが異なる場合、隣り合う 2 つのデバイスは 1 つのエポックを異なる方法でレンダリングできます。この整数はラップトップと電話の間で変わりません。各ブラウザは同じインスタントを構築し、独自の環境にローカル カレンダー フィールドを提供します。したがって、「ローカル」とは、エポック内に保持されるプロパティではなく、読者を表します。
ToolAcre は、ローカル行に `Intl.DateTimeFormat().resolvedOptions().timeZone` というラベルを付けることで、その依存関係を可視化します。ある時刻を示すスクリーンショットと別の時刻を示すサーバー ログは、どちらも正確な測定値である可能性があります。まず UTC 行を比較します。 UTC 出力と一致すると、基になる瞬間ではなくプレゼンテーションが異なることがわかります。
日付にはミリ秒がかかります — コンストラクターのコントラクト、秒に 1,000 を乗算する必要がある理由、および日付が表現できる範囲
JavaScript `Date` はエポックからミリ秒を受け取ります。 ToolAcre の `fromEpoch` は、オブジェクトを構築する前に、秒入力に 1,000 を乗算し、ミリ秒入力を変更しないままにします。 1,717,243,200 を `new Date` に直接渡すと、6 月の 2024 ではなく、1970 の約 20 日後を意味するため、この変換は明示的です。
実装は、非有限数と、フォーマットする前に ±8.64×10¹⁵ ミリ秒を超える解釈値を拒否します。この制限は、データベースやオペレーティング システムのクロックではなく、ソースで指定された日付範囲に基づいて決まります。セレクターを変更すると、値が境界を越えて移動する可能性があるため、エラーによってどの単位が適用されたかがわかります。
UTC アクセサーとローカル アクセサー — getUTCHours と getHours、およびエンジンがオフセットを適用する方法
ToolAcre は、`getUTCHours` および `getHours` を持つフィールドを抽出しません。アウトラインのアクセサーの文言は実装よりも具体的です。 `Intl.DateTimeFormat` に対して、`timeZone: "UTC"` を使用して 1 回、ゾーン オーバーライドなしで 1 回、日付をフォーマットするように要求します。どちらの呼び出しも同じミリ秒値を受け取るため、どちらの呼び出しもイベント自体を移動することはできません。
この区別はデバッグ時に重要です。秒とミリ秒の行がプロデューサーと一致していても、ローカル ラベルに驚かれる場合は、エポックに時間を追加するのではなく、ブラウザー ゾーンを調べてください。手動のオフセット演算では、別のインスタントが作成され、フォーマッタにローカル ルールが再度適用されるため、古典的な二重調整エラーが発生します。
UTC およびローカル形式設定は、エンジンに 1 つの日付の 2 つの読み取りを要求します。
コンバーターは、ブラウザーに `resolvedOptions().timeZone` を要求していることを証明できます。特定のエンジンがオペレーティング システム、バンドルされたデータ、または別のプラットフォーム層からすべてのタイムゾーン ルールを取得したかどうかを証明することはできません。ソースは意図的にその機械をエンジンの責任として扱い、ゾーン クエリが失敗した場合は「現地時間」というフレーズに戻ります。
この証拠境界は役に立ちます。結果内の名前付きゾーンはブラウザーの現在の選択を識別しますが、タイムゾーン データベースのバージョン レポートではありません。 2 つの環境が古い日付で一致しない場合は、ブラウザ、オペレーティング システム、および表示されたゾーンを記録します。コンバーターは観測結果を提供します。 Intl の背後にあるデータ パッケージは診断されません。
ブラウザーはローカル ゾーンを報告しますが、そのルール ソースは実装の詳細のままです
ISO 行の場合、`toISOString()` は末尾に Z と 3 つの小数点を含む UTC 文字列を提供します。人間が判読できる UTC 行とローカル行では、数値の年、短縮月、2 桁の日、および 24 時間クロックを備えた英語 Great Britain フォーマッタが使用されます。フォーマッタは `shortOffset` も要求し、レンダリングされた各行の該当するオフセット部分を作成します。
これらの選択肢は、コンソールから `Date.toString()` をコピーすることが同等の証拠ではない理由を説明しています。その正確な散文はロケールに依存しており、このツールの出力規約の範囲外です。 ToolAcre は表示オプションを修正しますが、実際のローカル ゾーンの変更は許可します。別のシステムが安定した機械可読な比較を必要とする場合は、ISO 値をコピーします。
実用的な例: 1 エポック、3 つの出力 - UTC ISO 文字列、ローカルでフォーマットされた時刻、および getTimezoneOffset からの分単位のオフセット
1,717,243,200 と入力し、秒を選択します。乗算により 1,717,243,200,000 ミリ秒が生成され、テストでは `2024-06-01T12:00:00.000Z` として確立されます。 UTC 行は、そのインスタントを UTC でフォーマットします。ローカル行は、ブラウザー ゾーン内の同一の日付をフォーマットし、そのゾーンに名前を付けます。秒行とミリ秒行は両方の数値形式を保持します。
正確なローカル クロックとオフセットは、サンプルを実行しているデバイスから読み取る必要があります。ここで公開すると、すべての読者が同じゾーンを持っているように見えます。このため、この機能したチェックでは ISO アサーションを修正結果として使用し、ローカル出力を観測値として扱います。 ISO が異なる場合は、位置設定を調査する前に、選択したユニットを再確認してください。
作業例: 1 つのエポック、ToolAcre が実際に公開する 3 つの出力
このルートでは、任意の 3 番目のゾーンのセレクターは提供されません。 `formatInZone` は内部的にゾーンを受け入れることができますが、パネルはそれを UTC およびブラウザーのデフォルトに対してのみ呼び出します。ユーザーが東京、ナイロビ、またはトロントを選択できると主張する記事では、たとえ国際的に他の場所でそのような書式設定がサポートされていたとしても、同梱されていないインターフェイスについて説明していることになります。
また、カレンダーの選択、ロケールの選択、タイムゾーン データベースのリビジョンも公開されません。クロスオフィス変換の場合は、エポックをアンカーとして保持し、文書化されたインターフェイスにターゲット ゾーンの名前が付けられているツールを使用します。ここでは、より狭い約束が重要です。つまり、ローカル環境の横にユニバーサル UTC があり、ローカルの意味を決定する隠されたサーバーはありません。
要点: ブラウザーは時計であり地図帳です。また、Unix タイムスタンプ コンバーターがサーバーなしで UTC とローカルを並べて表示するためにそれをどのように使用するか
ブラウザは、演算エンジンとプレゼンテーション環境の両方として機能します。 ToolAcre は単位を解決し、1 つの日付を作成し、標準 ISO 値を要求してから、UTC とローカルの読み取り値を並べてフォーマットします。これらの手順ではリモート変換サービスは必要なく、表示されたユニットにより、1,000 の係数の決定がレビュー用に維持されます。
デバイス間で出力が異なる場合は、ISO 行、ユニットノート、名前付きローカルゾーンをこの順序で比較します。これら 3 つの観察は、インスタント、スケール、プレゼンテーションを分けます。ローカル時計を真実の情報源として扱うと、3 つの質問がすべて 1 つにまとめられ、視聴者がゾーンを変更するたびに正しい変換が間違っているように見えます。