Unixタイムスタンプ変換

Unixタイムスタンプ変換について

Unixタイムスタンプは、1970年1月1日00:00:00 UTCからの経過秒数を表す整数です。サーバーログ、データベースのカラム、APIのcreated_atなどに1789000000のような数字で入っています。このツールはその数字を読める日時に、日時を数字に変換します。

数字そのものにタイムゾーンはありません。1790035200は東京では2026年9月22日午前9時、UTCでは同じ日の0時です。つまずくのはたいてい単位(秒かミリ秒か)と表示するタイムゾーンです。

10桁なら秒、13桁ならミリ秒

本来のUnix時間は秒単位ですが、JavaScriptのDate.now()やJavaのSystem.currentTimeMillis()はミリ秒を返します。同じ瞬間が1789000000(10桁)と1789000000000(13桁)の両方で保存されるわけです。ミリ秒を秒として変換すると西暦5万年台に、秒をミリ秒として読むと1970年1月21日ごろになります。結果が1970年付近か極端な未来なら、まず単位を疑ってください。

このツールは整数部の桁数で単位を判定します。現在の時刻は秒で10桁、ミリ秒で13桁、マイクロ秒で16桁、ナノ秒で19桁なので、11桁以下は秒、12〜14桁はミリ秒、15〜17桁はマイクロ秒、18〜19桁はナノ秒として読みます(Goやトレーシングツールのナノ秒値もそのまま入れられます)。ISO 8601変換ツールも同じ規則です。秒単位は2001年9月9日(1000000000)から10桁になり、2286年まで10桁のままなので、いま扱う値ではこの境界でまず外れません。1789000000.5のような小数付きの値は秒として読みます。

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

符号付き32ビット整数の最大値は2^31 − 1 = 2147483647で、変換すると2038-01-19T03:14:07Zです。その1秒後、32ビットのカウンターは−2147483648にあふれ、1901年12月に戻ります。これが2038年問題です。

64ビットのtime_tを使う現行のOSや言語は問題ありませんが、古い組み込み機器、4バイトの時刻フィールドを持つファイル形式、32ビット整数で定義されたDBカラムは残っています。MySQLのTIMESTAMP型も上限は2038-01-19 03:14:07 UTCです。住宅ローンの返済予定のように将来の日付を保存するシステムは、すでにこの境界を越える値を扱っています。

うるう秒は数えない

POSIXは「エポックからの秒」を1日ちょうど86400秒として計算すると定めています。1972年以降UTCには27回うるう秒が挿入されましたが、Unix時間には入っていません。直近の2017年1月1日8時59分60秒(JST)、つまり2016-12-31T23:59:60ZにはUnixタイムスタンプが存在せず、多くのシステムは同じ秒を繰り返すか、前後の時間を少しずつ引き延ばして(leap smear)吸収しました。

そのため2つのタイムスタンプの差は、実際に経過したSI秒と最大27秒ずれることがあります。2022年の国際度量衡総会は、遅くとも2035年までにうるう秒の挿入をやめると決議しました。このツールも23:59:60の入力は受け付けません。

JSTで見るときの注意

日本標準時(JST)と韓国標準時(KST)はどちらもUTC+9で、夏時間はありません。UTCに9時間足せばよいのですが、日付の境目に注意が必要です。UTC 15:00以降は日本では翌日です。UTCの日付で日次集計すると、日本時間0時〜9時の注文が前日に入ります。

日時入力欄はブラウザが報告するこのパソコンのタイムゾーンで解釈されます。別のタイムゾーンの時刻を変換したいときは、オフセットを指定できるISO 8601変換ツールを使ってください。

例

使い方

1. タイムスタンプ欄に数字を貼り付けると、単位を判定してUTC・ローカル時刻・相対時間を表示します。
2. 逆方向は日時欄に入力すると、秒とミリ秒の値が出ます。
3. 「現在」ボタンで今のタイムスタンプを取得できます。

よくある質問