Unix time変換:エポック秒⇔日時

タイムスタンプや日時を貼り付けると、お使いのタイムゾーンとUTCの日時に加え、数値のほかの読み方もすべて表示します。

s · ms · µs · ns · FILETIME · .NET · Excel · NTP · GPS · ブラウザー内で動作

例 · 817876800

土曜日

1995年12月2日

04:00:00 UTC

UTC
1995年12月2日(土) · 04:00:00
1995年12月2日(土) · 04:00:00UTC · UTC+00:00
相対時間
31 年前
表記形式
ISO 8601 · UTC
1995-12-02T04:00:00Z
ISO 8601 · UTC
1995-12-02T04:00:00Z
RFC 5322 · メールRFC 2822で定義された形式
Sat, 02 Dec 1995 04:00:00 +0000
HTTPの日付RFC 9110
Sat, 02 Dec 1995 04:00:00 GMT
SQL DATETIMEUTC
1995-12-02 04:00:00
秒
817876800
ミリ秒
817876800000
マイクロ秒
817876800000000
ナノ秒
817876800000000000

1つの数値 · すべてのエポック

7通りの読み方が実在の日付になります

桁数からUnix秒として読みました(9桁)。GPS秒として読むと2005年12月6日になります。これも実在の日付なので、ワンクリックで切り替えられるようにしています。

読み方日付
1900〜2100年:実在の日付今日2038年:32ビットの限界実在の日付にならない行を選ぶと、その読み方を使います
現在時刻

ミリ秒
マイクロ秒
ナノ秒
ISO 8601

ブラウザーの時計は整数のミリ秒単位で刻みます。それより下の0は桁合わせで、精度ではありません。

日時 → タイムスタンプ
タイムゾーン

UTC · この日付ではUTC+00:00

1793813880
ミリ秒
1793813880000
ISO 8601
2026-11-04T17:38:00Z
開始と終了(UTC)
開始終了
日17937504001793836799
月17934912001796083199
年17672256001798761599

処理はすべてこのタブの中で行い、貼り付けた内容はどこにも送信しません。

Unix time変換ツールの使い方

手元のタイムスタンプを、単位を問わずそのまま入力欄に貼り付けると、お使いのタイムゾーンとUTCで日時が表示されます。日付、メールのDateヘッダー、現在(now)という語を入力すれば、そのエポック時間がわかります。

このページは数値を秒、ミリ秒、マイクロ秒、ナノ秒として同時に読み、実在の日付になる読み方を選んで理由を示し、ほかの読み方にもワンクリックで切り替えられるようにします。答えの下では、同じ数字をWindows、.NET、Mac、Excel、NTP、GPSのタイムスタンプとしても読み、どの形式もコピーできます。

Unix time変換ツールの画面:133756272000000000をWindows FILETIMEとして読んで2024年11月9日と表示し、すべてのエポックを1本の時間軸に並べた様子Unix time変換ツールの画面:133756272000000000をWindows FILETIMEとして読んで2024年11月9日と表示し、すべてのエポックを1本の時間軸に並べた様子何でも貼り付け任意の単位の数値、ISO形式の日付、メールのDateヘッダー、SQLの日時、「現在」(now)という語。どう読み取ったかは入力欄の表示でわかります。桁を数える数値の下の目盛りが桁を3つずつ区切るので、18桁なら6つのグループになります。それが何かを知る最初の手がかりです。答えが先曜日と日付、続いてUTCとお使いのタイムゾーンでの時刻、そしてコピーできるすべての形式を表示します。どの読み方か、その理由どの読み方を選んだか、なぜそうしたかを言葉で示し、ほかに実在の日付になる読み方があれば、その名前も挙げます。ほかのすべてのエポック同じ数字をすべての単位とエポックで読み、それぞれの起点から伸びるバーで示します。行を選ぶと、その読み方を使います。
Windows FILETIMEを読み取っているところです。番号を選ぶと、各部分の役割がわかります。

