Unixタイムスタンプ変換ツール

Unixタイムスタンプ(エポック秒・ミリ秒)と人間可読な日時を相互変換します。世界時計・現在時刻の即時入力・複数タイムゾーンでの表示に対応した開発者向けツールです。

Unixタイムスタンプの基礎知識

Unixタイムスタンプは、1970年1月1日 00:00:00 UTC(Unixエポック)からの経過秒数で日時を表す仕組みです。以下は代表的なタイムスタンプの値とそれが指す日時の対応表です。

タイムスタンプ(秒) UTC日時 備考
0 1970-01-01T00:00:00Z Unixエポック(タイムスタンプの起点)
1000000000 2001-09-09T01:46:40Z 「10億秒」到達の瞬間(Unix Billennium)
1234567890 2009-02-13T23:31:30Z 10進数の各桁が1〜9まで並ぶ瞬間として話題になった値
2147483647 2038-01-19T03:14:07Z 2038年問題:32bit符号付き整数の最大値(この1秒後にオーバーフローする)

使い方のヒント

  • 10桁ならおおむね「秒」、13桁ならおおむね「ミリ秒」です。「自動判定」を選んでおけば桁数から自動的に単位を推測します。
  • サーバーのログやAPIレスポンスのタイムスタンプをそのまま貼り付けて、複数タイムゾーンでの表示を一括確認できます。
  • 日時 → タイムスタンプの変換では、入力した日時が「どのタイムゾーンの時刻か」を明示的に選ぶ必要がある点に注意してください。
  • ISO 8601形式(UTC)は多くのプログラミング言語・データベースがそのままパースできるため、ログの検索やAPI設計時の参考値としても便利です。
  • 「現在時刻を入力」ボタンを押すと、ブラウザのDate.now()から取得した現在時刻が即座に入力欄へ反映されます。

よくある質問

Unixタイムスタンプ(エポック秒)とは、1970年1月1日 00:00:00 UTC(Unixエポック)からの経過秒数で日時を表現する方式です。タイムゾーンに依存しない単一の数値で時刻を一意に表せるため、サーバーのログ・データベース・API等、コンピューター間で日時をやり取りする際の標準的な表現方法として広く使われています。

2038年問題とは、32bit符号付き整数でUnixタイムスタンプを扱っているシステムが、2038年1月19日 03:14:07 UTC(整数の最大値 2,147,483,647 秒)の1秒後にオーバーフローを起こし、日時が1901年頃に巻き戻ってしまう不具合のことです。現代の多くのシステムは64bit整数を使うため影響を受けませんが、組み込み機器や古いシステムでは依然として注意が必要とされています。

現在の日時(2020年代〜2030年代)を表すタイムスタンプは、秒単位ならおおむね10桁、ミリ秒単位ならおおむね13桁になります。本ツールの「自動判定」モードはこの桁数の違いを利用して単位を自動的に推測しますが、確実に判断したい場合は元データの仕様書やAPIドキュメントを確認するのが最も確実です。

1970年1月1日が採用された明確な単一の理由が文書化されているわけではありませんが、Unix自体が1969年〜1970年頃に開発されたこと、また当時のコンピューターのメモリ制約上、扱いやすいキリの良い年として選ばれたと言われています。この日付は「Unixエポック」と呼ばれ、以来ほぼすべてのプログラミング言語・OSで踏襲される事実上の標準になりました。

負の値は1970年1月1日より前の日時を表します。例えばタイムスタンプ -86400 は1969年12月31日 00:00:00 UTCを意味します。歴史的な日付や生年月日が1970年以前になるデータを扱うシステムでは、負のタイムスタンプが使われることがあります。
ツールくん

余談ですが ― コンピューターはなぜ「秒数」で時刻を数えるのか

人間は「2026年7月12日 17時8分」のように年月日と時刻を組み合わせて日時を表現しますが、コンピューターにとってこの形式は扱いにくいものです。うるう年・タイムゾーン・夏時間などの複雑なルールを毎回考慮しなければならず、2つの日時の差を計算するだけでも煩雑な処理が必要になります。そこで考え出されたのが、ある基準時刻からの経過秒数という単一の数値だけで時刻を表現する方法で、これがUnixタイムスタンプです。

単一の整数値として時刻を扱えることの最大の利点は、日時同士の比較・加減算が単純な四則演算に帰着することです。「2つのイベントの間隔は何秒か」を求めるにはタイムスタンプの差を取るだけでよく、うるう年や月の日数の違いを気にする必要が一切ありません。この単純さゆえに、Unix系OSだけでなくWindows・データベース・多くのプログラミング言語の内部表現としても採用され、事実上の世界標準になりました。

一方で、この「タイムゾーンに依存しない単一の数値」という設計は、人間が読む段階になって初めてタイムゾーンの変換が必要になることを意味します。同じタイムスタンプでも、東京で見れば深夜、ニューヨークで見れば前日の昼という具合に、表示するタイムゾーンによって見た目の日時がまったく異なります。ログ調査やAPI連携のデバッグで「時刻がずれている」と混乱するバグの多くは、このタイムゾーン変換の考慮漏れが原因であることも少なくありません。