開発者ツール · Unix タイムスタンプ コンバータ
マイクロ秒およびナノ秒エポック: 16 および 19 桁値の短縮
· 仕組み
タイムスタンプ unix-time 開発者ワークフロー
一部のランタイムはマイクロ秒またはナノ秒でエポックを発行し、秒またはミリ秒コンバーターでは直接読み取ることができない 16 桁または 19 桁の値を与えます。この投稿では、それらがどこから来たのか、そして安全に短くする方法について説明します。
トレース内の 19 桁の数値 — コンバーターに貼り付けられた time.UnixNano 出力と、意味のない結果
19 桁のトレース フィールドはナノ秒エポックになる可能性がありますが、それをこのコンバーターに直接貼り付けても、その仮説はテストされません。 ToolAcre は秒またはミリ秒を受け入れます。その範囲エラーは、サイズが大きすぎるデータベース数値がマイクロ秒またはナノ秒を使用している可能性があることを示唆しており、解釈する前に正規化するようユーザーに指示します。
調査中は元のテキストを保持してください。これを通常の JavaScript 数値に変換すると、除算が発生する前に下位の桁が変更される可能性があります。特に Unix エポックではないカウンタの場合、プロデューサのスキーマ、ロギング ステートメント、またはデータベースの列定義は、視覚的な長さよりも優れた証拠となります。
4 つの一般的な分解能 (秒、ミリ秒、マイクロ秒、ナノ秒) と現在の日付の桁数
秒は 1 秒ごとに 1 回進み、ミリ秒は 1,000 倍、マイクロ秒は 100 万倍、ナノ秒は 10 億倍速くなります。現在の日付では、これらは 10、13、16、19 桁の 10 進数で表示されることがよくあります。 「多くの場合」問題となるのは、マイナス記号、初期の日付、および遠い範囲は、数字のみのルールを破ることです。
パネルの自動しきい値は、10¹¹ の大きさで秒とミリ秒のみを区別します。 16 桁のマイクロ秒値はその境界を超えるため、ミリ秒として扱われ、通常は意図した日付を 1,000 倍超えます。サポートされていない解像度をルート名の 1 つに減らしてからユニットを選択してください。
4 つの解像度ラベルが一般的ですが、桁数だけがフォーマット契約ではありません
アウトラインではいくつかの言語 API とストレージ製品の名前が挙げられていますが、いずれもこのツールのソース ファイルではありません。どのプロデューサーがフィールドを発行したかを推測するのではなく、そのドキュメントを調べてください。 `_us` や `_ns` などの接尾辞、宣言された精度、または既知の隣接イベントは、10 進幅ではできないという証拠を提供します。
また、エポックと単調持続期間を区別します。高解像度カウンターは、プロセスの開始またはブートからの時間を測定する場合がありますが、1970 とは関係ありません。このような値を除算すると、カレンダーの日付ではなく、より小さなカウンターが生成されます。結果をエポックコンバータに渡す前に、単位と原点の両方を確認してください。
推定されるエミッターのリストではなく、プロデューサーから解像度を特定します
マイクロ秒をミリ秒に短縮するには、1,000 の係数を削除します。ナノ秒の間、1,000,000 を削除します。整数の除算はミリ秒未満の精度を意図的に確保します。正の値の場合、切り捨ては先頭のミリ秒カウントを取得します。否定的な場合は、文字列スライスのセマンティクスが同一であると仮定するのではなく、プロデューサーに一致する丸めルールを選択します。
精度が重要な場合は、10 進数のテキストまたは BigInt を使用して操作を実行します。浮動小数点除算は、すでに丸められた 19 桁の数値から開始できます。調査で 1 ミリ秒以内のイベント順序が必要な場合は、変換されたインスタントの横に破棄された残りの部分を保存します。 ToolAcre はこれらのミリ秒未満の区別を表示できません。
うまくいった例: 1700000000123456789 — ミリ秒までトリミングし、結果を読み取り、確保しておいたミリ秒未満の桁をメモします。
`1738577696123456789` をナノ秒として受け取ります。これを 10 進数のテキストとして扱い、整数演算で 1,000,000 で除算し、1,738,577,696,123 ミリ秒と 456,789 ナノ秒の余りを取得します。ミリ秒の商を明示的に入力します。 ISO 読み取り値は `2025-02-03T10:14:56.123Z` です。
残りはノイズではありません。2 つのトレース イベントは、表示されたミリ秒を共有できますが、それより下では異なります。順序付けのために生の値を保存し、削減された出力を人間の方向付けにのみ使用します。 1,738,577,696,124 に切り上げると、表示される瞬間が次のミリ秒に移動し、ソースが誤って表示されることになります。
文字列の除算は桁ごとに確認できます。削除された小数点以下 6 桁はナノ秒からミリ秒のスケールに正確に対応しますが、変更されていない接頭辞はカレンダーを含むカウントのままです。
実用的な例: 19 桁の値をミリ秒に削減しながらテキストとして保存します
JavaScript の正確な整数の保証は、一般的な 19 桁のエポック値を大幅に下回って終了します。 ToolAcre のパーサーは最終的に `Number` を呼び出すため、生のナノ秒テキストをパネルに入力しても、すべての桁を保持することはできません。サポートされている日付制限と単位セレクターは、Number をナノ秒の整数コンテナーに変換しません。
BigInt または文字列対応の前処理パスをリダクションに使用し、安全なサイズのミリ秒の結果を渡します。この順序は重要です。最初に解析して 2 番目に除算すると、保持したい数字が正確に破損する可能性があります。カレンダーのレンダリングが成功しても、下位のソース値が残っていることは証明されません。
これでカバーされないもの — 分解能とは関係のないクロック精度: ナノ秒のタイムスタンプでも秒単位で誤差が生じる可能性があります
解像度は、表現が値をどの程度細かく区別できるかを示します。時計が物理時間にどれだけ近かったかはわかりません。ナノ秒フィールドは不正確なソースから派生する可能性がありますが、秒フィールドは適切に同期することができます。コンバータはクロック品質の測定を行っておらず、そのような主張も行っていません。
同様に、余分な桁は測定された精度ではなく埋め込まれた精度になることがあります。インシデント分析では、同期証拠を使用してクロックを比較し、未加工の文書化されたカウンターを使用してイベント順序を比較します。カレンダー変換は読みやすさのみを提供します。長い 10 進数の末尾や ISO に示されている 3 ミリ秒から精度を推測しないでください。
要点: まずミリ秒に減らしてから変換します。また、Unix タイムスタンプ コンバーターが指定された単位で短縮された値を読み取る方法についても説明します。
変換前にサポートされていない解像度を減らし、元の解像度を保持し、破棄された残りを示します。 ToolAcre は、その契約で約束したことを実行できます。つまり、結果として得られる秒またはミリ秒を読み取り、選択した単位を表示した状態で UTC、ローカル、および ISO フォームを表示します。
正規化された日付が依然として意味をなさない場合は、数字を繰り返し削除するのではなく、原点に戻ってください。ブート以降のカウンター、別のエポック、または文書化されていないエンコーディングはすべて、あらゆるスケールで間違ったままになる可能性があります。単位、原点、整数の精度は別の問題です。人間が判読できる日付を信頼する前に、3 つすべてに答えてください。
自動検出はデフォルトにすぎないため、明示的な単位セレクターは削減後に重要になります。ミリ秒を選択すると、マグニチュード ヒューリスティックに再検出を求める代わりに、前処理の決定が記録されます。