エポック時間とは? なぜ1970年から始まるのか

エポック時間(Unix時間)とは、1970-01-01 00:00:00 UTCからの秒数です。この瞬間をPOSIXは「エポック(the Epoch)」と呼びます。タイムスタンプ0がその瞬間で、817876800は1995-12-02 04:00 UTCです。

1970年が選ばれた理由を記録した一次資料はありません。1971年11月の最初のUnixマニュアルは1971年1月1日からの60分の1秒を数えており、時計が約2年半で尽きると書いていました。1979年の第7版では、カウントは1970年1月1日からの秒数になっていました。Unixが書かれていた時期に近い、切りのよい日付です。UTC自体は1972年に始まったので、それより前のタイムスタンプは慣例としてUTCです。

Unix第1版、1971年1971年1月1日からの60分の1秒の数、32ビット

1973年4月8日に上限到達 · 2.27年

Unix第7版、1979年1970年1月1日からの秒数、符号付き32ビットの数

1901-12-13 → 2038-01-19前後それぞれ68年

負のカウント:1970年より前

年代--志向のユーザーなら、2**32個の60分の1秒が約2.5年にすぎないことに気づくだろう。

UNIX Programmer's Manual 第1版、time (II)、1971年11月3日

このページが読むすべてのエポックを1本の線上に

  1. .NET0001-01-01 · 100 ns単位のティック
  2. Windows FILETIME1601-01-01 · 100 ns単位のティック
  3. Excel1899-12-30 · 日
  4. NTP1900-01-01 · 秒
  5. Mac HFS+1904-01-01 · 秒
  6. Excel 19041904-01-01 · 日
  7. Unix1970-01-01 · 秒
  8. GPS1980-01-06 · 秒
どちらのバーも、カウンターのサイズから計算しています。2³²個の60分の1秒は2.27年で上限に達し、マニュアル自身の見積もりを少し下回ります。このページが読むほかのエポックはどれも、同じ線上の別の位置から始まります。変換ツール自身の時間軸で描いています。 出典:time (II), 1971, time (2), 1979

タイムスタンプの単位は秒・ミリ秒・マイクロ秒・ナノ秒のどれ?

桁数を数えます。現在のタイムスタンプは、秒(エポック秒)なら10桁、ミリ秒なら13桁、マイクロ秒なら16桁、ナノ秒なら19桁です。JavaScriptとJavaはミリ秒、Unixのツールと多くのAPIは秒を使います。

桁数は有力な手がかりですが、証拠ではありません。NTP、GPS、Macのタイムスタンプも現在は10桁で、Windows FILETIMEと.NETのティック数はどちらも18桁です。そのためこのページはすべての尺度を同時に読み、選んだ読み方をほかの読み方と並べて表示します。また、FILETIMEはJavaScriptで正確に保持できる大きさを超えるため、このページは貼り付けた桁をそのまま保持します。

10桁 · 4種類の尺度 · 数字だけではどれか判断できない

Unix秒1792972800
NTP秒4001961600
GPS秒1477008018
Mac HFS+3875817600
Unixミリ秒1792972800000
Unixマイクロ秒1792972800000000

18桁 · 2種類の尺度 · 最初の桁だけで区別できる

Windows FILETIME134374464000000000
.NETティック639285696000000000
Unixナノ秒1792972800000000000

10桁の秒数は2001-09-09T01:46:40Zから2286-11-20T17:46:39Zまでです。これは285年にわたる範囲で、単位ではありません。

どの値も同じ瞬間(2026年10月26日 00:00 UTC)を、それぞれの尺度で表したものです。桁数でUnixの単位は区別できますが、エポックは区別できません。 出典:ECMA-262 §21.4.1, [MS-DTYP] 2.3.3, DateTime.Ticks

Unix時刻を日本時間(JST)など現地の日時に変換するには?

