Unixタイムスタンプ変換ツール｜UNIX時間と日時を相互変換

1704067200は2024年1月1日0時(UTC)、日本時間では午前9時です

UNIXタイムスタンプ(UNIX時間)は、1970年1月1日 00:00:00 UTC を0として、そこから経過した秒数を数えた数字です。1704067200は2024年1月1日 00:00:00 UTC にあたり、UTCより9時間進んでいる日本では同じ日の午前9時です。13桁の1704067200000は、同じ瞬間をミリ秒で数えた値です。

上の変換ツールの数字欄に値を貼り付けると、桁数から秒・ミリ秒・マイクロ秒・ナノ秒を見分けて日付に変換します。日付欄に日付と時刻を入れると、逆に数字を作ります。タイムゾーンを選ぶと、その地域のサマータイムや昔の標準時まで反映します。一番上の帯では、現在のUNIX時間が1秒ごとに更新されます。下の数直線は、入れた値が32ビット整数に収まるかどうかを示します。

時刻を数字1つで記録する理由と、変換が必要になる場面

「2024年1月1日午前9時」と書いた日付は、どの国の時刻か、そのときサマータイムだったかが分からないと、同じ瞬間を指しているのか判断できません。UNIX時間は地球上のどこでも同じ瞬間に同じ数字になるため、サーバーのログ、データベース、APIが時刻をやり取りするときによく使われます。2つの値を引き算すれば間の秒数がそのまま出て、大小を比べれば先に起きたことが分かります。

その代わり、数字だけを見ても人間には日付が分かりません。次のような場面で変換が必要になります。

ログを読むとき: エラーの発生時刻が1760000000のように数字だけで記録されていると、日本時間で何時だったかを変換しないと他の記録と突き合わせられません。
APIのレスポンスやトークンを確認するとき: ログイン用トークン(JWT)の exp・iat・nbf は、RFC 7519 が定める NumericDate、つまり 1970-01-01T00:00:00Z からの秒数です。有効期限がすでに過ぎているかを、日付にして確かめます。
データベースで期間を検索するとき: 「2024年1月の1日分」を数値の列で検索するには、その日の0時と翌日の0時のタイムスタンプが必要です。上の「その日・その月・その年の開始と終了」がその値を出します。
Excelで受け取った数字の列を日付にするとき: ダウンロードしたデータの日付列が10桁や13桁の数字なら、単位とタイムゾーンを決めて数式で変換します(Excelの節)。
日付を数字で入力するとき: 予約配信の時刻や有効期限のように、設定値をタイムスタンプで受け取るプログラムに、特定の日本時間を入れる場合です。

計算方法: 1日を常に86,400秒として数えます

POSIX規格は 1970年1月1日 00:00:00 UTC を基準点(Epoch)とし、基準点からの経過時間を数えるとき、1日をちょうど86,400秒とします。そのため、日付を数字にする計算は「基準点からその日の前日までの日数 × 86,400 + その日の0時からの経過秒」になります。

日付と時刻をUTCに直します: 日本時間なら9時間を引きます。2024年1月1日 09:00(日本時間)は2024年1月1日 00:00 UTC です。
1970年1月1日からその日の前日までの日数を数えます: 1970〜2023年は54年 × 365日 = 19,710日に、うるう年13回(1972・1976・…・2020)の1日ずつを足して19,723日です。
日数 × 86,400 に、その日の時 × 3,600 + 分 × 60 + 秒を足します: 19,723 × 86,400 + 0 = 1,704,067,200秒です。
単位をそろえます: ミリ秒は1,000倍、マイクロ秒は1,000,000倍、ナノ秒は1,000,000,000倍します。

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400POSIX.1-2024 4.19 Seconds Since the Epoch (1970年以降の日付に使う式。割り算は整数の割り算)。同じ節に "each and every day shall be accounted for by exactly 86400 seconds" とあります。

