Unix time変換:エポック秒⇔日時
タイムスタンプや日時を貼り付けると、お使いのタイムゾーンとUTCの日時に加え、数値のほかの読み方もすべて表示します。
1つの数値 · すべてのエポック
7通りの読み方が実在の日付になります桁数からUnix秒として読みました(9桁)。GPS秒として読むと2005年12月6日になります。これも実在の日付なので、ワンクリックで切り替えられるようにしています。
- ミリ秒
- マイクロ秒
- ナノ秒
- ISO 8601
ブラウザーの時計は整数のミリ秒単位で刻みます。それより下の0は桁合わせで、精度ではありません。
UTC · この日付ではUTC+00:00
1793813880- ミリ秒
1793813880000- ISO 8601
2026-11-04T17:38:00Z
開始と終了(UTC)
| 開始 | 終了 | |
|---|---|---|
| 日 | 1793750400 | 1793836799 |
| 月 | 1793491200 | 1796083199 |
| 年 | 1767225600 | 1798761599 |
処理はすべてこのタブの中で行い、貼り付けた内容はどこにも送信しません。
Unix time変換ツールの使い方
手元のタイムスタンプを、単位を問わずそのまま入力欄に貼り付けると、お使いのタイムゾーンとUTCで日時が表示されます。日付、メールのDateヘッダー、現在(now)という語を入力すれば、そのエポック時間がわかります。
このページは数値を秒、ミリ秒、マイクロ秒、ナノ秒として同時に読み、実在の日付になる読み方を選んで理由を示し、ほかの読み方にもワンクリックで切り替えられるようにします。答えの下では、同じ数字をWindows、.NET、Mac、Excel、NTP、GPSのタイムスタンプとしても読み、どの形式もコピーできます。

