開発者ツール · Unix タイムスタンプコンバータ
秒ですか、それともミリ秒ですか? 10 桁のエポックと 13 桁のエポックを区別する
· 仕組み
タイムスタンプ UNIX 時間 開発者のワークフロー
現在遭遇するほとんどのエポック値は 10 桁 (秒) または 13 桁 (ミリ秒) であり、推測を誤ると日付が数万年ずれてしまいます。この投稿では、桁数の背後にある算術と、コンバータが単位を推測するのではなく記述する必要がある理由について説明します。
1700000000 それとも 1700000000000? — 同じ瞬間が二通りに書かれており、遠い未来の日付が表示されたダッシュボード
ログ値 1700000000 とペイロード値 1700000000000 は、同じ瞬間を表すことができます。最初の時間をミリ秒として扱うと、ダッシュボードは 1970 年 1 月になります。秒を秒として扱うと、日付が数千年未来に飛びます。タイムスタンプは単なるカウントに単位と開始点を加えたものであるため、ドキュメントのない created_at という名前のデータベース列には重要な情報が省略されています。
現在の秒カウントが 10 桁である理由 — 2001 年の 10 億番目の秒、10 桁の範囲は 2286 まで、および 9 桁が何を意味するのか
Unix 時間は、通常の POSIX 規則に従って、1970-01-01 00:00:00 UTC からの経過秒数をカウントします。 2001 年にはカウンターが 10 億を超えました。現代の正の日付の場合、通常は 10 進数の 10 桁です。 2286 年に 100 億に達するまで 10 桁のままです。これは 10 進表記の特性であり、ISO 日付文字列に組み込まれたルールではありません。エポックより前の負の値や現在よりはるかに外側の日付は、単純な桁数のショートカットを無効にします。
ミリ秒のカウントが 13 である理由 (1,000 の因数、3 桁の追加)、および JavaScript と Java の規則の由来
JavaScript Date.getTime() は通常、秒のタイムスタンプに 1,000 を掛けてミリ秒をカウントします。 3 つのゼロにより、現在の 10 桁の秒カウントが 13 桁のミリ秒カウントになります。たとえば、1,700,000,000 秒は 1,700,000,000,000 ミリ秒になります。どちらも 2023-11-14T22:13:20.000Z です。想定される単位を示さずに単に区切り文字を挿入するコンバーターは、有効な数値をもっともらしいが間違った日付に変換してしまう可能性があります。
推測が間違っている場所 - 紀元に近い小さな値、2001 年より前の日付、桁数の区別ができなくなる将来の日付
ミリ秒の値が短い可能性がある 1970 年付近、秒の桁数が 10 桁未満の 2001 年以前、またはマイクロ秒およびナノ秒カウンターの場合、ヒューリスティックは失敗します。 ToolAcre は、デフォルトで 10¹¹ 未満の大きさを秒、それ以上の値をミリ秒として解釈し、使用される単位にラベルを付けます。このしきい値は実際的な推測であり、明確な形式デコーダではありません。特定の API によって提供されるタイムスタンプは、その長さが異常な場合でも、その API のドキュメントを使用して解釈する必要があります。
動作例: 1 つのログからの 3 つの値 — 1700000000、1700000000000、1700000000000000、秒、ミリ秒、マイクロ秒で読み取られます。
例示的なログからの 3 つの整数がトラップを示しています。 1700000000 を秒として解釈し、1700000000000 をミリ秒として解釈します。どちらも 2023-11-14T22:13:20Z に解決されます。 1700000000000000 をマイクロ秒として解釈し、100 万で割ると同じ秒数が得られます。 ToolAcre コンバーターは、マイクロ秒モードではなく、秒またはミリ秒を受け入れます。最初に単位を変換せずに 3 番目の数値を貼り付けると、意図した瞬間が確認されません。デバッグ中は、生のフィールドとそのユニットを常に一緒に保ってください。
単位を推測するのではなく記載する必要がある理由 — コンバーターが適用された単位をどのように表示するかによって、誤った仮定が沈黙するのではなく可視化される
タイムスタンプを送信するサービスは、スキーマ内でユニットに名前を付けるか、明示的なオフセットを持つ ISO 8601 テキストを使用する必要があります。従来のフィールドが文書化されていない場合は、決定する前に、いくつかの値を別の信頼できるイベント時間と比較してください。偶然にありそうな日付が 1 つだけあるだけでは証拠としては不十分です。コンバーターには適用された単位が表示されるため、1,000 分の 1 の間違いを見つけるチャンスが得られます。長期的な API 契約として自動推測に依存するのではなく、単位を明示的に変更して比較します。
これでカバーされないもの — 文字列、ISO 8601 テキスト、またはスプレッドシートのシリアル日付として保存されたタイムスタンプは、別の問題です
この記事では、Excel のシリアル日付、2026-09-28T10:15Z などの文字列、またはローカル時計読み取り値のタイムゾーン形式については説明しません。それらは異なる表現です。 Unix タイムスタンプは瞬間を指します。同じ瞬間が、異なるゾーンでは異なる実時間として表示されます。うるう秒の規則も別個に扱う必要があり、32 ビットの符号付きカウンターには、秒かミリ秒の問題とは異なるオーバーフローの問題が 2038 年に発生します。
要点: 桁を数えてから単位を確認します。また、Unix タイムスタンプ コンバーターが単位のラベルが付いた秒とミリ秒の両方を読み取る方法についても説明します。
最初のヒントとして桁を数え、次に生産者が指定した単位と少なくとも 1 つの既知のイベントを確認します。 Unix タイムスタンプ コンバータは、適用された秒/ミリ秒の仮定を表示し、UTC 表現とローカル表現の両方をブラウザに表示します。見た目がきれいな日付によって、値を生成したシステムからの反対の文書が上書きされないようにしてください。