Unix時間変換

エポック秒 = 1970-01-01からの日数 × 86,400 + その日のUTCでの経過秒。日付と時刻は同じ計算を逆にたどったもの

方向

どちらへ進むか。タイムスタンプを入れて日時を受け取るか、日時を入れてタイムスタンプを受け取るか

タイムスタンプ

数そのもの。単位の欄に従って秒かミリ秒かが決まります。タイムスタンプから日時への方向でのみ使います

単位

入力した数が秒を数えているのか（今世紀の日付なら10桁）、ミリ秒を数えているのか（13桁）。タイムスタンプから日時への方向でのみ使います

日付

UTCでの暦の日。YYYY-MM-DDの形で書きます。日時からタイムスタンプへの方向でのみ使います

時刻

UTCでの時刻。HH:MMまたはHH:MM:SS。日時からタイムスタンプへの方向でのみ使います

日付（UTC）

そのタイムスタンプがあたるUTCでの暦の日。これが見出しの結果です

時刻（UTC）

UTCでの時刻。秒まで必ず付きます。入力に秒の端数があっても四捨五入せずに切り捨てます

曜日（UTC）

その日付の曜日。0（日曜）から6（土曜）までの数で示します

ISO 8601

2026-01-15T12:00:00Zのような完全な形。コードやログにそのまま貼れます

タイムスタンプ（秒）

同じ瞬間を1970-01-01T00:00:00Zからの整数秒で表したもの。四捨五入せずに切り捨てるので、上の時刻と食い違うことがありません

タイムスタンプ（ミリ秒）

同じ瞬間をミリ秒で表したもの。秒の値の1,000倍で、入力が持っていた秒未満の部分も保ちます

数と日付を突き合わせなければならないときに使います。サーバーログ、APIの応答、データベースの行からタイムスタンプを読み取るとき、送られてきた値が秒なのかミリ秒なのかを確かめるとき、保存するタイムスタンプを作るときなどです。このページは意図的にUTCで止まります。現地の時刻に変換することも、あなたがどのゾーンにいるかを尋ねることもありません。Unix時間にゾーンは無いので、正直な答えはUTCのものになり、それを現地の時計の読みに直すのはタイムゾーン計算の仕事です。タイムスタンプそのものの計算も行いません。「これに30日を足すといつか」は、まず変換してから日付計算を使ってください。

1. 1768478400基準となる瞬間

   1. この数は秒なので、それ自体がすでにエポックの値であり、読む前に変換は要らない
   2. 86,400で割ると1970年1月1日からの丸1日の数が出て、余りがその日の時刻になる。結果は2026年1月15日の12:00:00 UTC
   3. 2026年1月15日は木曜なので、曜日の数は4
   4. 書き下すと2026-01-15T12:00:00Zで、ログやAPIが期待する形
   5. ミリ秒の行は同じ瞬間の1,000倍で、同じ値をミリ秒で報告する仕組みから見るとこう見えるという数

   このページが開いたときに入っている値で、アンカーとして覚えておく価値があります。1768478400は2026年1月15日の正午UTCです。1つのタイムスタンプに馴染んでおくと、このページのほかの変換はどれも確かめやすくなります。間違った答えはたいてい丸1日単位か1,000倍単位で外れていて、どちらも知っているアンカーと突き合わせればすぐ見えるからです。

2. 2147483647 32ビット時代の最後の1秒

   1. 2147483647は2の31乗から1を引いた数で、符号付き32ビット整数が保持できるいちばん大きな数
   2. エポックの数として読むと2038年1月19日の03:14:07 UTCになり、これが2038年問題の内容です。この型でタイムスタンプを持つ仕組みは、その1秒後に余地が尽きて1901年の日付へ回り込みます
   3. 2038年1月19日は火曜なので、曜日の数は2
   4. 秒の行は数をそのまま返します。同じ計算を通って入って出てきたことを確かめる検査になります

   これは下の参考表にある行を、電卓に通したものです。2038年問題というのは日付に届かないという話ではなく（このページは何事もなく扱います）、符号付き32ビットのカウンタを使うプログラムがその次の1秒を表せないという話です。64ビットのカウンタには、問題になるような範囲でこうした端がありません。同じ値をミリ秒で書くと2147483647000になるのはそのためです。

3. 端数を含むミリ秒の値1768478400500

   1. 13桁あり、単位がミリ秒なので、最初の例と同じ瞬間に0.5秒を足したもの
   2. 時計の時刻は端数を四捨五入せずに落とすので、12:00:01ではなく12:00:00と読める
   3. 秒の行もそれに合わせて切り捨てられ、1768478401ではなく1768478400になる
   4. ミリ秒の行は端数を保ちます。結果のなかで端数が存在するのはそこだけだからです

   四捨五入と切り捨てが食い違う唯一の場合であり、秒の行が切り捨てる理由でもあります。0.5秒を切り上げると、すぐ上の時計の時刻より1大きい秒の値が出てしまい、2つの行を見比べた読み手はどちらかが壊れていると結論するでしょう。どの行も表示されている時刻と辻褄が合っていることのほうが、いちばん近い整数であることより大事です。

