Unixタイムスタンプの理解と変換のしかた
Epochがなぜ重要か、エンジニアを何度も噛む「秒かミリ秒か」落とし穴、どのタイムゾーンでも読みやすい日時への変換方法。
なぜ重要か
ログ調査で「1735689600」という値が出てきました。これは秒なら2025-01-01 00:00:00 UTC、ミリ秒を秒として誤読すると1970-01-21 02:08:09です。単位を取り違えるとポストモーティムの時系列が55年ずれます。Unixタイムは保存と計算には優れていますが人間には不向きであり、秒かミリ秒かは言語・DB・APIでバラバラです。信頼できるコンバータが単位の前提を明示してくれます。
実際の3つのシーン
1735689600を貼れば2025-01-01 00:00:00 UTCと2024-12-31 16:00:00 PSTが出ます。影響ユーザのタイムゾーンを選んで次へ。
インシデントの切り分けが速い
JSTで日時を入力し、スケジューラが秒かミリ秒かに合わせて結果epochをコピーします。
コードに正しいepoch
epoch一覧を貼り、並んでデコードUTC日付が表示されるので、そのままスプレッドシートへ。
読めるレポート
手順
Unixタイムコンバーターを開きます。
タイムスタンプを貼るか日時を選ぶ
10桁なら秒（おおよそ1973–2286）、13桁ならミリ秒で自動検出します。異常値ならドロップダウンで上書きしてください。
複数ゾーンでデコード結果を読む
UTC、ブラウザのローカル、任意のIANA（例：
Asia/Tokyo、America/Sao_Paulo）。逆方向にも変換
任意ゾーンの日時を入力すると、epochを秒とミリ秒の両方で出力します。
必要な形式でコピー
1735689600、1735689600000、ISO2025-01-01T00:00:00Z、RFC 2822—宛先が受け付けるものを選びます。
入力
1735689600 (seconds)デコード結果
UTC: 2025-01-01 00:00:00
ISO: 2025-01-01T00:00:00.000Z
Local: 2024-12-31 19:00:00 (UTC-5)入力
1735689600 (mistakenly read as milliseconds)ミリ秒として読んだ場合
UTC: 1970-01-21 02:08:09.600
実践テクノ
- API契約には必ず単位を書く。「Unixタイム」とだけ書くと曖昧。**「整数のUnixタイムスタンプ（ミリ秒）」**なら明確です。
- 1970年以前は負のタイムスタンプが有効です。コンバータはそれをグレゴリ歴で正しく表示します。
- 人向け表示はISO-8601。
2026-04-22T15:30:00Zは一意でソートにも強いです。 - 複数件は1行ずつ貼ってバッチ変換できます。
よくある落とし穴
よくある誤り
タイムゾーン変換後のサマータイム驚異
「10月の太平洋9時」と「11月の太平洋9時」は別物です。固定オフセット（UTC-8）ではなくIANAゾーン（America/Los_Angeles）で変換するとコンバータがDSTを処理します。
よくある誤り
JavaScript Date.getTime() と Python time.time()
JSはミリ秒、Pythonは（小数ありの）秒です。ポート時は明示的に1000倍または1/1000。コンバータは両形式を受け付けるので食い違いに気づけます。
よくある誤り
2038年問題
レガシーでUnix時刻を符号付き32bitに入れると2147483647（2038-01-19）以降オーバーします。そのような資産なら64bit時刻への移行を計画します。
向いていない用途
- 営業日計算（「今から5営業日後」など）は
date-fns-business-daysや会計の休日カレンダー向きです。 - cronのタイミングは次N回発火を出す評価ツールが適しています。
- RRULE等カレンダー連続イベントはiCalendarパーサ向きです。
FAQ
「epochゼロ」はどのゾーン？
0は1970-01-01 00:00:00 UTCです。UTCがUnix epoch定義で暗黙です。
なぜ年に2回流れる／飛ぶ時間がある？
**サマータイム（DST）**です。IANAデータベースが各地のルールを追跡し、コンバータが自動適用します。
入力はサーバーに送られますか？
いいえ。ブラウザのDateとIntl.DateTimeFormatのみで処理し、ページ外には出ません。
次のステップ
- チーム横断の会議枠はタイムゾーン比較で。
- よく使う都市は/time-tools/world-clockにピン。
- 該当地域の休日は今日の祝日ツール。