Unixタイムスタンプにはタイムゾーンがなく、どこでも同じ1つの瞬間を指します。日付はどこで読むかで変わるため、このページはお使いのタイムゾーン(日本ならJST)とUTCを並べて表示し、ほかに選んだタイムゾーンでも表示します。

タイムゾーンの選択にはIANAタイムゾーンデータベースを使います。OSが使っているのと同じデータベースなので、夏時間(サマータイム)の切り替えは今日ではなく、その日付に合わせて適用されます。逆向きの変換では、オフセットなしで入力した日付はUTCとして読み、お使いのタイムゾーンで読み直すこともできます。

1つの瞬間1793057400= 2026-10-26T23:30:00Z

  • ロサンゼルス16:3010月26日(月)UTC−07:00
  • ニューヨーク19:3010月26日(月)UTC−04:00
  • UTC23:3010月26日(月)UTC+00:00
  • ベルリン00:3010月27日(火)UTC+01:00
  • コルカタ05:0010月27日(火)UTC+05:30
  • 東京08:3010月27日(火)UTC+09:00
  • ロード・ハウ島10:3010月27日(火)UTC+11:00

ベルリン、2026年3月29日23時間 · 時計が02:00から03:00に進んだ

ベルリン、2026年10月25日25時間 · 時計が03:00から02:00に戻った

中央ヨーロッパ標準時 · UTC+01:00中央ヨーロッパ夏時間 · UTC+02:002回あった1時間存在しなかった1時間

1つのタイムスタンプと7か所の時計。現地の日付がUTCと違う場合は印を付けています。2026年のベルリンの2回の切り替え日には、どの瞬間も指さない時刻と、2つの瞬間を指す時刻がありました。 出典:ECMA-262 §21.4.1.19, IANA tz

2038年問題:Unix時間は2038年にどうなる?

符号付き32ビット整数で保存したUnix時間は2147483647で尽きます。これは2038-01-19 03:14:07 UTCで、その1秒後には1901年12月の日付に折り返します。POSIXが現在求めているように64ビットで数えるシステムは影響を受けません。

2026年時点でのリスクは、時計ではなく保存先にあります。MySQLのTIMESTAMP列は今も2038-01-19 03:14:07 UTCで終わり、32ビットのフィールドを残したファイル形式や組み込み機器も同じです。NTPにはそれより早い独自の桁あふれがあり、32ビットの秒は2036年に一巡します。このページは、2038年の境界に近い、または超えたタイムスタンプに印を付けます。

2,147,483,647符号付き32ビットの最大値

01111111 11111111 11111111 11111111

2038年1月19日(火)03:14:07 UTC

+ 1秒

-2,147,483,648同じ32ビットを符号付きとして読んだ値

10000000 00000000 00000000 00000000

1901年12月13日(金)20:45:52 UTC

最後の1秒(UTC)

符号付き32ビットのtime_t2038-01-19 03:14:07
符号なし32ビットの秒2106-02-07 06:28:15
MySQLのTIMESTAMP列2038-01-19 03:14:07
NTP、era 02036-02-07 06:28:15
Mac HFS+の日付2040-02-06 06:28:15

今日2038-01-19

どの終端も、フィールド自身のサイズから計算した、保持できる最後の1秒です。POSIX.1-2024が必須とする64ビットのtime_tなら、1970年の前後それぞれ約2923億年まで表せます。 出典:POSIX.1-2024 A.4.19, MySQL 8.4, RFC 5905 §6, TN1150

Unixタイムスタンプは負の値になる?

はい。負のタイムスタンプは1970年より前の日付です。-1は1969-12-31 23:59:59 UTC、-86400は1969-12-31 00:00:00 UTCです。

POSIX自体は負の値を未定義としていますが、GNUや多くのシステムは文書化された拡張として1970年より前の日付と扱い、JavaScript、Python、PostgreSQLも同様です。例外はMySQLで、TIMESTAMP列は1970年から始まり、FROM_UNIXTIME(-1)はNULLを返します。生年月日や歴史的な記録はごく普通の負のタイムスタンプなので、このページは誤りとせず、日付として読みます。