4. 逆方向2026年1月15日12:00:30 UTC

   1. 日付は1970年1月1日からの日数に変えられ、86,400を掛けて真夜中までの秒数になります
   2. そこに真夜中から30秒が足されます。合計は1768478430で、最初の例の値に30を足したものです
   3. 時刻の欄は秒を受け付けるので、12:00:30は分に切り下げられずそのまま読まれます
   4. 日付と曜日の行は変わらず戻ってきます。外へ出してまた中へ入れるのは恒等な操作だからです

   すでに変換した値に対して逆方向を走らせるのが、タイムスタンプを確かめるいちばん安い方法です。往復して最初の数に戻らなければ、単位が違っていた可能性が高い。単位がミリ秒のときに10桁の数を入れると1,000倍ずれますが、それはエラーではなく1970年1月の日付として現れます。

このページが出すものはすべてUTCで、現地のタイムゾーンへ変換することはありません。Unix時間はタイムゾーンを持たない形で定義されているので、それを現地の時計の読みに直すのはタイムゾーン計算の仕事です。扱える範囲は1970-01-01T00:00:00Zから2100-12-31T23:59:59Zまでで、外れた値は黙って計算されずに拒否されます。負のタイムスタンプはエポック以前の日付に対する正規のUnix時間ですが、このページはその旨を伝えて止まります。1969年の答えを返して、自分で宣言した範囲と矛盾させるよりはましだからです。秒の端数は四捨五入ではなく切り捨てなので、ミリ秒の値は精度を失いませんが、表示される秒に影響することもありません。ほかの書式の日付文字列は解釈しませんし、この端末のタイムスタンプも読みません。計算も行いません。変換した値の30日後が要るなら、日付計算を使ってください。

エポック秒とは何か

エポック秒とは1970-01-01T00:00:00 UTCから経過した秒数のことで、Unix系の仕組みが数え始める0の地点です。Unix時間、POSIX時間とも呼ばれます。どこにいるかには何も依存しません。エポック秒はUTCで定義されるので、同じ瞬間は世界中で同じ値になり、現地の時計について意見の食い違う2台の機械も、タイムスタンプについては一致します。

タイムスタンプを日付に変換するには

値を入れて、秒を数えているのかミリ秒を数えているのかを指定し、返ってくる日付と時刻を読んでください。最初に確かめるべきは桁数です。今世紀の日付なら秒の数は10桁、ミリ秒の数は13桁になります。13桁の値を秒として読むと数万年先の日付になり、拒否されます。10桁の値をミリ秒として読むと1970年1月に着地し、こちらは自分から名乗り出ません。逆方向でもう一度変換するのが、いちばん手早い確認です。

2038年問題とは何か

2038年問題とは、タイムスタンプを符号付き32ビット整数にしまう仕組みで起きることです。その型が保持できるいちばん大きな値は2147483647で、これは2038-01-19T03:14:07 UTCにあたり、その1秒後にカウンタが溢れて1901年の日付になります。タイムスタンプそのものの限界ではなく、記憶域の限界です。64ビットのカウンタにはこの問題がありません。このページはその値もその先も問題なく変換します。32ビット整数ではなく倍精度で計算しているからです。

秒とミリ秒のどちらで保存すべきか

どちらも広く使われていて、どちらも間違いではありません。ただし値だけではどちらなのか分からないので、単位は数と一緒に運ぶか、あらかじめ決めておく必要があります。ミリ秒は秒未満の端数を保ち、JavaScriptのDateオブジェクトや多くのログの仕組みがこれを使います。秒はPOSIXが定義しているもので、多くのAPIやデータベースが返すものです。2つのあいだの変換は1,000倍するだけで、このページは両方の行を出すので、その対をひと目で見られます。

ISO 8601はタイムスタンプと同じものか

いいえ。どちらも同じ瞬間を表すので混同しやすいのですが、別物です。ISO 8601は書き表した形、つまり2026-01-15T12:00:00Zで、人が読めて、並べ替えられて、末尾のZによってUTCからの時差についても曖昧さがありません。Unix時間は書式を持たない1つの数です。ISO 8601の文字列は文書やURLに貼るもので、数は保存したり比べたりするものです。このページは同じ変換から両方を出すので、互いに突き合わせて確かめられます。

• The Open Group Base Specifications — Seconds Since the Epoch：エポックからの経過秒数という規格上の定義 — The Open Group — エポックと閏秒の扱いについての規格上の定義
• RFC 3339 — Date and Time on the Internet: Timestamps：インターネット上で日時を表す書式の規格 — IETF — このページが出力する、Zで終わる文字列の書式
• MDN — Date：JavaScriptの日時オブジェクト — MDN Web Docs — ミリ秒数の値と、JavaScriptにおけるその範囲