Unix 時間と日時を相互に変換

Unix 時間を貼れば JST の日時に、日時を入れれば Unix 時間になります。変換結果の下には、その値を秒とミリ秒のどちらとして読んだかと、UTC 表記、ISO 8601 表記が並びます。

変換結果
2026-09-10 09:26:40(木)JST
単位の判定
秒として読みました
UTC
2026-09-10 00:26:40(木)
ISO 8601
2026-09-10T00:26:40.000Z

桁数で秒とミリ秒を見分ける

Unix 時間は 1970 年 1 月 1 日 0 時 0 分 0 秒 UTC からの経過秒数です。ただし実際に流通する値には、秒のものとミリ秒のものが混ざります。このツールは 11 桁を超える値をミリ秒として読みます。秒として読むと西暦 5138 年より先になってしまうためです。

単位を取り違えると、日時は千倍ずれた場所に着地します。行き先は二通りしかなく、1970 年の直後か、遠い未来かのどちらかです。どちらとして読んだかは結果の下に必ず出るので、値そのものを疑う前に単位を確かめられます。

  • 11 桁以下は秒、12 桁以上はミリ秒として読まれる
  • 結果が 1970 年 1 月あたりなら、秒の値がミリ秒として扱われている
  • 結果が遠い未来なら、ミリ秒の値が秒として扱われている
  • 結果の下の単位表示が、渡す相手の仕様と合っているか確かめる

日時から Unix 時間を出すとき

入力した日時は JST として解釈します。たとえば 2026 年 9 月 5 日 14 時 30 分 0 秒 JST は、Unix 時間で 1788586200 です。10 桁なので秒の値であり、同じ時刻をミリ秒で表せば 13 桁になって、ミリ秒として扱われる側に回ります。

この向きでは秒とミリ秒の両方が出ます。受け取り側がミリ秒を求めているときに、手元で末尾へ 000 を足すと桁を数え間違えやすいので、出た値をそのままコピーする方が確実です。UTC 表記と ISO 8601 表記も並ぶため、仕様書や設定ファイルに書く形式に合わせて選べます。

ログから拾った数字は加工せずに貼る

ログや管理画面に残るのは数字だけで、それが秒なのかミリ秒なのかは書かれていないことがほとんどです。あらかじめ 1000 で割ってから貼ると、割る必要のなかった値まで割ってしまい、間違いが二重になります。数字はそのまま貼り、単位の判定は結果の下の表示に任せる方が早く済みます。

桁数から単位が正しく判定されているのに、出てきた日時が想定とかけ離れている場合は、単位ではなく値そのものを疑うことになります。その数字が Unix 時間ではなく、別の基準で数えた値である可能性があります。

よくある質問

10 桁と 13 桁のどちらで渡せばいいですか

受け取る側の仕様に合わせます。このツールは 11 桁を超える値をミリ秒として読むので、渡す前に結果の下の単位表示を見れば、手元の値がどちらとして扱われるか確認できます。

別のシステムで変換したら 1970 年 1 月になりました

秒の値がミリ秒として読まれると、1970 年の直後に着地します。同じ値をここで変換し、単位の判定と桁数を照らし合わせると、どちら側の取り決めがずれているかが分かります。

タイムゾーンは選べますか

日時の入力は JST として解釈します。結果には UTC 表記も並ぶので、UTC での時刻はそのまま読めます。それ以外の地域の時刻は扱いません。

ミリ秒より細かい単位は扱えますか

マイクロ秒やナノ秒には対応していません。桁数の多い値を貼ると 11 桁を超えるためミリ秒として読まれ、遠い未来の日時が出ます。単位表示と桁数を見れば、その取り違えには気づけます。

ほかの変換ツール

最終更新:2026-09-05。次のようにも検索されます:unixtime 変換 ツール、エポック秒 日時 変換、unix時間 秒 ミリ秒 違い、タイムスタンプ 変換 jst