開発 · 5分で読めます ·
Unix タイムスタンプは秒？ミリ秒？
毎週どこかで本番に出てしまう「13 桁」のバグと、2 つの単位を見分けるとてもシンプルなルール。
JavaScript はミリ秒、多くのバックエンドは秒で時刻を扱います。取り違えると、日付は 1970 年 1 月か、数万年先の未来に飛んでしまいます。
桁数を数える
現在のタイムスタンプは秒なら 10 桁です（1790000000 は 2026 年 9 月 21 日）。同じ瞬間はミリ秒で 13 桁、マイクロ秒で 16 桁、ナノ秒で 19 桁になります。
見分けるルール
絶対値が 10¹² より大きければミリ秒、そうでなければ秒とみなします。2001 年 9 月以降のミリ秒のタイムスタンプと、33658 年より前の秒のタイムスタンプなら、このルールで判別できます。
const ms = Math.abs(n) > 1e12 ? n : n * 1000;タイムスタンプにタイムゾーンはない
Unixタイムスタンプは1970年1月1日00:00 UTCからの秒数です。同じ数値は世界中どこでも同じ瞬間を表し、変わるのは表示の仕方だけです。バグが起きるのは、ローカル時刻をUTCであるかのようにタイムスタンプへ変換したときです。すべての日時がタイムゾーンの差だけずれ、夏時間の切り替えでさらにずれます。タイムスタンプはUTCで保存・送信し、人に見せるときだけローカル時刻に変換しましょう。
主な言語で現在時刻を取得する
JavaScript Date.now() ミリ秒
JavaScript Math.floor(Date.now() / 1000) 秒
Python time.time() 秒（小数あり）
Java System.currentTimeMillis() ミリ秒
Go time.Now().Unix() 秒
PostgreSQL EXTRACT(EPOCH FROM now()) 秒
MySQL UNIX_TIMESTAMP() 秒1970年より前の日付と2038年問題
負のタイムスタンプも有効で、−86400は1969年12月31日です。古いシステムや表計算ソフトの中にはこれを扱えないものがあり、生年月日や過去のデータはバグのよくある原因です。反対側では、符号付き32ビット整数は2147483647、つまり2038年1月19日03:14:07 UTCで上限に達します。タイムスタンプをまだ32ビットで保存しているシステムは1901年に戻ってしまいます。64ビットで保存すれば、この問題は数十億年先まで起きません。
うるう秒
Unix時間はうるう秒を無視し、1日は常にちょうど86,400秒です。計算が単純になり、ほとんどのアプリケーションでは差は問題になりません。うるう秒をまたぐ正確な間隔が必要な、一部の科学や金融のシステムだけが気にする必要があります。
デバッグ用のクイックチェックリスト
- 日付が1970年1月になる：秒の値をミリ秒として読んでいる。
- 年が5桁になる：ミリ秒の値を秒として読んでいる。
- すべての日時が同じ時間数だけずれる：ローカル時刻をUTCとして扱った、またはその逆。
- 1年のうち一部の期間だけ1時間ずれる：夏時間の切り替えを無視している。
- 日付が1901年に飛ぶ：32ビットのオーバーフロー。
単位は明示的に選ぶ
4Dev のタイムスタンプ変換ツールは推測しません。"Unix Timestamp" は秒、"Unix Timestamp (ms)" はミリ秒を意味し、マイクロ秒やナノ秒の形式も並んでいます。ISO 8601、RFC 2822、SQL DATETIME、Excel のシリアル日付を含め、全部で 33 の形式に対応しています。
人が読む日付にはISO 8601
タイムスタンプは保存や計算には最適ですが、人には読みにくいものです。ログ、API、人が開くファイルでは、2026-09-21T14:30:00ZのようなISO 8601を使えば、あいまいさがなく、文字列として正しく並び、タイムゾーンも明示できます。両者を相互に変換するのが、まさにタイムスタンプ変換ツールの役目です。