Unixタイムスタンプ タイムスタンプの変換方法とその普及理由

Unixタイムスタンプは、1970年1月1日00:00:00 UTCからの秒数を表します — これもUnixエポックと呼ばれます。その日時は技術的な理由ではなく、Unixが設計されていた当時の現在の年を指しています。エポックは常にUTCで、たとえば 1712800000 世界中のどこでも同じ時刻を意味します。

Unixタイムスタンプはあらゆる場面で使用されています：HTTPヘッダー、JWTトークン、データベース記録、ログファイル、メッセージキュー、APIレスポンスなどです。時間に関わる開発やデバッグをしている場合、頻繁にこのタイムスタンプに出会うことになります。そして IO Tools Unixタイムスタンプコンバーター は迅速な確認に便利ですが、コード内で扱う方法も理解しておく必要があります。

秒とミリ秒：誰もが遭遇するバグ

生産環境で最も一般的なタイムスタンプのバグは、秒とミリ秒を混同することです。Unix標準では 秒を使用します。JavaScriptの Date.now() は ミリ秒を返します。Javaの System.currentTimeMillis().

も同様です。タイムスタンプが 1712800000 であれば、2024年4月です。タイムスタンプが 1712800000000 (ミリ秒)であれば、5万年頃になります。もし日付計算が数十年後の日付を生成したり、表示が 1970-01-01となっている場合、これはほぼ必ずこの原因です。

ルール：タイムスタンプが13桁ならミリ秒、10桁なら秒です。不安な場合は1000で割って、結果が意味があるか確認してください。

言語によるUnixタイムスタンプの変換

実際に使うパターンは次の通りです：

JavaScript

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

パイソン

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

SQL（MySQL / MariaDB）

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

クイックリファレンステーブル

タイムゾーンの罠

Unixタイムスタンプは常にUTCです。常にです。数値 1712800000 はタイムゾーンを持ちません — ただエポックからの秒数を数えています。タイムゾーンは表示上の問題であり、保存上の問題ではありません。

開発者が被害を受ける場面：

• Pythonの datetime.fromtimestamp(ts) without tz=timezone.utc — サーバーのローカルタイムゾーンを使用し、静かに動作します。代わりに fromtimestamp(ts, tz=timezone.utc) その代わり。
• MySQLの FROM_UNIXTIME() — MySQLサーバーのタイムゾーン設定（@@session.time_zone）に変換されます。サーバーがUTC+8なら、結果は8時間ずれてしまいます。
• MySQLに datetime を保存しない場合 — アプリサーバーとデータベースサーバーが異なるタイムゾーンにある場合、すべての挿入・読み取りがバグの可能性をもっています。

すべての問題を回避するためのパターンは、データベースにUnixタイムスタンプを保存し、アプリ層で表示時にユーザーの好むタイムゾーンに変換することです。

タイムスタンプとISO 8601文字列：保存すべきものは何か

どちらも有効な保存形式です。利害のバランスは次の通りです：

• Unixタイムスタンプ（整数）：コンパクトで、比較や算術に速く、タイムゾーンの曖昧さがなく、すべてのデータベースエンジンで動作します。デメリットは、ツールを使わなければ人間が読み取れません。
• ISO 8601文字列 (例： 2024-04-11T02:13:20Z)：データベース内で人間が読みやすい、自己説明的です。デメリットは、範囲クエリに遅いこと、タイムゾーンが誤って省略されたり間違えられる可能性があります。

ほとんどのアプリケーションでは、タイムスタンプを整数として保存します。人間が読みやすい場面ではAPIやログにISO 8601を使用します。もしISO 8601を保存しなければ、常にタイムゾーン Z または明示的なオフセットを含めるべきです — タイムゾーンが記載されていない場合、分散システムでは災害になります。 2024-04-11 02:13:20 タイムゾーンが指定されていないことは分散システムにおいて大災害である。

2038問題

32ビット符号付き整数は最大値 2147483647を保持できます。これはUTCで1970年1月1日03:14:07に相当します。タイムスタンプを32ビット int で保存するシステムはその時点でオーバーフローし、1901年に戻ったり、クラッシュします。

心配すべきですか？新しいコードを書いているなら、いいえ — 64ビット整数を使用してください。古いCコード、埋め込みファームウェア、または古いMySQLスキーマで INT(11) を使用している場合は、確認が必要です。MySQLの TIMESTAMP タイプにも影響があります。 DATETIME は影響しません。現代のシステムが64ビットタイムスタンプを使用している場合、2920億年まで安全です。

コードを書くことなく、タイムスタンプを迅速に変換したいですか？ IO ToolsのUnixタイムスタンプコンバーター は秒とミリ秒をサポートし、UTCとローカルタイムを並べて表示し、日付を貼り付けることでタイムスタンプを取得できます。

あなたも好きかもしれません

新しい

Color Accessibility for Developers: Contrast, Blindness Simulation, and Fixing Issues

続きを読む "

掲載日 5月 7, 2026

新しい

WebP vs AVIF vs PNG vs JPEG: Choosing Image Formats for the Web

続きを読む "

掲載日 5月 6, 2026

新しい

chmod計算機： オクタル数を覚えることなくUnixファイルの権限

続きを読む "

掲載日 2026年5月5日

新しい

Gitなしテキスト差分： ファイルと文字列の変更を確認

続きを読む "

掲載日 2026年5月4日