日時・スケジュール
ログの10桁・13桁の数字は何月何日？
使うツール
日時の不具合は、計算を始める前の『この数字は何の単位か』で起きることがあります。APIの値が秒なのにミリ秒として読んだり、UTCの表示を現地時刻と比較したりすると、正しい数字からおかしな日付が出ます。数字を足し引きして帳尻を合わせる前に、単位と表示方法を切り分けましょう。
Unix時間変換では、単位を明示して整数の時刻値を読み、UTCと選んだタイムゾーンの表示を比べられます。桁数から単位を自動確定する使い方ではありません。ここでは0から始め、既知の一日を使って秒とミリ秒の取り違えを再現します。
0は、東京でも0。表示される時計だけが違う
UTC: 1970-01-01T00:00:00Z
Asia/Tokyo: 1970-01-01T09:00:00+09:00この二つは同じ瞬間です。東京で表示するからUnix値へ9時間分を足す必要はありません。タイムゾーンを変える操作は、同じ瞬間を別の時計で読むための操作です。UTCから東京へ表示した後に、さらに9時間を加算すると、表示の変更と時刻そのものの変更を二重に行ってしまいます。
ログに2024-01-01 09:00としか書かれていない場合は、どのタイムゾーンかが欠けています。見た目の9時だけでは、UTCの9時か東京の9時かを決められません。時刻を共有するときはZや+09:00のようなオフセット、またはタイムゾーン名を一緒に残すと、同じ瞬間を再現しやすくなります。
1704067200は、秒とミリ秒で別の日になる
1704067200 seconds → 2024-01-01T00:00:00Z
1704067200 milliseconds → 1970-01-20T17:21:07.2Z秒で読むと2024年の元日、ミリ秒で読むと1970年の1月になります。秒をミリ秒へ変えるには1,000倍が必要で、同じ瞬間をミリ秒で表す値は1704067200000です。日付がおかしいときに桁を適当に増減するのではなく、生成元の仕様が秒かミリ秒かを確認してから単位を合わせます。
『10桁なら秒、13桁ならミリ秒』は、よく見る時代の値から得た目安にすぎません。1970年に近い時刻、負の値、遠い未来では桁数が変わります。時刻の列名がtimestampでも単位は確定しないため、APIの契約や保存形式へ単位を明記することが再発防止になります。
オフセット付き日時から、逆向きにも確かめる
2024-01-01T00:00:00Z
2024-01-01T09:00:00+09:00日時からUnix値へのモードで、それぞれを別々に変換します。単位が秒なら、どちらも1704067200です。表記が違っても同じUnix値へ戻れば、時刻そのもののずれではなく表示方法の違いと分かります。一方、オフセットなしの日時は実行環境の解釈に依存する可能性があるため、再現用の入力には使わないようにします。
小数秒を含む日時を扱う場合は、秒単位の整数部分と、選択単位に対応する結果の値を混同しないことも大切です。ミリ秒まで必要なログを整数秒だけへ落とすと、同じ秒の中で起きた出来事の順序が失われます。必要な精度を決めて、変換前後で桁を落としていないか確認します。
誕生日や締切日を、勝手にUnix時刻へしない
2024-01-01という日付だけの値には、時刻もタイムゾーンもありません。これをUnix値へ変えるには、どこの何時として扱うかという追加の約束が必要です。誕生日や営業日を、便利だからとUTCの0時へ変換すると、別の地域で表示したときに前日になることがあります。日付だけの情報は、その用途に合う日付として扱います。
『二つの日付が何日離れているか』なら日時差の暦日モード、『二つの瞬間の間に何秒たったか』なら経過時間モードを使います。同じ一日という言葉でも、カレンダー上の一日と24時間が常に同じとは限りません。タイムゾーンや夏時間が関わる計算では、先に問いを言葉にしてから入力形式を選びます。
変換が正しくても、元の時計が正しいとは限らない
二つのサーバーのログが数秒ずれている場合、単位とタイムゾーンをそろえても差が残ることがあります。このツールは時刻値の意味を変換するもので、サーバーの時計同期や通信遅延を測るものではありません。記録した時刻が処理開始か終了か、端末時刻か受信時刻かという違いも、別途確認が必要です。
変換できる値であっても、それが正しいイベントに対応する証拠にはなりません。コピー時に別の列を選んでいないか、タイムスタンプの生成仕様が変わっていないかを確認します。既知のイベントを一つ選び、値、単位、UTC表示、現地表示をそろえて比較すると、問題の層を絞りやすくなります。
時刻を渡すときは、数字と単位を一組にする
報告には1704067200だけでなく、『Unix秒、UTCでは2024-01-01T00:00:00Z』のように書きます。必要なら表示先のAsia/Tokyoも添えます。数字、単位、タイムゾーンのどれか一つが欠けると、受け取った側が推測して同じ不具合を再現してしまいます。変換結果をコピーするときも、ラベルを消して数字だけにしないようにします。
テストには0、既知の日時、秒とミリ秒の同一瞬間、オフセット付きの逆変換を残します。現在時刻だけを使う試験は、毎回結果が変わり比較しにくくなります。固定した入力を使えば、変換処理や表示設定を変更した後も、単位の取り違えと二重の時差補正を見つけやすくなります。
ログの時刻をそろえても、出来事の順番は別に確かめる
二つのサービスのログで、一方が2024-01-01T09:00:00+09:00、もう一方が2024-01-01T00:00:00Zなら、表示は違っても同じ瞬間です。まず双方をUnix秒へ変換して1704067200になることを確かめれば、時差を処理遅延と取り違えずに済みます。ただし、片方のログが秒までしか記録していない場合、同じ秒に起きた二つの出来事の前後はその情報だけでは分かりません。単位をミリ秒へ変更して末尾にゼロを足しても、失われた時刻の細かさは増えません。
さらに、異なる端末の時計がずれていれば、変換が正しくてもログの並びは実際の順序と逆になる場合があります。リクエストIDや処理の関連を示す情報と合わせて読む必要があり、時刻変換ツールだけで因果関係を確定しません。調査メモには、元の数値、秒かミリ秒か、表示したTimezone、ログの記録精度を残します。時刻の表示を統一した段階と、時計の同期や記録順を確認した段階を分けておけば、変換結果の正しさをシステム全体の時系列保証へ広げずに済みます。