Unix タイムスタンプとは？

この数値の定義

POSIX は「エポックからの秒数」を決まった式で定義しています。1日を常にちょうど 86,400 秒とし、1970-01-01T00:00:00Z から数え始めます。エポックより前の時点は負の値になるので、-1 は 1969-12-31T23:59:59Z です。

値は UTC で測るため、タイムゾーンも夏時間も持ちません。壁時計の時刻に変換するのは別の手順で、Asia/Tokyo や America/New_York などのタイムゾーンが必要です。

秒・ミリ秒・その他の単位

本来の Unix タイムスタンプは秒単位ですが、より細かい単位で保存するシステムも多くあります。現在の日付なら、桁数で見分けるのがいちばん手っ取り早い方法です。

単位の取り違えは、タイムスタンプで最もよくあるバグです。秒の値を JavaScript の new Date() に渡すと1970年1月になり、ミリ秒の値を秒として読むと数万年先の未来になります。JavaScript では、秒を得るには Math.floor(Date.now() / 1000)、元に戻すには new Date(seconds * 1000) で変換します。

うるう秒は数えない

UTC は地球の自転とずれないよう、ときどきうるう秒を挿入します。1972年以降、27 回追加されました。Unix 時間はこれを無視します。POSIX の式は毎日を 86,400 秒とみなすため、うるう秒はシステムによって、同じ秒を繰り返すか、長い時間に分散して吸収（スメア）されます。

実際には、2つのタイムスタンプの差で求めた経過時間は、その間のうるう秒の数だけずれることがあります。日常のスケジュール管理ならこの誤差は問題になりませんが、科学や金融の時刻管理では TAI や GPS 時刻が使われます。国際的な時刻管理機関は2022年、2035年までにうるう秒の挿入をやめることを決議しました。

2038年問題

古いソフトウェアは Unix 時間を符号付き 32 ビット整数で保存しており、その最大値は 2147483647 です。この値には 2038-01-19T03:14:07Z に達します。その1秒後にカウンターがオーバーフローして -2147483648 になり、1901-12-13T20:45:52Z と解釈されます。

• 最近の 64 ビットの OS、言語、データベースは 64 ビットの time_t を使っており、約 2920 億年もちます。
• リスクが残るのは、組み込み機器、古いファイル形式、MySQL の TIMESTAMP のような 32 ビットのデータベース列、時刻に 4 バイトしか確保していないバイナリプロトコルです。
• 20 年有効の証明書、住宅ローン、有効期限など、遠い将来の値はすでに2038年を超えているため、このバグはその日付よりずっと前に表れることがあります。

タイムスタンプと日付文字列の使い分け

瞬間（イベントが起きた時刻、トークンの有効期限など）は、Unix タイムスタンプか UTC の日付文字列で保存しましょう。どちらもあいまいさがなく、正しく並べ替えられます。

人が読むログ、API、ファイルでは、2026-10-14T09:30:00Z のような読みやすい ISO 8601 の文字列を使いましょう。1791970200 を見ても一目では何もわからないからです。来春のパリでの 9 時の会議のような将来のローカルな予定は、ローカル時刻と IANA のタイムゾーン名で保存しましょう。その日が来る前に夏時間のルールが変わることがあり、事前に計算したタイムスタンプは間違いになってしまいます。