Unix タイムスタンプの使い方
Unix タイムスタンプとは、1970 年 1 月 1 日 00:00:00 UTC からある時点までに経過した秒数のことです。うるう秒は含みません。整数ひとつで一瞬を正確に指し示せ、タイムゾーンや日付書式に左右されないため、コンピュータの世界で最も広く使われている時刻の表し方です。
秒とミリ秒の 2 種類がある理由
古いシステム（Unix、PHP や Python の time()、MySQL の UNIX_TIMESTAMP()）は秒単位なので 10 桁の数字になります。一方 JavaScript の Date.now()、Java の System.currentTimeMillis()、そして多くのモバイル／フロントエンドフレームワークはミリ秒単位なので 13 桁です。
この 2 つを取り違えるのが開発でいちばんよくあるバグの元です。13 桁のミリ秒値を秒としてサーバーに渡すと日付は数万年先に飛び、10 桁の秒値をミリ秒として渡すと 1970 年に戻ります。本ツールは桁数から自動判別し、両方の単位の結果を並べて出すので、この罠を踏まずに済みます。
タイムスタンプとタイムゾーンの関係
ここが肝心です。タイムスタンプ自体にタイムゾーンはありません。 絶対的な時点を表す値なので、世界のどこで同じ値を見ても同じ瞬間を指します。タイムゾーンが関わるのは「タイムスタンプを人が読める日付文字列に変換する」段階だけです。
つまり同じ 1750000000 が、UTC+8 ではある日の午後、UTC ではその日のより早い時刻、ニューヨークでは前日になりますが、時間軸上では同じ 1 点です。本ツールは UTC・北京時間（UTC+8）・お使いのローカル時刻の 3 つの視点を同時に出すので、タイムゾーンをまたぐ調査が楽になります。
よくある利用シーン
- API のデバッグ：
createdAt: 1750000000がいつなのか一目でわかる - ログ調査：ログのタイムスタンプを読める時刻に直し、障害の発生時刻を特定する
- データベース検索：
WHERE created_at > 1750000000のような条件を組み立てる - キャッシュと署名：トークンの有効期限を計算し、リクエストのタイムスタンプが有効な時間内かを検証する
2038 年問題
32 ビット符号付き整数の最大値は 2147483647 で、これは UTC の 2038 年 1 月 19 日 03:14:07 にあたります。これを超えると、秒単位のタイムスタンプを 32 ビットで保持している古いシステムはオーバーフローします。現代のシステムは 64 ビット整数を使うのが一般的で、約 2920 億年先まで表せるためこの問題はありません。上記の早見表にある 2000000000 は、この境界付近を観察するための値です。
よくある質問
10 桁でも 13 桁でも入力できますか？
どちらでも構いません。桁数で自動判定し、10 桁以下は秒、11〜13 桁はミリ秒として解釈したうえで、両方の単位の値を併記します。
変換結果が思っていた時刻と 8 時間ずれるのはなぜ？
UTC と北京時間を比べているためです。タイムスタンプは絶対的な時点で、UTC はゼロ時点の時刻を表します。北京時間は UTC+8 なので、同じタイムスタンプでは北京時間のほうが 8 時間進んで見えます。本ツールは両方を同時に表示するので、見比べれば混同しません。
日付からタイムスタンプに変換するとき、入力した日付はどのタイムゾーンで解釈されますか？
お使いのローカルタイムゾーンとして解釈します。これが多くの開発場面での期待通りの挙動です。入力が UTC 時刻なら、時差の分を自分で引くか、結果に 8 時間を足してください（北京時間の場合）。
どんな日付書式に対応していますか？
2026-10-15 14:30:00、2026/10/15 14:30、2026-10-15T14:30:00Z、そして日付だけの 2026-10-15（その日の 00:00:00 とみなします）を認識します。