数字を日付に戻すときは、逆に86,400で割ります。1,704,067,200 ÷ 86,400 = 19,723、余り0なので、1970年1月1日から19,723日後の2024年1月1日 0時0分0秒 UTC です。この変換ツールは、この計算をナノ秒単位の大きな整数で行い、選んだタイムゾーンの時刻は、ブラウザーのIANAタイムゾーンデータから、その瞬間の実際の時差を足して表示します。

桁数で単位を見分ける: 10・13・16・19桁

タイムスタンプには単位が書かれていません。同じ瞬間でも、秒で数えれば10桁、ミリ秒で数えれば13桁になります。現在に近い日付の桁数と、このツールの自動判別の基準は次のとおりです。

同じ瞬間(2024-01-01 00:00:00 UTC)を単位別に書いた値
単位	値	桁数	自動判別 (整数部)	主な使われ方
秒 (s)	1704067200	10	1000億(10¹¹)未満	PHP time()、MySQL UNIX_TIMESTAMP()、JWT、date +%s
ミリ秒 (ms)	1704067200000	13	10¹¹以上 10¹⁴未満	JavaScript Date.now()、Java System.currentTimeMillis()
マイクロ秒 (µs)	1704067200000000	16	10¹⁴以上 10¹⁷未満	Go UnixMicro()
ナノ秒 (ns)	1704067200000000000	19	10¹⁷以上	Python time.time_ns()、Go UnixNano()

この境界なら、1973年3月3日 09:46:40 UTC から5138年11月16日 09:46:40 UTC までの瞬間は、どの単位で書かれていても正しく見分けられます。1970年から1973年3月初めまでのミリ秒値のように境界より小さい数字は、1段階小さい単位として読まれます。元の単位が分かっている場合は「単位」で直接選んでください。11・14・17桁のようにあまり見かけない桁数には、画面に確認の案内が出ます。

単位を取り違えると、日付が大きくずれます。10桁の1704067200をミリ秒として読むと1970年1月20日 17:21:07.200 UTC になり、13桁の1704067200000を秒として読むと約5万5970年になって、このツールの範囲(9999年)を超えます。日付が1970年1月に固まっていたり、0001〜9999年の範囲を外れるという案内が出たりしたときは、まず単位を確認してください。

変換の例

入力値 → UTC と東京の時刻
入力	単位	UTC	東京
0	秒	1970-01-01 00:00:00	1970-01-01 09:00:00
-1	秒	1969-12-31 23:59:59	1970-01-01 08:59:59
1704034800	秒	2023-12-31 15:00:00	2024-01-01 00:00:00
1704067200	秒	2024-01-01 00:00:00	2024-01-01 09:00:00
1704067200.5	秒	2024-01-01 00:00:00.500	2024-01-01 09:00:00.500
1704067200123	ミリ秒	2024-01-01 00:00:00.123	2024-01-01 09:00:00.123
1704067200123456	マイクロ秒	2024-01-01 00:00:00.123456	2024-01-01 09:00:00.123456
1704067200123456789	ナノ秒	2024-01-01 00:00:00.123456789	2024-01-01 09:00:00.123456789
-615506400	秒	1950-07-01 02:00:00	1950-07-01 12:00:00 (サマータイム, UTC+10)

1704034800は、日本の2024年の元日0時です。日本の日付を入れたのにUTCの日付が前日になるのは、日本がUTCより9時間進んでいるからで、2つの表記が指す瞬間は同じです。

覚えておきたい数字

