「このログ、結局いつのこと？」

システム開発中、コンソールに吐き出された 1736823600 という数字。
「ああ、これは UNIX タイムだね」と理解はしても、具体的にそれが何月何日の何時なのか、パッと答えられる人はまずいません。

UNIX時間とは？秒・ミリ秒の違いと日時変換の基本

ログ調査やデータベースの確認、API のデバッグ……。エンジニアの日常は、この「人間には読みづらいけれど、コンピューターには都合がいい数字」との戦いでもあります。

UNIX タイム：世界を繋ぐ「秒数」

UNIX タイム（エポック秒）は、1970年1月1日 00:00:00 UTC からの積み重ねです。

そもそも、なぜこんな読みづらいものを使うのでしょうか？
それは、世界中に散らばるコンピューターたちが、「今、この瞬間」を正しく共有するためです。
「日本の 9 時」は「イギリスの 0 時」ですが、UNIX タイムなら世界中どこでも同じ一つの数値。このシンプルさがあるからこそ、私たちは地球の裏側のサーバーとも同期してデータをやり取りできるのです。

開発現場でよくある「3つの罠」

仕組みを知っていても、私たちはつい「うっかり」ミスをしてしまいます。

1. 「秒」と「ミリ秒」の混同

JavaScript の Date.now() は 13 桁（ミリ秒）、PHP や Python の標準は 10 桁（秒）。
「API を叩いたら、1970 年の日付になっちゃった！」というのは、多くの場合この桁数の違いに気づいていないことが原因です。

2. タイムゾーンの壁

UNIX タイムは常に UTC（協定世界時）ですが、私たちの生活は JST（日本標準時）です。
「9 時間のズレ」を考慮し忘れて、深夜に動くはずのバッチ処理がお昼に暴走してしまった……なんて失敗、ありませんか？

3. 「2038 年」という期限

遠い未来の話と思っていましたが、少しずつ近づいています。古いシステムを触る機会があれば、「この変数、2038 年で溢れないかな？」という視点を持つことが、未来のあなた（あるいは後任者）を救うかもしれません。

UNIX時間を日時に変換する手順

ログやAPIレスポンスにあるUNIX時間を読むときは、まず桁数を確認します。
10桁なら秒、13桁ならミリ秒であることが多いです。

  1. 変換したい数値をコピーする。
  2. UNIXタイム変換ツール に貼り付ける。
  3. 秒かミリ秒かを確認する。
  4. UTCとJSTの日時を見比べる。
  5. ログ、DB、APIのタイムゾーン仕様と一致しているか確認する。

たとえば 1736823600 は10桁なので、秒のUNIXタイムとして扱います。
一方で 1736823600000 は13桁なので、JavaScriptなどでよく使われるミリ秒のタイムスタンプです。
この違いを間違えると、まったく別の日時として表示されます。

秒とミリ秒の見分け方

開発中に出てくるタイムスタンプは、言語やAPIによって単位が違います。
よくある目安は次の通りです。

種類桁数の目安よく出る場所
秒10桁UNIX系コマンド、PHP、Pythonの一部API
ミリ秒13桁JavaScriptの Date.now()、フロントエンドのログ
ISO 8601文字列REST API、JSONログ、DBの日時カラム

桁数だけで完全に判断できるわけではありませんが、最初の切り分けとしてはかなり有効です。
不安な場合は、変換結果が現在時刻や期待する期間に近いかを確認してください。

障害調査での使い方

UNIX時間の変換は、障害調査でもよく使います。
たとえば「ユーザーがエラーを見た時刻」と「サーバーログの時刻」がずれているときは、次の順番で確認すると原因を絞りやすくなります。

  • フロントエンドの時刻がミリ秒か秒か
  • サーバーログがUTCかJSTか
  • DBに保存されている日時のタイムゾーン
  • バッチやCronの実行タイムゾーン
  • 監視ツールの表示タイムゾーン

同じ出来事を見ているはずなのに時刻が合わない場合、単位とタイムゾーンのどちらかがずれていることが多いです。

言語別のUNIX時間の扱い方

主要言語でのUNIX時間の変換コードをまとめます。

// JavaScript / TypeScript
const nowMs = Date.now();                 // ミリ秒
const nowSec = Math.floor(nowMs / 1000);  // 秒

