Unix タイムスタンプ変換：10桁・13桁と秒／ミリ秒の見分け方

本当に必要な場面

ログに数字が1つだけあり、それがローカル時刻でいつなのか、UTC でいつなのかをすぐに知りたいときです。タイムゾーンをまたぐ調査では、両方を並べて見るほうが暗算より確実です。

データベースや API に書き込む前に、2026-10-25 15:30:00 を Unix 秒に変換し、時ずれがないか確認したいときです。秒を要求する API もあればミリ秒を要求する API もあり、1000倍を間違えると大きくずれます。

外部サービスが返す expires_at や iat を確認するときです。まず秒かミリ秒かを見極め、そのうえで変換した日時が妥当かを判断します。

• ログの数字だけからローカル時刻と UTC を知る
• データベースに書く前にローカル日時を秒に変換する
• API の値が秒かミリ秒か確認する
• ローカル時刻と UTC を並べて比べる

失敗しないための手順

桁数で判断します。10桁は秒、13桁はミリ秒で、1000倍の違いがあります。このツールは絶対値が 10^11 以上かどうかで判定し、未満は秒、以上はミリ秒として扱います。そのため12〜13桁はミリ秒、11桁は秒のままです。小数を含む入力はミリ秒として扱います。迷ったら「現在時刻」を押して桁数を比べてください。

JavaScript では Date のコンストラクターがミリ秒を受け取るため、秒は1000倍します。new Date(sec * 1000) です。逆に秒を取得するときは Math.floor(Date.now() / 1000) とします。秒のつもりで Date.now() をそのまま渡すと、約1000倍の値になります。

タイムゾーンについて、ローカル時刻はブラウザのタイムゾーンで描画され、夏時間はそのタイムゾーンの規則に従ってブラウザが処理します。UTC と ISO の行は常に UTC で、ISO は 2026-10-25T07:30:00.000Z のような形式です。タイムゾーンを切り替える機能はないため、同じタイムスタンプでも別の端末ではローカル時刻が変わって見えますが、UTC は変わりません。

0 を「値なし」として使わないでください。0 は 1970-01-01T00:00:00Z という有効な時刻です。欠損を表すなら null を使い、読み取り側で明示的に判定してください。

2038年問題は、Unix 秒を32ビット符号付き整数で保存することに由来します。最大値 2,147,483,647 が 2038-01-19T03:14:07Z にあたります。このツールは JavaScript の Number と Date（倍精度浮動小数点数）を使うため影響を受けず、Date は約 ±8.64e15 ミリ秒まで扱えます。ただし保存先のデータベース列やサーバーが32ビットのままの場合は、別途確認が必要です。

• 10桁は秒、13桁はミリ秒。1000倍の違い
• JavaScript の Date には秒を1000倍して渡す
• ローカル時刻はシステムのタイムゾーン、UTC は固定
• 0 は有効な時刻。欠損は null で表す

代替手段と限界

コマンドラインでは、macOS は date -u -r 1761328800、Linux は date -u -d @1761328800 で UTC を直接表示できます。現在の秒は date -u +%s です。スクリプトでの一括変換に向いています。

コードではタイムゾーン対応の API を使ってください。Python の datetime.fromtimestamp(ts, tz=timezone.utc)、Java の Instant.ofEpochSecond、Go の time.Unix などです。タイムゾーンと書式を正しく扱えます。

ニューヨーク、ロンドン、東京の壁時計を同時に見たい場合や、2026-10-25T15:30:00+08:00 のようなオフセット付き ISO 文字列を解析したい場合は、タイムゾーンを選べるツールか日付ライブラリを使ってください。このツールは数値のタイムスタンプとローカル日時の入力だけを受け付け、日付の加減算も行いません。

• スクリプトでの一括変換 → date
• アプリケーションコード → タイムゾーン対応 API
• 複数タイムゾーンやオフセット付き ISO → 専用ツール
• このツールはオフセット解析もタイムゾーン切替も不可