タイムスタンプ → UTC と東京の時刻
値 (秒)	UTC	東京	意味
0	1970-01-01 00:00:00	1970-01-01 09:00:00	基準点 (Epoch)
1,000,000,000	2001-09-09 01:46:40	2001-09-09 10:46:40	初めて10桁になった瞬間 (10億秒)
1,234,567,890	2009-02-13 23:31:30	2009-02-14 08:31:30	数字が1から0まで順に並んだ瞬間
1,800,000,000	2027-01-15 08:00:00	2027-01-15 17:00:00	18億秒(1億単位の区切り)
2,000,000,000	2033-05-18 03:33:20	2033-05-18 12:33:20	20億秒
2,147,483,647	2038-01-19 03:14:07	2038-01-19 12:14:07	符号付き32ビットの最大値 (2³¹−1)
−2,147,483,648	1901-12-13 20:45:52	1901-12-14 05:45:52	符号付き32ビットの最小値
4,294,967,295	2106-02-07 06:28:15	2106-02-07 15:28:15	符号なし32ビットの最大値 (2³²−1)

ナノ秒を符号付き64ビット整数に入れた場合、最大値の9,223,372,036,854,775,807は2262年4月11日 23:47:16.854775807 UTC です。Goのドキュメントも、UnixNano() は1678年より前や2262年より後の日付では結果が未定義になると書いています。

2038年問題: 32ビット整数に入れた時刻

秒を符号付き32ビット整数に保存すると、入る最大の値は2,147,483,647、つまり2038年1月19日 03:14:07 UTC (日本時間の正午すぎの12時14分7秒)です。その次の1秒は、この枠に入りません。あふれた値が最小の負数−2,147,483,648に変わると、時刻は1901年12月13日 20:45:52 UTC として読まれます。

符号なし32ビット整数は負の数を入れられない代わりに、2106年2月7日 06:28:15 UTC まで使えます。符号付き64ビット整数で秒を数えれば約2920億年まで入るので、実質的に上限はありません。上の数直線の2本の帯がこの2つの範囲で、目印が帯の外にあれば、その値は該当する形式に保存できません。

データベースの列、ファイル形式、古い機器のように32ビットで保存する場所に、2040年が期限の日付のような将来の日付を入れる前に確認してください。MySQL 8.4のドキュメントは、64ビット環境では UNIX_TIMESTAMP() が受け取れる値を3001年(32536771199.999999秒)まで、32ビット環境では2147483647.999999秒までと書いています。

言語・ツール別の現在値と単位

タイムスタンプを作ったプログラムが分かれば、単位も分かります。各公式ドキュメントに書かれた戻り値の単位は次のとおりです。

現在時刻をタイムスタンプで取得するコード
環境	コード	単位	メモ
JavaScript	`Date.now()`	ミリ秒	整数13桁
Python	`time.time()` · `time.time_ns()`	秒 · ナノ秒	time() は小数付きの実数
Java	`System.currentTimeMillis()`	ミリ秒	値の精度はOSによって違う
PHP	`time()`	秒	タイムゾーン情報は含まない
Go	`time.Now().Unix()` · `UnixMilli()` · `UnixNano()`	秒 · ミリ秒 · ナノ秒	UnixNano() は1678〜2262年のみ
MySQL	`UNIX_TIMESTAMP()`	秒	日付を渡すとセッションのタイムゾーンで読む。逆方向は `FROM_UNIXTIME()`
PostgreSQL	`EXTRACT(EPOCH FROM now())`	秒	小数秒を含む。逆方向は `to_timestamp()`
シェル (GNU date)	`date +%s`	秒	逆方向は `date -u -d @1704067200`
JWT	exp · iat · nbf	秒	RFC 7519 NumericDate、小数も可

MySQLの UNIX_TIMESTAMP('2024-01-01 00:00:00') のように日付の文字列を渡す関数は、接続(セッション)のタイムゾーンでその日付を読みます。同じ式でも、サーバーのタイムゾーン設定しだいで9時間違う値が出ることがあります。結果をこのツールに入れて、どの時刻として読まれたかを確かめてください。

タイムゾーンと日本標準時の歴史

タイムスタンプの数字にはタイムゾーンが含まれていません。同じ1704067200が、東京では2024年1月1日の午前9時、ロンドンでは0時、ニューヨークでは前日の午後7時に見えるだけで、指している瞬間は1つです。タイムゾーンは、数字を人間が読む時刻として表示するときにだけ必要です。