秒さかのぼる距離(対数目盛)日付(UTC)

01970年1月1日(木)00:00:00 UTC
-11969年12月31日(水)23:59:59 UTC
-86,4001969年12月31日(水)00:00:00 UTC
-31,536,0001969年1月1日(水)00:00:00 UTC
-1,000,000,0001938年4月24日(日)22:13:20 UTC
-2,147,483,6481901年12月13日(金)20:45:52 UTC
  • POSIX年が<1970であるか、値が負である場合、その関係は未定義である。
  • GNU date@-1は1969-12-31 23:59:59 UTC:POSIXの拡張としての負のカウント
  • JavaScript1970年の前後約273,790年以内なら、どの日付でも
  • MySQL TIMESTAMP1970-01-01 00:00:01 UTCから始まり、負の値は保持できない
各値をUnix秒として読んでいます。バーは対数目盛なので、小さな値も見えます。最後の行は、符号付き32ビットのフィールドが保持できる最小の数で、2038年問題の反対側の端です。 出典:POSIX.1-2024 §4.19, GNU Coreutils, ECMA-262 §21.4.1, MySQL 8.4

Windows・.NET・Mac・Excel・NTP・GPS:ほかのエポック

多くのシステムは独自のゼロから数えます。Windowsは1601年、.NETは西暦1年、MacとHFS+は1904年、Excelは1900年、NTPは1900年、GPSは1980年1月6日からです。Unixタイムスタンプとしては意味をなさない数値は、多くの場合このどれかです。

たとえばFILETIMEの133756272000000000は、1601年からの100ナノ秒単位の数で、2024-11-09 12:00:00 UTCです。Excelは日数を数え、1900年を意図的にうるう年として扱うため、シリアル値61未満は1日ずれており、このページはそれに印を付けます。GPS時刻はうるう秒を飛ばしており、2017年からUTCより18秒進んでいます。

エポック単位起点2026年10月26日時点桁数タイムゾーン使われる場所
Unix秒秒1970-01-01179297280010UTC(POSIX)date +%s、Pythonのtime.time()
Unixミリ秒ミリ秒1970-01-01179297280000013UTCJavaScriptのDate.now()、Java
Unixナノ秒ナノ秒1970-01-01179297280000000000019UTCGoのUnixNano()
Windows FILETIME100 ns単位のティック1601-01-0113437446400000000018UTC(FATでは現地時刻)NTFS、Active DirectoryのlastLogon、Win32
.NETティック100 ns単位のティック0001-01-0163928569600000000018KindによりUTCまたは現地時刻.NETのDateTime.Ticks
Excelシリアル値日1899-12-30463215なし:時計の表示Excel、Google Sheets、LibreOffice
Excel 1904日1904-01-01448595なし:時計の表示古いMac版Excel
Mac HFS+秒1904-01-01387581760010GMT(旧HFS:現地時刻)HFS+のファイルの日付
NTP秒秒1900-01-01400196160010UTCNTPパケット
GPS秒秒1980-01-06147700801810うるう秒なし:UTC + 18sGPS受信機、RINEXファイル
どの値も同じ瞬間(2026年10月26日 00:00 UTC)をそれぞれの尺度で表したもので、このページが動かしているエンジンで計算しています。Google SheetsとLibreOfficeも1899-12-30から日数を数えるので、1900年3月1日以降はシリアル値がExcelと一致します。 出典:[MS-DTYP] 2.3.3, DateTime.Ticks, Excel, Google Sheets, LibreOffice, TN1150, RFC 5905, RINEX 3.05

Unix時間はうるう秒を数える?

いいえ。Unix時間は毎日をちょうど86,400秒とするため、うるう秒には固有の数値がありません。POSIXもそう述べています。分解したPOSIX時刻は、見かけに反して必ずしもUTCではありません。