// UNIX秒 → Date（必ず1000を掛ける）
const date = new Date(1736823600 * 1000);
console.log(date.toISOString());          // "2026-01-14T09:00:00.000Z"

// タイムゾーンを考慮した整形
const fmt = new Intl.DateTimeFormat('ja-JP', {
  timeZone: 'Asia/Tokyo', dateStyle: 'full', timeStyle: 'long',
});
console.log(fmt.format(date));            // "2026年1月14日水曜日 18:00:00 JST"
# Python
import time
from datetime import datetime, timezone, timedelta

ts = 1736823600
dt_utc = datetime.fromtimestamp(ts, tz=timezone.utc)
jst = timezone(timedelta(hours=9))
print(dt_utc.astimezone(jst).isoformat())  # 2026-01-14T18:00:00+09:00
// Go
import "time"
ts := int64(1736823600)
jst, _ := time.LoadLocation("Asia/Tokyo")
t := time.Unix(ts, 0).In(jst)
fmt.Println(t.Format(time.RFC3339))        // 2026-01-14T18:00:00+09:00
-- PostgreSQL
SELECT to_timestamp(1736823600);           -- 2026-01-14 09:00:00+00
-- MySQL
SELECT FROM_UNIXTIME(1736823600);          -- 2026-01-14 09:00:00

タイムゾーンと保存形式の鉄則

データベースには、オフセット付きでないローカル時刻を保存してはいけません。"2026-01-14 09:00:00" という値は、日本の9時（UTC 0時）なのかニューヨークの9時（UTC 14時）なのか曖昧です。

原則：UNIX秒（またはPostgreSQLの TIMESTAMP WITH TIME ZONE）で保存し、表示するときだけローカル時刻に変換する。 主要なオフセットは次のとおりです。

地域標準オフセット夏時間
UTC+00:00—
JST（日本）+09:00なし
KST（韓国）+09:00なし
EST（米国東部）−05:00−04:00
CET（中欧）+01:00+02:00

日本・韓国・中国は夏時間（DST）を採用していないため、東アジア向けのシステムでは時刻の扱いがかなり単純になります。

「2038年問題」とは

UNIX時間は 32ビット符号付き整数 で保存されることが多く、その最大値 2,147,483,647 は次の時刻に対応します。

2038年1月19日 03:14:07 UTC

この瞬間を過ぎると32ビットのカウンターがオーバーフローし、日付が1901年12月13日として表示されてしまいます。これが 2038年問題（Y2K38） です。影響を受けやすいのは、組み込みシステム、time_t を int32_t として扱う古いC言語コード、INT(11) で日時を保存している古いDBスキーマなどです。

対策は 64ビット整数で保存する こと。現代の言語やDB（Python の datetime、Go の time.Time、JavaScript の Date、PostgreSQL の TIMESTAMP）は既に64ビットで安全です。リスクはレガシーCコードや一部の組み込み環境に残っています。

迷ったときの「翻訳機」を、手元に

複雑な計算や変換は、無理に頭でやろうとせず、道具に任せてしまいましょう。

当サイトの UNIXタイム変換ツール は、数値を貼り付けるだけで、それが「秒」なのか「ミリ秒」なのかを自動で判別し、UTC とローカル時刻の両方に一瞬で翻訳します。

API 仕様の確認や、障害調査の真っ只中。
慌ただしい時間にこそ、このツールをあなたの「時間を読み解くレンズ」として活用してください。

よくある質問

UNIX時間はUTCですか？

はい。UNIX時間はUTCを基準にした経過秒数です。
JSTで表示するときは、表示側でUTCから日本時間へ変換します。

JavaScriptのタイムスタンプは秒ですか？

Date.now() はミリ秒です。
一般的なUNIX時間の秒として扱いたい場合は、Math.floor(Date.now() / 1000) のように1000で割ります。

1970年の日付になってしまうのはなぜですか？

秒とミリ秒の単位を間違えている可能性があります。
13桁のミリ秒を秒として扱ったり、10桁の秒をミリ秒として扱ったりすると、期待と大きく違う日時になります。

まとめ

UNIX タイムは、見慣れると愛着の湧く、実はとても公平で合理的な仕組みです。
数字の向こう側にある「時間」を自在に操れるようになれば、エンジニアとしての視界はもっと広く、クリアになります。さあ、時間を味方につけて、もっと楽しい開発を！