日本の時刻も、昔からずっとUTC+9だったわけではありません。IANAタイムゾーンデータの東京(Asia/Tokyo)の記録は次のとおりです。このツールは、その日付に実際に使われていた時差を使います。

東京のUTCとの差 (IANA tzdb asia)
期間	UTCとの差	夏のサマータイム
1888年1月1日より前	+9:18:59	なし (東京の地方平均時)
1888年1月1日 ~ 1947年12月31日	+9:00	なし (日本標準時)
1948年1月1日から	+9:00	1948〜1951年の夏だけ +10:00

たとえば1950年7月1日の正午(東京)は−615,506,400秒です。すべての日付を+9で計算すると−615,502,800秒になり、1時間ずれます。tzdbのルールでは、1948〜1951年のサマータイムは春(1948年は5月、1949年は4月、1950年と1951年は5月)の土曜24時に始まり、9月の土曜25時に終わります。日付欄に存在しない時刻を入れると、飛ばされた分だけ後の時刻として、2回ある時刻は先のほう(サマータイム側)として計算し、そのことを欄の下に表示します。

うるう秒は数えません

原子時計で測った時間と地球の自転とのずれを合わせるため、1972年から2016年までにUTCにうるう秒が27回入りました。UNIX時間は1日を常に86,400秒と数えるので、2016年12月31日 23:59:60 UTC のようなうるう秒の瞬間を表す数字はありません。23:59:59 (1483228799) の次の値1483228800が、そのまま2017年1月1日 00:00:00 UTC です。

そのため、うるう秒をはさむ2つのタイムスタンプを引き算すると、実際に経過した時間より1秒短く出ます。国際地球回転・基準系事業(IERS)は、2026年7月の Bulletin C 72 で2026年12月末にもうるう秒を入れないと発表しており、2017年1月1日からUTC−TAIは−37秒です。日付欄に23:59:60を入れると、うるう秒は存在しないという案内が出ます。

Excelでの変換

Excelの1900年日付システムは、1900年1月1日からの日数をシリアル値として使います。そのため、秒を日付にするには、86,400で割ってから1970年1月1日のシリアル値(25569)を足します。A1に値があるときの数式は次のとおりです。

Excelの数式 (A1 = タイムスタンプまたは日付)
やりたいこと	数式	A1 = 1704067200 のとき
秒 → UTCの日付	`=A1/86400+DATE(1970,1,1)`	45292 → 2024-01-01 00:00:00
秒 → 日本時間	`=A1/86400+DATE(1970,1,1)+9/24`	45292.375 → 2024-01-01 09:00:00
ミリ秒 → UTCの日付	`=A1/86400000+DATE(1970,1,1)`	A1 = 1704067200000 なら 45292
UTCの日付 → 秒	`=(A1-DATE(1970,1,1))*86400`	2024-01-01 00:00 → 1704067200
日本時間 → 秒	`=(A1-DATE(1970,1,1)-9/24)*86400`	2024-01-01 09:00 → 1704067200

数式の結果は数字で表示されるので、セルの表示形式を「yyyy/mm/dd hh:mm:ss」のような日付・時刻にする必要があります。+9/24 は1950年のサマータイムのような昔の時差を反映できないので、古い日付はこのツールで確認してください。Microsoftは、Excelが1900年をうるう年と誤って扱っていると説明しており、1900年3月1日より前の日付はシリアル値が実際と1日ずれます。上の「Excel・スプレッドシートの日付値」の欄は、その期間には値を表示しません。

間違えやすい例