1972年以降、UTCには27回のうるう秒が追加されました。Unix時間にはその余分な1秒に当たる数値がないため、1つのタイムスタンプが2秒分を表します。最後のうるう秒は2016-12-31で、2022年には国際度量衡総会が、うるう秒が必要になる上限を2035年までに引き上げることを決めました。これで事実上、うるう秒は終わります。うるう秒をもともと持たないGPS時刻を見ると、その差がわかります。18秒進んでいます。

1998年12月31日の最後の数秒

UTC23:59:5823:59:5923:59:6000:00:0000:00:01
Unix時間915148798915148799915148800915148800915148801
GPS時刻599184010599184011599184012599184013599184014

Unix時間は915148800を2回使います。うるう秒のないGPS時刻は数え続けます。

うるう秒27回2016年12月31日より後はなし · 2027年6月28日より前の予定なし

GPS時刻の開始前GPS時刻の開始後:1回ごとにGPS時刻が1秒ずつ先行

協定世界時(UTC)にはうるう秒が含まれる。しかし、POSIX時刻(エポックからの秒数)では、時間差を簡単かつ互換性のある方法で計算できるように、うるう秒は無視される(適用されない)。したがって、分解されたPOSIX時刻は、見かけに反して必ずしもUTCではない。

POSIX.1-2024, Rationale A.4.19
このうるう秒の直後、GPS時刻はUTCより13秒進んでいました。 出典:POSIX.1-2024 A.4.19, leap-seconds.list, RINEX 3.05

Python・JavaScript・Java・C#・Go・SQL・シェルでUnixタイムスタンプを変換する

どの言語でも、1〜2行で双方向に変換できます。落とし穴は単位(JavaScriptとJavaはミリ秒で数える)とタイムゾーン(データベースはセッションのタイムゾーンで値を読むことがある)です。

下の例はどれも817876800を日付に変換し、日付を秒に戻すもので、実際に実行して出力を確認しています。シェルでは、macOSとBSDはdate -r 817876800、GNU/Linuxはdate -d @817876800を使います。この2つに互換性はありません。

from datetime import datetime, timezone

t = datetime.fromtimestamp(817876800, tz=timezone.utc)
print(t.isoformat())  # 1995-12-02T04:00:00+00:00

back = datetime(1995, 12, 2, 4, 0, tzinfo=timezone.utc)
print(int(back.timestamp()))  # 817876800

2026年10月26日にPython 3.14.4で実行:コメントのとおりに出力されます。

各タブは、貼り付けたまま動く完全なプログラムまたはセッションです。シェルのタブでは、お使いのシステム用の半分を実行してください。 出典:docs.python.org, ECMA-262, Instant, DateTimeOffset, pkg.go.dev/time, PostgreSQL, MySQL, date(1), GNU Coreutils

エポック時間:よくある質問

エポック時間とは?

エポック時間(Unix時間、Unixタイムスタンプ)は、1970-01-01 00:00:00 UTCから経過した秒数で、うるう秒は数えません。1つの数値なら比較、並べ替え、送信が簡単なので、コンピューターは日付をこの形で保存します。タイムスタンプ1000000000は2001-09-09 01:46:40 UTCで、上の入力欄でどんな値も日付に変換できます。

エポック時間(unixtime)を日付に変換するには?

上の入力欄に数値を貼り付けます。このページは数値を秒、ミリ秒、マイクロ秒、ナノ秒として読み、実在の日付になる読み方を選んで、お使いのタイムゾーンとUTCで日付を表示します。手作業なら、秒を1,000倍して日付関数に渡します。JavaScriptならnew Date(817876800 * 1000)です。

現在のエポック時間は?

このページの時計が、現在のUnix時間を秒、ミリ秒、マイクロ秒、ナノ秒でリアルタイムに表示し、どの値もコピーできます。お使いの端末の時計から取得しているので、正確さはその時計しだいです。インターネットで時刻を同期しているコンピューターなら、誤差はたいてい1秒未満です。コマンドラインではdate +%sで秒単位で表示できます。