何でも貼り付け任意の単位の数値、ISO形式の日付、メールのDateヘッダー、SQLの日時、「現在」(now)という語。どう読み取ったかは入力欄の表示でわかります。桁を数える数値の下の目盛りが桁を3つずつ区切るので、18桁なら6つのグループになります。それが何かを知る最初の手がかりです。答えが先曜日と日付、続いてUTCとお使いのタイムゾーンでの時刻、そしてコピーできるすべての形式を表示します。どの読み方か、その理由どの読み方を選んだか、なぜそうしたかを言葉で示し、ほかに実在の日付になる読み方があれば、その名前も挙げます。ほかのすべてのエポック同じ数字をすべての単位とエポックで読み、それぞれの起点から伸びるバーで示します。行を選ぶと、その読み方を使います。エポック時間とは? なぜ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です。
1973年4月8日に上限到達 · 2.27年
1901-12-13 → 2038-01-19前後それぞれ68年
負のカウント:1970年より前
UNIX Programmer's Manual 第1版、time (II)、1971年11月3日
年代--志向のユーザーなら、2**32個の60分の1秒が約2.5年にすぎないことに気づくだろう。
このページが読むすべてのエポックを1本の線上に
- 1
.NET
0001-01-01· 100 ns単位のティック - 2
Windows FILETIME
1601-01-01· 100 ns単位のティック - 3
Excel
1899-12-30· 日 - 4NTP
1900-01-01· 秒 - 5
Mac HFS+
1904-01-01· 秒 - 6
Excel 1904
1904-01-01· 日 - 7Unix
1970-01-01· 秒 - 8GPS
1980-01-06· 秒
タイムスタンプの単位は秒・ミリ秒・マイクロ秒・ナノ秒のどれ?
桁数を数えます。現在のタイムスタンプは、秒(エポック秒)なら10桁、ミリ秒なら13桁、マイクロ秒なら16桁、ナノ秒なら19桁です。JavaScriptとJavaはミリ秒、Unixのツールと多くのAPIは秒を使います。
桁数は有力な手がかりですが、証拠ではありません。NTP、GPS、Macのタイムスタンプも現在は10桁で、Windows FILETIMEと.NETのティック数はどちらも18桁です。そのためこのページはすべての尺度を同時に読み、選んだ読み方をほかの読み方と並べて表示します。また、FILETIMEはJavaScriptで正確に保持できる大きさを超えるため、このページは貼り付けた桁をそのまま保持します。
10桁 · 4種類の尺度 · 数字だけではどれか判断できない
18桁 · 2種類の尺度 · 最初の桁だけで区別できる
10桁の秒数は2001-09-09T01:46:40Zから2286-11-20T17:46:39Zまでです。これは285年にわたる範囲で、単位ではありません。
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時間
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 111111112038年1月19日(火)03:14:07 UTC
+ 1秒
-2,147,483,648同じ32ビットを符号付きとして読んだ値
10000000 00000000 00000000 000000001901年12月13日(金)20:45:52 UTC
最後の1秒(UTC)
time_t2038-01-19 03:14:07TIMESTAMP列2038-01-19 03:14:07今日2038-01-19
time_tなら、1970年の前後それぞれ約2923億年まで表せます。 出典:POSIX.1-2024 A.4.19, MySQL 8.4, RFC 5905 §6, TN1150Unixタイムスタンプは負の値になる?
はい。負のタイムスタンプは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から始まり、負の値は保持できない
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-01 | 1792972800 | 10 | UTC(POSIX) | date +%s、Pythonのtime.time() |
| ミリ秒 | 1970-01-01 | 1792972800000 | 13 | UTC | JavaScriptのDate.now()、Java | |
| ナノ秒 | 1970-01-01 | 1792972800000000000 | 19 | UTC | GoのUnixNano() | |
| 100 ns単位のティック | 1601-01-01 | 134374464000000000 | 18 | UTC(FATでは現地時刻) | NTFS、Active DirectoryのlastLogon、Win32 | |
| 100 ns単位のティック | 0001-01-01 | 639285696000000000 | 18 | KindによりUTCまたは現地時刻 | .NETのDateTime.Ticks | |
| 日 | 1899-12-30 | 46321 | 5 | なし:時計の表示 | Excel、Google Sheets、LibreOffice | |
| 日 | 1904-01-01 | 44859 | 5 | なし:時計の表示 | 古いMac版Excel | |
| 秒 | 1904-01-01 | 3875817600 | 10 | GMT(旧HFS:現地時刻) | HFS+のファイルの日付 | |
| NTP秒 | 秒 | 1900-01-01 | 4001961600 | 10 | UTC | NTPパケット |
| GPS秒 | 秒 | 1980-01-06 | 1477008018 | 10 | うるう秒なし:UTC + 18s | GPS受信機、RINEXファイル |
Unix時間はうるう秒を数える?
いいえ。Unix時間は毎日をちょうど86,400秒とするため、うるう秒には固有の数値がありません。POSIXもそう述べています。分解したPOSIX時刻は、見かけに反して必ずしもUTCではありません。
1972年以降、UTCには27回のうるう秒が追加されました。Unix時間にはその余分な1秒に当たる数値がないため、1つのタイムスタンプが2秒分を表します。最後のうるう秒は2016-12-31で、2022年には国際度量衡総会が、うるう秒が必要になる上限を2035年までに引き上げることを決めました。これで事実上、うるう秒は終わります。うるう秒をもともと持たないGPS時刻を見ると、その差がわかります。18秒進んでいます。
1998年12月31日の最後の数秒
Unix時間は915148800を2回使います。うるう秒のないGPS時刻は数え続けます。
うるう秒27回2016年12月31日より後はなし · 2027年6月28日より前の予定なし
GPS時刻の開始前GPS時刻の開始後:1回ごとにGPS時刻が1秒ずつ先行
POSIX.1-2024, Rationale A.4.19
協定世界時(UTC)にはうるう秒が含まれる。しかし、POSIX時刻(エポックからの秒数)では、時間差を簡単かつ互換性のある方法で計算できるように、うるう秒は無視される(適用されない)。したがって、分解されたPOSIX時刻は、見かけに反して必ずしもUTCではない。
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で実行:コメントのとおりに出力されます。
const t = new Date(817876800 * 1000); // Date counts milliseconds console.log(t.toISOString()); // 1995-12-02T04:00:00.000Z const back = Date.UTC(1995, 11, 2, 4, 0, 0) / 1000; // months count from 0 console.log(back); // 817876800
2026年10月26日にNode.js 22.23.2で実行:コメントのとおりに出力されます。
import java.time.Instant;
public class Main {
public static void main(String[] args) {
Instant t = Instant.ofEpochSecond(817876800L);
System.out.println(t); // 1995-12-02T04:00:00Z
long back = Instant.parse("1995-12-02T04:00:00Z").getEpochSecond();
System.out.println(back); // 817876800
}
}2026年10月26日にOpenJDK 25.0.2で実行:コメントのとおりに出力されます。
var t = DateTimeOffset.FromUnixTimeSeconds(817876800); Console.WriteLine(t.ToString("o")); // 1995-12-02T04:00:00.0000000+00:00 var back = new DateTimeOffset(1995, 12, 2, 4, 0, 0, TimeSpan.Zero).ToUnixTimeSeconds(); Console.WriteLine(back); // 817876800
2026年10月26日に.NET 10.0.103で実行:コメントのとおりに出力されます。
package main import ( "fmt" "time" ) func main() { t := time.Unix(817876800, 0).UTC() fmt.Println(t.Format(time.RFC3339)) // 1995-12-02T04:00:00Z back := time.Date(1995, 12, 2, 4, 0, 0, 0, time.UTC).Unix() fmt.Println(back) // 817876800 }
2026年10月26日にGo 1.25.5で実行:コメントのとおりに出力されます。
SET TIME ZONE 'UTC'; SELECT to_timestamp(817876800); -- 1995-12-02 04:00:00+00 SELECT EXTRACT(EPOCH FROM TIMESTAMPTZ '1995-12-02 04:00:00+00')::bigint; -- 817876800
2026年10月26日にPostgreSQL 16.10で実行:コメントのとおりに出力されます。
SET time_zone = '+00:00'; SELECT FROM_UNIXTIME(817876800); -- 1995-12-02 04:00:00 SELECT UNIX_TIMESTAMP('1995-12-02 04:00:00'); -- 817876800
2026年10月26日にMySQL 9.5.0で実行:コメントのとおりに出力されます。
# macOS and the BSDs: -r takes seconds date -u -r 817876800 '+%F %T' # 1995-12-02 04:00:00 date -u -j -f '%F %T' '1995-12-02 04:00:00' +%s # 817876800 # Linux (GNU coreutils): -d @seconds; GNU's -r reads a file's date date -u -d @817876800 '+%F %T' # 1995-12-02 04:00:00 date -u -d '1995-12-02 04:00:00' +%s # 817876800
2026年10月26日にmacOS 26.6とGNU coreutils 9.12のdateコマンドで実行:コメントのとおりに出力されます。
エポック時間:よくある質問
エポック時間とは?
エポック時間(unixtime)を日付に変換するには?
new Date(817876800 * 1000)です。現在のエポック時間は?
date +%sで秒単位で表示できます。Unixタイムスタンプの単位は秒?ミリ秒?
Unix時間はなぜ1970年から始まる?
Unix時間とUTCは同じ? うるう秒はどうなる?
2038年問題とは?
TIMESTAMP列は今もその1秒で終わります。1970年より前の日付も変換できる?
TIMESTAMPは保持できませんが、ほとんどの言語とデータベースは1970年より前の日付として読みます。Windows FILETIMEを日付に変換するには?
Excelの日付シリアル値をタイムスタンプに変換するには?
タイムゾーンや夏時間に対応していますか?
タイムスタンプはどこかに送信されますか?
足りないものはありますか?機能や新しいツールを提案する