UNIXタイムスタンプ変換ツールを作った話｜なぜ1970年1月1日が基準なのか、2038年問題とは

ログファイルやAPIのレスポンスで、こんな数字を見たことはありませんか。

1735689600

これは UNIXタイムスタンプ（Epoch時刻） です。この記事では、Lapis Tech Toolsの UNIXタイムスタンプ変換ツール を題材に、なぜこの仕組みが生まれたのか、実装上どこでつまずきやすいかを解説します。

UNIXタイムスタンプとは何か

UNIXタイムスタンプは、1970年1月1日 00:00:00 UTC（協定世界時）を起点（0）として、そこから経過した秒数を表した数値です。この起点は「UNIX紀元（Epoch）」と呼ばれます。

なぜ1970年なのかについて公式な唯一の理由が明文化されているわけではありませんが、UNIXの開発が本格化した1970年前後のタイミングで、区切りの良い年として採用されたという経緯が広く知られています。OS・プログラミング言語・データベースを問わず、この基準が事実上の世界標準になっています。

秒とミリ秒、桁数で見分ける

実装で最初につまずきやすいのがここです。

• Linuxのシェルコマンドやデータベース（MySQL・PostgreSQL）は秒単位が一般的（10桁）
• JavaScriptのDate.now()や一部のWeb APIはミリ秒単位（13桁）

ツールの変換ロジックでは、この違いを桁数で自動判定しています。

// 13桁以上ならミリ秒、そうでなければ秒とみなして1000倍する
const ts = raw > 9999999999 ? raw : raw * 1000;
const d = new Date(ts);

このワンライナーを入れておかないと、「秒のつもりで渡されたタイムスタンプをミリ秒としてnew Date()に渡してしまい、1970年付近の日付になってしまう」という典型的なバグを踏むことになります。

JST・UTC・ISO 8601、3つの表記が必要な理由

日本国内向けの開発では日本時間（JST、UTC+9）で確認したい場面が多い一方、サーバーログやAPI連携ではUTCやISO 8601形式（2026-01-01T00:00:00.000Zのような形式）で扱うことが多くあります。

ツールでは、1つのUNIXタイムスタンプに対してJST・UTC・ISO 8601の3表記を同時に表示することで、「このAPIのレスポンスはUTCで返ってきているけど、日本時間だと何時なんだっけ」という確認の手間を1回で済ませられるようにしています。

const jst = d.toLocaleString('ja-JP', { timeZone: 'Asia/Tokyo', ... });
const utc = d.toUTCString();
const iso = d.toISOString();

toLocaleStringにタイムゾーンを明示的に渡すことで、サーバー側の実行環境のタイムゾーン設定に依存せず、常に正しいJST表記を得られるようにしています。

2038年問題とは

ツールのプリセット一覧には、あえて次の日時を入れています。

2038/01/19 12:14:07　→　2147483647

これは俗に言う 「2038年問題」 の限界値です。UNIXタイムスタンプを32bit符号付き整数（int32）で扱っているシステムでは、表現できる最大値が2,147,483,647までしかありません。この1秒後にオーバーフローし、日時計算が破綻する可能性があります。

現代の主要な言語・DBは64bit整数（あるいはそれに準ずる型）でタイムスタンプを扱うため影響を受けないケースが大半ですが、古い組み込みシステムやレガシーなCコードベースでは実際に懸念される問題です。「西暦2000年問題（Y2K）」の再来として、エンジニアの間では今も話題に上ります。

まとめ

UNIXタイムスタンプは「1970年からの経過秒数」というシンプルな仕組みですが、実装では

• 秒とミリ秒の桁数判定
• タイムゾーンを明示したJST/UTC変換
• 32bit環境における2038年問題

といった落とし穴があります。ログ調査やAPI開発でタイムスタンプの変換が必要になったら、UNIXタイムスタンプ変換ツールをブラウザ完結（データを外部に送信しない）で使ってみてください。