ログ・データベース・API を扱ったことがあれば、1700000000 のような数値が日付を表しているのを見たはずです。それが Unix タイムスタンプで、これを理解すると時刻関連のバグを丸ごと一つ減らせます。全体像を押さえましょう。
同じ瞬間、2 つの答え。 タイムスタンプ変換に
1700000000を入れると、2 行が同時に返ります。Local: 2023-11-15 06:13:20 UTC: 2023-11-14 22:13:20日付が違う点に注目してください。この瞬間は UTC では 11 月 14 日、UTC+8 では 11 月 15 日です。意図的に並べて表示しています。タイムスタンプの不具合はほぼ例外なく「ローカル表示を見て UTC だと思い込む」ことから生じるからです。10 桁は秒、13 桁はミリ秒。秒として読む処理にミリ秒を渡すと、西暦 55839 年に着きます。
Unix タイムスタンプとは?
Unix タイムスタンプは、Unix エポック(1970 年 1 月 1 日 00:00:00 UTC)からの経過秒数です。UTC の固定点から数えるため、タイムゾーンに関係なく地球上のどこでも同じ意味を持つ単一の絶対値になります。
まさにこの性質ゆえにシステムは好んで使います。異なる国の 2 台のサーバーが、タイムゾーン計算なしで直接タイムスタンプを比較できるのです。
秒 vs ミリ秒
これが混乱の第一原因です。プラットフォームごとに単位が異なります:
- 秒 — 10 桁の数値、例
1700000000。Unix ツール、データベース、多くの API で一般的。 - ミリ秒 — 13 桁の数値、例
1700000000000。JavaScript のDate.now()はこれを返します。
覚え方:10 桁は秒、13 桁はミリ秒。変換した日付が 1970 年付近になったら、秒のところにミリ秒を(あるいはその逆を)渡した可能性が高いです。当サイトのタイムスタンプ変換ツールは桁数から単位を自動判定するので、迷う必要はありません。
タイムゾーンと UTC
タイムスタンプ自体にはタイムゾーンがありません——絶対的な瞬間です。タイムゾーンは表示するときにだけ意味を持ちます。同じタイムスタンプ 1700000000 は:
- UTC では
2023-11-14 22:13:20 - UTC+9(東京)では
2023-11-15 07:13:20
どちらも同じ瞬間を、異なるタイムゾーンで示したものです。デバッグ時は表示中の時刻がどのタイムゾーンかを必ず確認しましょう。当ツールはミスを防ぐためローカル時刻と UTC を並べて表示します。
同じタイムスタンプの組を私たちのタイムスタンプ変換ツールに通した結果です。この表を作った端末は UTC+8 設定なので、ローカル時刻はすべて UTC より 8 時間先を示します。その差こそ 2 行を同時に出す理由です。
| タイムスタンプ | 変換ツールの表示 |
|---|---|
0 | ローカル時刻:1970-01-01 08:00:00 UTC:1970-01-01 00:00:00 |
1000000000 | ローカル時刻:2001-09-09 09:46:40 UTC:2001-09-09 01:46:40 |
1700000000 | ローカル時刻:2023-11-15 06:13:20 UTC:2023-11-14 22:13:20 |
1767225600 | ローカル時刻:2026-01-01 08:00:00 UTC:2026-01-01 00:00:00 |
2147483647 | ローカル時刻:2038-01-19 11:14:07 UTC:2038-01-19 03:14:07 |
2147483648 | ローカル時刻:2038-01-19 11:14:08 UTC:2038-01-19 03:14:08 |
コードでの変換
たいていの言語で変換は簡単です:
// JavaScript(ミリ秒)
const now = Date.now(); // 1700000000000
const date = new Date(1700000000000); // Date オブジェクト
const seconds = Math.floor(Date.now() / 1000);# Python(秒)
import time
now = int(time.time()) # 1700000000
from datetime import datetime, timezone
dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)JavaScript がミリ秒で動くのに対し、Python の time.time() は秒を返す点に注目してください——これも単位を混同しないための理由です。
2038 年問題(簡単に)
タイムスタンプを符号付き 32 ビット整数で保存するシステムは、2038 年 1 月 19 日にオーバーフローします。現代のシステムは 64 ビット整数を使い、上限を数千億年先まで押し出すため、今日ではほとんど問題になりません——ただ、なぜ 64 ビット時刻があるのかは知っておく価値があります。
最後の 2 行が 2038 年の境界です。2147483647 は ローカル時刻:2038-01-19 11:14:07 UTC:2038-01-19 03:14:07。1 秒足すと変換ツールは ローカル時刻:2038-01-19 11:14:08 UTC:2038-01-19 03:14:08 を何の文句もなく返します。ここは正確に理解する価値があります。算術は問題ないのです。JavaScript は値を倍精度で保持しているからです。2038 年問題は算術の話ではなく格納の話 —— 符号付き 32 ビット整数に 2147483648 は入りません。その列を int として読むものはすべて負数に回り込み、1901 年に着地します。
クイック変換
タイムスタンプを今すぐ確認したいですか?無料の Unix タイムスタンプ変換ツールに貼り付ければ、ローカルと UTC の日付を即表示し、日付からタイムスタンプへの逆変換や、現在のタイムスタンプのコピーができます。ブラウザで動作し、通信は不要です。