UNIX時間 変換｜エポック秒⇔日時を秒・ミリ秒・JST・UTC・ISO 8601で双方向変換
UNIXタイムスタンプ(エポック秒：1970年1月1日 0:00 UTCからの経過秒数)と日時を双方向に変換。秒(10桁)・ミリ秒(13桁)の両方に対応し、JST(日本時間、UTC+9)とUTC(協定世界時)+ISO 8601形式を同時表示。2038年問題(32bit符号付き整数の上限=2,147,483,647秒)、うるう秒(TAI-UTC差)、タイムゾーン(IANA Time Zone Database)、JavaScript/Python/Java/Go/SQL/Excelの実装例まで、POSIX標準・RFC 3339に沿ってプログラマー・データ分析・API開発の実務に対応した無料ツールです。
UNIX時間 変換ツール
UNIX時間の定義と単位系
基本定義
UNIX時間 = 1970-01-01T00:00:00Z(UTC)からの経過秒数
Unix系OS(BSD, Linux, macOS)を起源とする時刻の内部表現。うるう秒を無視した「単調増加する秒数」として、システム時刻・データベース・API・ログ・ファイルシステム(mtime/ctime)などあらゆる場面で使用されます。POSIX標準(IEEE Std 1003.1)で正式定義され、C言語のtime_t型として実装されています。
秒とミリ秒
1 UNIX秒 = 1000 UNIXミリ秒 = 1,000,000 マイクロ秒 = 1,000,000,000 ナノ秒
2026年現在のUNIX秒は10桁(1,700,000,000台)、ミリ秒は13桁。APIレスポンスに数値が返ってきたときは桁数で単位を判別するのが実務セオリー。JavaScript Date.now()・Java System.currentTimeMillis()はミリ秒、C言語 time()・Python time.time()は秒(小数含む)、Go time.Unix()は秒とナノ秒の分離。
符号付き整数の限界(2038年問題)
2^31 - 1 = 2,147,483,647 秒 = 2038-01-19T03:14:07 UTC
32bit符号付き整数(int32_t)で表現可能なUNIX秒の上限。2038年1月19日3時14分7秒(UTC)を超えると、古い32bitシステムでは負の値にオーバーフローし、1901年12月13日に巻き戻る恐れがあります。64bit化(int64_t)により事実上の解消。詳細は2038年問題参照。
関連する派生指標
UNIX時間の派生としてJulian Date(JD、天文学)、Modified Julian Date(MJD、宇宙工学)、NTP時刻(1900年基準、SNTP/RFC 5905)、Windowsファイルタイム(1601年基準・100ns単位)などがあります。詳細換算はJulian Date換算ページを参照してください。
UNIX時間とISO 8601の違い
API・ログ・データベースで頻用される時刻表現は主にUNIX時間とISO 8601の2種類。両者の違いを整理します。
| 項目 | UNIX時間(エポック秒) | ISO 8601(RFC 3339) |
|---|---|---|
| 表現 | 数値(整数) | 文字列(YYYY-MM-DDTHH:MM:SSZ) |
| 例 | 1761868800 | 2025-10-31T00:00:00Z |
| 可読性 | 低(数値のみ) | 高(人間が読める) |
| タイムゾーン | 常にUTC(暗黙) | 明示(Z, +09:00等) |
| ソート | 数値ソートで時系列 | 文字列ソートで時系列 |
| ストレージ | 4-8バイト(整数) | 20-25バイト(文字列) |
| 用途 | DB・ログ・内部計算 | API・設定ファイル・人間向け |
| 典型例 | Linuxのfile timestamp | JSON API・XML SOAP |
実務では両者を用途で使い分けます。REST API・JSON APIのレスポンスはISO 8601が標準(RFC 7519 JWTのexpクレームだけは例外的にUNIX秒)、内部処理・DBの主キーソート・パフォーマンス重視の場面ではUNIX秒を採用するケースが多く見られます。
主要時刻のUNIX時間一覧
覚えておくと便利な代表的な時刻のUNIX秒値です。
| イベント | UNIX秒 | JST日時 |
|---|---|---|
| 1970年1月1日(エポック) | 0 | 1970-01-01 09:00 |
| 1971年1月1日 | 31536000 | 1971-01-01 09:00 |
| 1980年1月1日 | 315532800 | 1980-01-01 09:00 |
| 1990年1月1日 | 631152000 | 1990-01-01 09:00 |
| 2000年1月1日(Y2K) | 946684800 | 2000-01-01 09:00 |
| 2010年1月1日 | 1262304000 | 2010-01-01 09:00 |
| 2020年1月1日 | 1577836800 | 2020-01-01 09:00 |
| 2025年1月1日 | 1735689600 | 2025-01-01 09:00 |
| 2026年1月1日 | 1767225600 | 2026-01-01 09:00 |
| 2030年1月1日 | 1893456000 | 2030-01-01 09:00 |
| 2038年問題(32bit限界) | 2147483647 | 2038-01-19 12:14 |
| 2100年1月1日 | 4102444800 | 2100-01-01 09:00 |
| 3000年1月1日 | 32503680000 | 3000-01-01 09:00 |
言語別 UNIX時間の取得・変換
主要プログラミング言語での取得方法とタイムスタンプの単位です。
| 言語 | 取得コード | 単位 |
|---|---|---|
| JavaScript | Math.floor(Date.now()/1000) | 秒(Date.now()自体はミリ秒) |
| Python | int(time.time()) | 秒(小数含む) |
| Java | System.currentTimeMillis()/1000L | ミリ秒→秒 |
| Go | time.Now().Unix() | 秒(UnixNanoで nanosec) |
| PHP | time() | 秒 |
| Ruby | Time.now.to_i | 秒 |
| C/C++ | time(NULL)(time.h) | 秒(time_t型) |
| C# | DateTimeOffset.Now.ToUnixTimeSeconds() | 秒(ミリ秒版もあり) |
| Rust | SystemTime::now().duration_since(UNIX_EPOCH) | 秒+nanos |
| MySQL/MariaDB | UNIX_TIMESTAMP() | 秒 |
| PostgreSQL | EXTRACT(EPOCH FROM NOW())::bigint | 秒 |
| Excel/GoogleSheets | =(NOW()-DATE(1970,1,1))*86400 | 秒(TZ調整必要) |
| Shell(Linux) | date +%s | 秒 |
2038年問題と64bit化対応
問題の本質
C言語のtime_t型が32bit符号付き整数として実装されていた古いUNIX/POSIXシステムでは、2038年1月19日 03:14:07 UTC(=UNIX秒 2,147,483,647)を1秒でも過ぎると値がオーバーフローし、1901年12月13日 20:45:52に巻き戻る現象が発生します。
影響範囲
- 組み込み機器(車載・産業制御): 32bit MCU、リアルタイムOS(FreeRTOS等)の一部で残存
- 古いスマホ・タブレット: iOS 10以前・Android 5以前で潜在リスク
- 古いファイルシステム: ext3・FAT32のタイムスタンプ、SSL証明書の有効期限
- データベース: MySQLの
TIMESTAMP型は2038年上限(DATETIME型は9999年まで)
対策
NetBSD 6.0(2012)、OpenBSD 5.5(2014)、Linux 5.6(2020)以降はtime_tを64bit化。64bit符号付き整数(int64_t)なら約2,920億年までカバー可能で事実上の解消。現代のJava(long)・Go(int64)・Python 3・JavaScript(64bit浮動小数点)は最初から64bit相当のため問題なし。
データベースの2038対応
MySQL TIMESTAMP型は依然として32bit(2038年上限)。長期保存が必要な場合はDATETIME型(9999年まで)を選択します。PostgreSQL timestamp型・SQL Server datetime2型は最初から64bit相当で問題なし。
うるう秒とTAI-UTC差
うるう秒(Leap Second)
地球の自転は潮汐摩擦で徐々に遅くなっており、原子時計に基づくUTC(協定世界時)との差が0.9秒を超えた際に、国際地球回転・基準系事業(IERS)の判断で6月末または12月末に「うるう秒」を挿入します。1972年〜2016年で27回挿入され、2017年1月1日以降は挿入なしで停止傾向。
UNIX時間はうるう秒を無視
POSIX仕様上、UNIX時間は1日=86,400秒固定とし、うるう秒を計上しません。そのため厳密にはTAI(国際原子時)とUNIX時間の差は約27秒(2026年時点)。金融取引・GPS測位・宇宙工学などミリ秒未満の精度が必要な用途では別途TAI管理が必要です。
Google/AWSのSmear方式
Google Public NTP・AWS Time SyncはSmear(スミア、平滑化)方式を採用し、うるう秒を24時間かけて徐々に挿入することで、瞬間的な時刻ジャンプを回避しています。金融・データベース分野で「うるう秒でシステム障害」を避けるための業界共通実装。
2035年 うるう秒廃止決議
2022年の国際度量衡総会(CGPM)で、うるう秒を2035年までに廃止する方針が決議されました。今後は「うるう分」「うるう時」など長期間隔での調整に移行する可能性があり、時刻管理システムの改修が予想されます。
タイムゾーン(IANA Time Zone Database)
IANA TZデータベース
IANA Time Zone Database(tz database, zoneinfo)は世界中のタイムゾーン・夏時間ルールを集約したデータベース。Linux・macOS・Java・Python・PostgreSQLなど主要OS/言語が採用する事実上の標準です。Asia/Tokyo(JST=UTC+9)、America/New_York(EST=UTC-5)など「地域/都市」形式で識別します。
日本標準時(JST)の歴史
- 1888年1月1日から明石市の東経135度を基準とするJST(UTC+9)採用
- 1948-1951年の3年間のみ夏時間(サマータイム)実施
- 2017年以降は夏時間なし、恒常的にUTC+9
- 2020年五輪招致時に夏時間再導入の議論があったが未実現
コード例(JavaScript)
// UTC→JST変換
const utcSec = 1761868800;
const jst = new Date(utcSec * 1000);
// toLocaleString('ja-JP', {timeZone: 'Asia/Tokyo'})
console.log(jst.toLocaleString('ja-JP', {timeZone: 'Asia/Tokyo'}));
// → 2025/10/31 09:00:00
コード例(Python)
from datetime import datetime, timezone
from zoneinfo import ZoneInfo # Python 3.9+
dt = datetime.fromtimestamp(1761868800, tz=ZoneInfo('Asia/Tokyo'))
print(dt.isoformat())
# → 2025-10-31T09:00:00+09:00
業界での応用
Web API・マイクロサービス開発
REST API・JSON APIのタイムスタンプ表現、JWT(JSON Web Token)のexp/iatクレーム、Webhookイベントの発生時刻管理。RFC 7519・OAuth 2.0仕様書でUNIX秒が明示指定されています。国境をまたぐSaaSではUTC統一が必須。
データベース・ログ管理
ソート・比較・範囲検索の高速化(数値インデックス活用)、時系列DBでの効率的なストレージ、ログ集約(fluentd, Logstash, Datadog)のイベントタイムスタンプ。MySQL UNIX_TIMESTAMP()、PostgreSQL EXTRACT(EPOCH FROM ...)で相互変換。
金融取引・ブロックチェーン
高頻度取引(HFT)のタイムスタンプ、ビットコイン/イーサリアムのブロック生成時刻、スマートコントラクトの有効期限管理。金融庁・SECの取引記録保存要件でナノ秒精度のタイムスタンプが求められることも。
IoT・センサーデータ
センサーの計測時刻管理(MQTT・LoRaWANのペイロード)、時系列データベース(InfluxDB, TimescaleDB)への投入、機械学習用データセットのラベリング。組み込み機器の2038年対応は残存課題。
ゲーム開発・イベント管理
ゲーム内イベントの開始・終了時刻、サーバー時刻の同期(NTP)、プレイヤーの最終ログイン時刻管理、日次ログインボーナスのリセットタイマー。オンラインゲームでは全ユーザー共通のUTC基準運用が標準。
データ分析・BI
Tableau・Power BI・Looker等のBIツールでの時系列可視化、Google BigQuery/SnowflakeのUNIX_SECONDS()関数、pandas pd.to_datetime(unit='s')でのデータフレーム変換、A/Bテスト結果のコホート分析。
よくある間違い・注意点
- 秒とミリ秒の混同 ― JavaScript
Date.now()はミリ秒(13桁)、C言語time()は秒(10桁)。APIレスポンスをそのままnew Date(ts)に渡すと1000倍/1000分の1のズレが発生。桁数チェックを実装するのが実務セオリー。 - タイムゾーンの誤解 ― UNIX時間は常にUTC基準。JSTと勘違いして9時間ズレたまま運用するケースが頻発。APIレスポンスに
Z(Zulu Time = UTC)が付いていることを常に確認。 - MySQL TIMESTAMP型の2038年上限 ―
TIMESTAMP型は32bit(2038年上限)。長期保存が必要ならDATETIME型(9999年)を採用。SNSの投稿時刻や決済ログでは要注意です。 - Excelのシリアル値との混同 ― Excelの日付シリアル値は1900年1月1日=1で始まりUNIX時間とは異なる基準日。相互変換は
=(A1-DATE(1970,1,1))*86400のような式が必要。 - うるう秒の処理漏れ ― POSIX仕様上UNIX時間はうるう秒を無視。金融・宇宙工学などミリ秒精度が必要な用途では別途TAI管理が必要。Google/AWSはSmear方式で回避。
- 負の値の扱い ― 1970年より前はUNIX秒が負の値になります。
time_tを符号無し整数として扱うと1970-1901年の日付が正しく処理されません。歴史データを扱う場合は要注意。 - Y2038問題を先送り ― 32bit組込機器の2038年対応は未解決の分野。20年後に稼働している家電・車載機器のファームウェア対応計画が必要です。
関連する規格・実務基準
- POSIX(IEEE Std 1003.1-2017) ― UNIX時間の正式定義。
time_t型・time()関数・gmtime()・localtime()の仕様。 - RFC 3339 ― ISO 8601をインターネットプロトコル用に簡略化した仕様。JSON API・Atom Feed・XMLの日付表現の標準。
- ISO 8601:2019 ― 国際標準の日付・時刻表現。YYYY-MM-DDTHH:MM:SS±HH:MM形式。
- RFC 5905(NTPv4) ― Network Time Protocolの仕様。1900年基準の64bit時刻表現(整数部32bit秒+小数部32bit)。
- RFC 7519(JWT) ― JSON Web Tokenの仕様。
exp・iat・nbfクレームでUNIX秒を明示指定。 - IANA Time Zone Database ― 世界のタイムゾーン・DST(夏時間)ルールの標準データベース(zoneinfo)。
- IERS Bulletin C ― うるう秒挿入の公式アナウンス。国際地球回転・基準系事業(IERS)発行。
- CGPM(国際度量衡総会) ― 2022年うるう秒廃止決議。2035年までに移行予定。
参考文献・公的資料
より詳細なUNIX時間・タイムゾーン・時刻同期の仕様は、以下の公的機関・標準化団体の資料を参照してください。
- The Open Group POSIX仕様 ― UNIX時間・エポック秒の公式定義。IEEE Std 1003.1-2017準拠。
- IETF RFC 3339 ― インターネット上の日付・時刻表現仕様。ISO 8601のプロファイル。
- IETF RFC 7519(JWT) ― JSON Web Tokenの仕様書。UNIX秒での有効期限指定。
- IANA Time Zone Database ― 世界タイムゾーンデータベースの公式頒布元。Asia/Tokyo等のTZID定義。
- IERS(国際地球回転・基準系事業) ― うるう秒挿入の公式アナウンス(Bulletin C)。
- 情報通信研究機構(NICT) 日本標準時 ― 日本標準時(JST)の維持機関。原子時計による時刻標準供給。
- NICT うるう秒解説 ― うるう秒挿入の歴史と2035年廃止決議の解説。
- 国際度量衡局(BIPM) ― TAI(国際原子時)・UTCの維持機関。2022年うるう秒廃止決議の主体。
- Google Public NTP ― Google Smear方式うるう秒処理の公式解説。
- AWS Time Sync Service ― AWSのNTPサービスとうるう秒処理仕様。
よくある質問（FAQ）
秒とミリ秒の違いは?
秒は10桁(2026年時点 1,700,000,000台)、ミリ秒は13桁。JavaScript Date.now()・Java System.currentTimeMillis()はミリ秒、C言語 time()・Python time.time()は秒。API連携ではレスポンスの桁数で判別するのが実務セオリーです。
2038年問題とは?
32bit符号付き整数で表現可能なUNIX秒の上限が2,147,483,647(2038年1月19日 03:14:07 UTC)。それを超えると負の値にオーバーフローし1901年12月13日に巻き戻る恐れがあります。64bit化により大半のシステムでは解消済ですが、32bit組込機器・古いスマホ・MySQLのTIMESTAMP型では未解決課題として残ります。
JavaScriptで現在のUNIX秒を取得?
Math.floor(Date.now() / 1000)でミリ秒→秒に変換。Date.now()自体はミリ秒単位(13桁)なので、秒に変換したい場合は必ず1000で割ります。ISO 8601形式が欲しければnew Date().toISOString()。
Excelで変換するには?
UNIX秒→日時: =A1/86400 + DATE(1970,1,1)(日付セル形式)。日時→UNIX秒: =(A1 - DATE(1970,1,1)) * 86400。ExcelはUTC非対応なので、JST変換なら+9時間の調整が別途必要。Google Sheetsでも同じ式で動作します。
うるう秒は考慮される?
UNIX時間はうるう秒を無視する仕様(POSIX準拠)のため、厳密にはTAI(国際原子時)と数十秒のズレがあります(2026年時点で約27秒)。金融取引・GPS測位・宇宙工学以外の日常用途では誤差レベルで問題ありません。Google/AWSはSmear方式で瞬間的なジャンプを回避しています。
Pythonで変換するには?
現在のUNIX秒: int(time.time())。UNIX秒→datetime(JST): datetime.fromtimestamp(1761868800, tz=ZoneInfo('Asia/Tokyo')) (Python 3.9+)。datetime→UNIX秒: int(dt.timestamp())。ZoneInfoはPython 3.9からの標準ライブラリで、pytzより推奨されます。
MySQLで変換するには?
UNIX秒→datetime: FROM_UNIXTIME(1761868800)。datetime→UNIX秒: UNIX_TIMESTAMP('2025-10-31 09:00:00')。ただしTIMESTAMP型は2038年上限のため、長期保存はDATETIME型を推奨。
ISO 8601とRFC 3339の違いは?
RFC 3339はISO 8601のインターネットプロトコル向けサブセットで、より厳密な形式を規定しています。基本的にRFC 3339形式(YYYY-MM-DDTHH:MM:SSZやYYYY-MM-DDTHH:MM:SS+09:00)がJSON API・Atom Feed・XMLで採用される標準。ISO 8601は略記形式(20250101T120000)も許容していますが、RFC 3339はハイフン・コロン必須です。
タイムゾーンはどう扱う?
UNIX時間は常にUTC基準で、タイムゾーンは表示時のみ考慮します。IANA Time Zone Database(Asia/Tokyo, America/New_York等)を使用するのが業界標準。JavaScript Intl.DateTimeFormat・Python ZoneInfo・Java ZoneIdで対応可能です。
2038年以降はどうなる?
64bit環境なら約2,920億年まで扱えるため事実上の解消。ただし2038年時点で32bit組込機器(車載ECU・産業制御・古い家電のファーム)が稼働している可能性があり、業界別で対応が進行中です。SSL証明書・データベースのTIMESTAMP型・古いファイルシステムも要注意領域。
負のUNIX時間はある?
あります。1970年1月1日より前の日時は負のUNIX秒で表現されます(例: 1969年12月31日 = -86400)。歴史データや古い書類の日付を扱う場合、time_tを符号付きとして扱うシステムが対応可能。C言語標準では未定義動作の可能性もあるため、実装依存の挙動に注意。
NTP時刻とUNIX時間の違いは?
NTP(Network Time Protocol、RFC 5905)は1900年1月1日基準の64bit時刻(整数部32bit秒+小数部32bit)で、UNIX時間(1970年基準)とは2,208,988,800秒の差があります。NTP秒 = UNIX秒 + 2,208,988,800。NTPも2036年に整数部32bitがオーバーフローする「Y2036問題」を抱えていますが、NTPv4では巡回検出でエポックを跨いで動作可能です。