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秒後にオーバーフローする)

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

このツールは、Unixタイムスタンプ(エポック秒・エポックミリ秒)と人間が読める日時表記を、ブラウザ内だけで相互変換するツールです。サーバーのログに残る「1752300000」のような数値がいつの時刻なのか調べたいとき、逆に「2026年7月12日 15時30分(日本時間)」をAPIに渡すための数値へ変換したいとき、どちらの方向にも対応します。桁数から秒とミリ秒を自動判定する機能があるため、単位が分からない値を貼り付けてもまず迷いません。

変換結果はISO 8601形式(UTC)に加えて、日本標準時・米国東部時間・米国太平洋時間・英国時間・中央ヨーロッパ時間の主要タイムゾーンでの表記を一覧表示します。あわせて「3時間前」のような相対時間も表示するため、ログの発生時刻が現在からどれくらい前かを直感的に把握できます。すべての計算はJavaScriptでその場で行われ、入力した値が外部サーバーへ送信されることはありません。

Unixタイムスタンプ変換ツールの使い方

  1. 変換したい方向を選ぶ タイムスタンプから日時を知りたいときは上のカード、日時からタイムスタンプを求めたいときは下のカードを使います。
  2. タイムスタンプまたは日時を入力する ログやAPIレスポンスからコピーした数値を貼り付けるか、日時入力欄にカレンダーから直接入力します。
  3. 単位・タイムゾーンを確認する 上のカードでは秒・ミリ秒の単位を、下のカードでは入力した日時がどのタイムゾーンの時刻かを選択します。「自動判定」のままでも桁数から推測されます。
  4. 「現在時刻を入力」で今の時刻を試す ボタンを押すとブラウザの現在時刻がその場で入力欄に反映され、動作確認や検算に使えます。
  5. 結果とタイムゾーン一覧を読み取る ISO 8601表記・相対時間・各タイムゾーンでの表示がまとめて表示されるので、必要な形式をコピーして使います。

使いこなすためのヒント

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

Unixタイムスタンプ変換ツールの活用シーン

サーバーログの時刻解析

アクセスログやエラーログに残るエポック秒を貼り付けて、実際に何時に起きた出来事だったのかをその場で確認できます。

API開発・デバッグ

REST APIのレスポンスに含まれるタイムスタンプフィールドが秒かミリ秒かを判定し、期待した日時になっているかをすぐに検証できます。

データベースのタイムスタンプ列の調査

DBに保存された数値型の日時カラムを確認する際、SQLクライアントを開かずに素早く人間可読な日時へ変換できます。

複数タイムゾームをまたぐチームとの調整

海外拠点のメンバーとイベント開始時刻を共有する際、UTC基準の数値から各地域の現地時刻を一括で確認できます。

テストデータ・サンプルコードの作成

特定の日時に対応するタイムスタンプ値が欲しいとき、日時からタイムスタンプへ変換してテストコードにそのまま埋め込めます。

用語集

Unixタイムスタンプ(エポック秒)
1970年1月1日 00:00:00 UTCからの経過秒数で日時を表す数値。タイムゾーンに依存しない単一の値として、多くのシステムで日時の内部表現に使われています。
Unixエポック
Unixタイムスタンプの起点となる1970年1月1日 00:00:00 UTCのことです。この瞬間のタイムスタンプ値は0になります。
UTC(協定世界時)
世界共通の時刻の基準です。日本標準時はUTCより9時間進んでいる(UTC+9)というように、各地の時刻はUTCからのオフセットで表されます。
エポックミリ秒
Unixエポックからの経過時間をミリ秒(1000分の1秒)単位で表した数値です。JavaScriptのDate.now()はこの形式を返し、秒単位より3桁多い13桁前後の値になります。
ISO 8601
「2026-07-12T15:30:00.000Z」のように年月日と時刻を国際規格化した表記方法です。末尾のZはUTCであることを示し、多くのプログラミング言語やデータベースがそのまま解釈できます。
2038年問題
32bit符号付き整数でUnixタイムスタンプを扱うシステムが、2038年1月19日 03:14:07 UTC(整数の最大値2,147,483,647秒)の1秒後にオーバーフローし、日時が誤って巻き戻ってしまう問題です。
夏時間(DST)
一部の国や地域で、日照時間を有効活用するために特定期間だけ時計を1時間進める制度です。米国東部時間や中央ヨーロッパ時間など、このツールが対応するタイムゾーンの一部にも夏時間があります。
相対時間表現
「3時間前」「2日後」のように、基準時刻からの差を人間が直感的に理解しやすい形で表す表現方法です。

よくある質問

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連携のデバッグで「時刻がずれている」と混乱するバグの多くは、このタイムゾーン変換の考慮漏れが原因であることも少なくありません。