Unixタイムスタンプの単位は秒?ミリ秒?

従来のUnixタイムスタンプは秒ですが、JavaScript、Java、多くのWeb APIはミリ秒を使い、マイクロ秒やナノ秒を使うデータベースやログもあります。現在のタイムスタンプは、秒なら10桁、ミリ秒なら13桁です。日付が1970年や数千年後になったら単位の誤りです。このページはすべての単位を試し、意味の通るものを示します。

Unix時間はなぜ1970年から始まる?

理由を記録した一次資料はありません。1971年の最初のUnixマニュアルは1971年1月1日からの60分の1秒を数えており、数年以内に尽きると見込んでいました。カウントが秒単位に変わったとき、1970年1月1日が起点になりました。Unixが書かれていた時期に近い切りのよい日付で、そこから32ビットの秒数で2038年まで届きます。

Unix時間とUTCは同じ? うるう秒はどうなる?

ほぼ同じですが、完全には一致しません。Unix時間はUTCの暦と時刻に従いますが、毎日をちょうど86,400秒としてうるう秒を無視するため、うるう秒には固有のタイムスタンプがありません。POSIX自身も、分解したUnix時間は必ずしもUTCではないとしています。人が読む日時では差は表れませんが、うるう秒をまたぐ精密な間隔では表れます。

2038年問題とは?

符号付き32ビットで保存したUnix時間の上限は2147483647、つまり2038-01-19 03:14:07 UTCです。1秒後にはあふれて、1901年12月と読まれます。最新のOSは64ビットの時刻を使うので安全ですが、一部のデータベース、ファイル形式、組み込み機器には32ビットのフィールドが残り、たとえばMySQLのTIMESTAMP列は今もその1秒で終わります。

1970年より前の日付も変換できる?

はい。1970年より前の日付は負のタイムスタンプで、-1は1969-12-31 23:59:59 UTC、1950年の日付は約-6億3100万です。負の数を貼り付ければ日付を、古い日付を入力すれば負の値を表示します。厳密なPOSIXは負の値を未定義とし、MySQLのTIMESTAMPは保持できませんが、ほとんどの言語とデータベースは1970年より前の日付として読みます。

Windows FILETIMEを日付に変換するには?

FILETIMEは1601-01-01 UTCからの100ナノ秒単位の数なので、現在は18桁です。入力欄に貼り付けると、Unixの単位と並べてFILETIMEとして読みます。133756272000000000は2024-11-09 12:00:00 UTCです。手作業なら116444736000000000を引き、10,000,000で割るとUnix秒になります。

Excelの日付シリアル値をタイムスタンプに変換するには?

Excelのシリアル値は日数を数え、時刻は小数で表します。既定の1900年方式では45658が2025-01-01です。シリアル値を貼り付けると、1900年方式と1904年方式の両方でExcelの日付として読みます。Excelは1900年を意図的にうるう年として扱うため、61未満のシリアル値は1日ずれます。このページは推測せず、そこに印を付けます。

タイムゾーンや夏時間に対応していますか?

はい。各日付をお使いのタイムゾーンとUTCで表示し、America/New_YorkやAsia/KolkataなどIANAのどのタイムゾーンも選べます。夏時間は今日ではなく変換する日付に合わせて適用されるため、夏のタイムスタンプは冬に見ても夏時間です。オフセットなしで入力した日付はUTCとして読み、ワンクリックでお使いのタイムゾーンで読み直せます。

タイムスタンプはどこかに送信されますか?

いいえ。変換はブラウザー内で行うので、貼り付けた内容は端末から出ず、どのサーバーも見ません。「リンクをコピー」で作ったリンクはアドレスにタイムスタンプを含むため、開いたページにはすぐ日付が表示されます。それ以外は何も保存も送信もしません。

足りないものはありますか?機能や新しいツールを提案する