ミリ秒を秒として入れる: 13桁を秒の欄に入れると、数万年後になります。逆に10桁をミリ秒として読むと、1970年1月が出ます。
日本時間を二重に足す: 数字にはタイムゾーンがないので、9時間を足すのは、数字を人間が読む時刻に直すときの1回だけです。ログにすでに日本時間で書かれた日付に、さらに9時間を足すと、日付が1日進むことがあります。
Excelの数式でタイムゾーンを忘れる: =A1/86400+DATE(1970,1,1) はUTCです。日本時間が必要なら +9/24 を足さないと、午前9時より前の記録の日付が合いません。
32ビットの枠に2038年以降の日付を入れる: 保存形式が符号付き32ビットなら、2038年1月19日 03:14:07 UTC より後の値はあふれます。
ナノ秒をJavaScriptの数値で扱う: Number は2⁵³ (9,007,199,254,740,992) より大きな整数を正確に持てないため、1704067200123456789が1704067200123456800に変わります。ナノ秒の値は文字列かBigIntで扱ってください。

制限事項

UTCと選んだタイムゾーンの日付が、どちらも0001年1月1日〜9999年12月31日の範囲に入る値だけを変換します。ナノ秒より小さい桁は受け付けません。1582年より前の日付も、現在のグレゴリオ暦をさかのぼって延長して計算します。
うるう秒の瞬間(23:59:60)は表せません。UNIX時間そのものに、その瞬間の数字がないためです。
タイムゾーンごとの時刻は、このブラウザーに入っているIANAタイムゾーンデータを使います。データが古いブラウザーでは、最近ルールが変わった国の反映が遅れることがあります。
「現在」の値と「現在との差」はこの端末の時計が基準なので、端末の時計が狂っていれば同じようにずれます。現在との差は、1年を365.2425日とした概算です。
「その日・その月・その年の開始と終了」は、選んだタイムゾーンの0時が基準です。0時がサマータイムで飛ばされる地域では、その日に最初に存在する時刻を開始として使います。

出典

01The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the Epoch基準点からの秒数の式、"each and every day shall be accounted for by exactly 86400 seconds"。Epochの定義は3.125 (1970年1月1日0時 UTC)
02IETF RFC 7519: JSON Web Token (JWT)2節 NumericDate: 1970-01-01T00:00:00Z からの秒数、うるう秒は無視、小数可。4.1.4〜4.1.6 exp・nbf・iat
03IETF RFC 3339: Date and Time on the Internet: Timestamps5.6 date-time 形式、時差は±hh:mmまで (秒単位の時差は書けない)
04IETF RFC 9110: HTTP Semantics, 5.6.7 Date/Time FormatsHTTPの日付の標準形式 IMF-fixdate、例 "Sun, 06 Nov 1994 08:49:37 GMT"
05ECMAScript: Time Values and Time Range1日は86,400,000ミリ秒、表現範囲は±8,640,000,000,000,000ミリ秒 (±1億日)
06MDN: Date.now()"returns the number of milliseconds elapsed since the epoch"
07Pythonドキュメント: time.time()・time.time_ns()time() は基準点からの秒 (実数)、time_ns() は整数のナノ秒。ほとんどのUnix系システムはうるう秒を数えない
08Go time パッケージ: Time.Unix・UnixMilli・UnixMicro・UnixNanoUnixNano() は1678年より前や2262年より後では結果が未定義
09MySQL 8.4: UNIX_TIMESTAMP()・FROM_UNIXTIME()戻り値は秒、日付の引数はセッションのタイムゾーンで読む、64ビット環境の上限は32536771199.999999秒
10PostgreSQL: Date/Time Functions, EXTRACT(EPOCH)・to_timestamptimestamp with time zone のepochは 1970-01-01 00:00:00 UTC からの秒 (それ以前は負)
11GNU coreutils: Seconds since the Epoch'@' の後ろの数字は基準点からの秒、date +%s はうるう秒を数えない
12Microsoft: Excel incorrectly assumes that the year 1900 is a leap year1900日付システムのうるう年の誤り、1900年3月1日より前の日付の曜日のずれ。日付システムの説明はMicrosoftサポートの 'Date systems in Excel'
13IERS Bulletin C 72 (2026年7月6日)"NO leap second will be introduced at the end of December 2026"、2017年1月1日からUTC−TAI = −37秒
14IANAタイムゾーンデータ (tzdb) asiaZone Asia/Tokyo: 9:18:59 LMT ~ 1887-12-31 15:00u、以後 9:00 Japan。Rule Japan 1948〜1951年のサマータイム

