タイムゾーンをまたぐログのタイムスタンプ読み方

インシデントのタイムラインは、システム、リージョン、ログ形式をまたぐことがよくあります。あるサービスは Unix 秒、別のサービスは ISO 8601 UTC、ダッシュボードはブラウザのローカル時刻を表示し、顧客は自分のタイムゾーンで問題を報告します。

コツはすべての形式を暗記することではありません。比較する前に正規化することです。

よくあるタイムスタンプの形

よく見かける形式は次のとおりです。

• Unix 秒、例: 1716657600
• Unix ミリ秒、例: 1716657600000
• ISO 8601 UTC、例: 2026-05-26T06:30:00Z
• オフセット付き ISO 文字列、例: 2026-05-26T14:30:00+08:00
• 明示的なオフセットのないローカルダッシュボードのラベル

危険なのは最後のケースです。タイムゾーンのない時刻は、どのシステムが表示したか分からないと解釈できません。

秒とミリ秒

Unix 秒は現在の日付付近で 10 桁です。Unix ミリ秒は 13 桁です。これらを混同すると、実際のイベントから数十年ずれた日付になります。

タイムスタンプが 1970 年付近や遠い未来に見える場合は、まず単位を確認してください。Timestamp Converter なら秒、ミリ秒、ローカル時刻、UTC を並べて確認できます。

タイムラインは UTC に正規化する

インシデントを再構成するときは、まずタイムラインを UTC で書きます。UTC はすべてのシステムに同じ基準点を与えます。

そのうえで、人間の読者の助けになる場合だけローカル時刻を追加します。

• 顧客が報告した時刻（顧客のタイムゾーン）
• サポートチケットの時刻（担当者のタイムゾーン）
• ダッシュボードの時刻（ブラウザのローカル時刻で表示されることが分かっている場合）

こうすれば、関係者が異なるリージョンにいても分析が安定します。

取り込み遅延に注意

ログのタイムスタンプは、意味が異なることがあります。

• イベントが発生した時刻
• サービスがログ行を書き込んだ時刻
• コレクターが受信した時刻
• インデックスが検索可能になった時刻

2 つのシステムが順序が逆に見える場合、一方がイベント時刻で、もう一方が取り込み時刻ではないか確認してください。

シンプルな比較ワークフロー

疑わしいログ行ごとに次を行います。

1. タイムスタンプをコピーする
2. UTC とローカル時刻に変換する
3. 元のタイムゾーンまたは単位をメモする
4. 正規化した UTC 値を比較する
5. そのうえでどちらのイベントが先か判断する

タイムバグは扱いにくく感じるのは、システムごとに少しずつ異なる物語を語っているからです。タイムスタンプを正規化すれば、物語はずっと読みやすくなります。