開発者ツール · Unix タイムスタンプ コンバータ
すべてのエポックが 1970 であるわけではありません: NTP、Windows FILETIME、GPS、および Excel の日付
· 背景
タイムスタンプ データ形式 デバッグ
Unix の 1970 の起源は、数多くあるものの 1 つにすぎません。この投稿では、ファイルとプロトコル (1900、1601、1904、1980、2001) で遭遇するエポックを調査し、決して Unix 時間ではない値を認識する方法を示します。
1900 に到達したタイムスタンプ — どの単位を選択しても意味をなさない、ネットワーク キャプチャからの値
単位だけが非表示パラメータではないため、パケット キャプチャからの数値は、秒とミリ秒の両方で無意味になる可能性があります。エポックとは、選択されたゼロ点を意味します。 Unix は 1970 を使用しますが、別のプロトコルは別の場所からカウントされる場合があります。再スケーリングでは間違った原点を修復できません。
ToolAcre の両方の読み取り値が既知のイベント時間と競合する場合、切り替えを停止します。フィールド名、プロデューサー、プロトコルのバージョン、文書化された発行元を特定します。妥当な年が表示されるまで繰り返し数字をトリミングすると、調査が偶然に変わります。
妥当な日付が表示されるが、周囲のイベントと矛盾する場合にも、同じ診断が適用されます。もっともらしさは弱いチェックです。来歴と既知の参照イベントの方が強力です。
NTP および 1900 — 32 ビット端数を含む 1900-01-01 からの秒数、およびそれによってもたらされる 2036 ロールオーバー
ワークブックには、NTP の起点、分数レイアウト、ロールオーバー日付が指定されています。 Unix コンバータでは何も実装またはテストされていないため、この記事ではそれらの詳細を保証しません。ネットワーク キャプチャは、送信者とパーサーが使用するプロトコルのドキュメントに従ってデコードする必要があります。
Unix 秒を導出した後でのみ、値がこのツールに入力されます。 1 つの固定幅フィールドだけでは識別できない可能性があるため、元号またはロールオーバー コンテキストを保持します。想定された時代から得られた洗練された UTC 結果は、内部的には一貫していても、外部的には間違っている可能性があります。
プロトコル フィールドは、全体コンポーネントと部分コンポーネントを分割することもできます。指定されたスケールを使用せずにそれらを連結または 10 進数化すると、準拠したデコーダーが意図しなかった新しい数値が作成されます。
NTP 変換の詳細とロールオーバー動作には、ここに記載されていないソース ドキュメントが必要です
同様に、名前付きの Windows カウンターと .NET カウンターは受け入れられるモードではありません。リポジトリには、原点または目盛りスケールの定数が含まれていません。大きな 10 進数値は、開発者が変換を試みる前に JavaScript の正確な整数の範囲を超える可能性があります。
プラットフォームの文書化された定義に基づいた整数セーフ ライブラリを使用し、オリジナルをテキストまたはワイド整数として保存してから、Unix 値を出力します。浮動小数点で記憶されているオフセットを減算しないでください。ソースの解像度がミリ秒よりも細かい場合、ローエンドでの正確さが重要になります。
ラウンドトリップ テストには、ゼロ以外の 1 秒未満の数字を含む値を含める必要があります。全秒フィクスチャは、100 ナノ秒またはミリ秒の残りが正しく保存されたかどうかを公開できません。
FILETIME および .NET 定義は ToolAcre によって実装されず、メモリからアサートされません
スプレッドシートの日付には、ワークブックの日付システム設定によって解釈される数値シリアルという別の表現が導入されています。ワークブックの 1900 の癖と古い Mac の主張にはスプレッドシート ソースが必要ですが、ここでは確立されていません。 ToolAcre はワークブックのメタデータを読み取りません。
スプレッドシート対応ツールを使用してファイルを検査し、構成された日付システムを決定し、そのライブラリを使用して日の小数点以下の精度を保持します。シリアルを Unix 秒として扱うと、通常のスケール バグのように見える早期 1970 の日付が生成される可能性がありますが、実際の問題は発生元と単位の両方にあります。
ワークブックの設定はファイルと一緒に移動できるため、見た目が似ている 2 つのシリアルが異なる起源を使用する場合があります。変換は、メタデータが利用可能なドキュメント境界に属します。
スプレッドシートのシリアル システムと癖にはスプレッドシート固有の証拠が必要です
アウトラインで指定されている GPS および Apple 関連のエポックも実装の対象外です。それらの関係には、一定の原点シフトを超えたスケール規則が含まれる場合があります。信頼できる証拠がない限り、現在のオフセットや換算式はここでは公開されていません。
一般的な診断は引き続き転送します: ゼロ、ティック期間、およびプロデューサーからのリープ規則を識別します。次に、適切なライブラリを使用して変換し、同じデータ セットからの既知のタイムスタンプと照合して検証します。 3 つの独立した事実は、小数点幅の推測よりも安全です。
この注意は、leap 規則に関して特に重要です。 1 つのスケールと日付に対して機能する定数は、システムのすべてのペア間で時代を超越した関係であるとは限りません。
GPS と Apple エポックの関係には、このモジュール外の信頼できるソースが必要です
防御可能な有効なメソッドは、既知の瞬間から始まります。たとえば、ToolAcre で検証された `2025-02-03T10:23:00.000Z` (Unix の 1,738,578,180 秒に相当) です。文書化された別のエポックについては、そのシステムの公式の原点と整数演算によるスケールを使用してその値を計算し、同じ定義を使用して変換し直します。
Unix ISO 文字列との往復を比較し、派生を保持します。この記事では、意図的に、読み取られなかった定数を 5 エポック テーブルに埋め込むことはしません。この方法はあらゆる仮定を明らかにし、実際にデータを生成したプロトコルまたはファイル形式に照らしてレビューすることができます。
有効な方法: 未検証の定数を公開するのではなく、文書化されたエポック全体で 1 つのインスタントを導出する
ToolAcre は、外部エポックを自動的に認識または変換しません。その単位メニューには、構成内の Unix 定義に基づいて、秒とミリ秒が表示されます。自動検出は、10¹¹ の大きさのスケールの中からのみ選択します。ゼロ点を変更することはありません。
この狭い契約により、誤った信頼が防止されます。外部カウントがたまたまもっともらしい Unix 日付に一致した場合、コンバータは発信元が間違っていることを警告できません。来歴は算術の前に入力する必要があります。手動の Runbook に頼るのではなく、コードで変換を文書化します。
表示される自動ラベルは、秒またはミリ秒のみを報告します。ソースにはそのような分岐が存在しないため、原点検出が行われた証拠として引用されるべきではありません。
要点: どのゼロからカウントしているのか、そして Unix タイムスタンプ コンバーターが Unix の秒またはミリ秒を読み取っていることをどのようにして明確に伝えるのかを知ってください。
どのゼロからカウントしているのか、1 ティックの大きさ、ソースがそのタイム スケールをどのように処理しているのかを把握します。 Unix コンバータは、これらの質問が 1970 UTC から秒またはミリ秒に解決された後にのみ回答します。 1 つの整数からセマンティクスを推測することはできません。
信じられない二重の読み取り値は、約数を試行し続ける許可としてではなく、起源を調査する信号として使用します。ソース変換によって Unix 値が生成されると、ToolAcre は、独自の仮定を可視化したまま、便利な独立した UTC およびローカルの健全性チェックを提供します。
優れたアダプターは、外部型に名前を付け、ソース変換を 1 つ実行し、ブランド化された Unix 値を出力します。この設計により、生のカウンターが汎用日付コンストラクターに漏洩するのを防ぎます。