出典の確認日は2026-10-18です。タイムゾーンデータは毎年何度か改訂され、画面の時刻は使っているブラウザーに入っている版に従います。

よくある質問

現在のUNIXタイムスタンプはいくつですか?

一番上の「現在のUNIX時間」の帯が、この端末の時計を基準に1秒ごとに表示します。2026年10月ごろは17億9000万秒台の10桁の数字で、ミリ秒ならその末尾に3桁が付いた13桁です。「秒をコピー」「ミリ秒をコピー」を押すと、押した瞬間の値をそのままコピーできます。

1704067200は何年何月何日ですか?

2024年1月1日 00:00:00 UTC です。日本時間では同じ日の午前9時です。13桁の1704067200000は、同じ瞬間をミリ秒で書いた値です。

10桁と13桁のタイムスタンプは何が違いますか?

最近の日付なら、10桁は秒、13桁はミリ秒です。同じ瞬間のミリ秒値は秒の値の1,000倍になります。16桁はマイクロ秒、19桁はナノ秒です。10桁をミリ秒として読むと1970年1月に、13桁を秒として読むと数万年後になるので、日付がおかしいときはまず単位を確認してください。

日本時間の日付をタイムスタンプに変えるにはどうしますか?

日付欄に日付と時刻を入れ、タイムゾーンを「東京」にすると、数字欄に秒が出ます。2024年1月1日 00:00:00(日本時間)は、9時間引いたUTCの2023年12月31日 15:00なので、1704034800秒です。

ExcelでUNIX時間を日付に変える数式は?

A1に秒があるとき、=A1/86400+DATE(1970,1,1) がUTCの日付で、日本時間なら末尾に +9/24 を足します。ミリ秒なら86400の代わりに86400000で割ります。結果のセルの表示形式を日付・時刻にしないと、日付として表示されません。

2038年問題とは何ですか?

秒を符号付き32ビット整数に保存すると、最大値が2,147,483,647(2038年1月19日 03:14:07 UTC、日本時間の12時14分7秒)で、それより後の時刻を入れられなくなる問題です。64ビット整数で保存すれば起きません。

負のタイムスタンプもありますか?

はい。1970年1月1日 0時(UTC)より前の瞬間は負の数です。−1は1969年12月31日 23:59:59 UTC で、符号付き32ビットの最小値−2,147,483,648は1901年12月13日 20:45:52 UTC です。

UNIX時間にうるう秒は含まれますか?

いいえ。POSIX規格は1日をちょうど86,400秒と数えます。1972年以降にUTCへうるう秒が27回入りましたが、UNIX時間には23:59:60を表す数字がないため、2016年12月31日 23:59:59(1483228799)の次の値1483228800が、そのまま2017年1月1日 0時です。

昔の日本の日付が、UTC+9でない時差で出るのはなぜですか?

日本では1948〜1951年の夏にサマータイム(UTC+10)が実施されました。このツールはIANAタイムゾーンデータから、その日付に実際に使われていた時差を反映します。1888年1月1日より前は東京の地方平均時(UTC+9:18:59)です。

マイクロ秒・ナノ秒の値も変換できますか?

はい。16桁はマイクロ秒、19桁はナノ秒として自動判別し、ナノ秒まで正確な整数で計算します。JavaScriptの普通の数値(Number)は2⁵³より大きな整数を正確に持てず、ナノ秒値の末尾が変わってしまいますが、このツールは大きな整数(BigInt)で計算します。