UNIX タイムスタンプを変換

数字を貼り付けて、それがどの瞬間を指すのかを確かめてください。秒かミリ秒かは自動で判別し、どちらとして読んだかを必ず示します。黙って当てにいくことが、1000 倍の誤りを謎に変えるからです。UTC、日本標準時、ISO 8601、そしてどれくらい前か——問いがひとつで済むことはめったにないので、答えは 4 つ出ます。

自動判別はほぼ確実に当たり、答えにはどちらとして読んだかが書かれます。

結果

入力すると、ここに答えが出ます。

  • 処理される場所

    ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。

  • 順番待ちもアカウントもなし

    お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。

  • 何度でも

    回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。

仕組み

  1. タイムスタンプを貼り付けてください。
  2. 数字が紛らわしいと分かっている場合を除き、自動判別のままにします。
  3. UTC と日本時間の日時を読みます。何も送信されていません。

10 桁か、13 桁か

UNIX タイムスタンプは 1970 年 1 月 1 日からの経過を数えます。秒なら現在の日付は 10 桁、ミリ秒なら 13 桁です。この桁数の差があるので、尋ねずに単位を推定できます。しきい値は、人が見るどんな日付からも遠く離れています。

推定した結果は必ず表示します。この変換の古典的な失敗が、黙って当てにいくことだからです。ミリ秒の数字を秒として読めば 5 万年台の日付が出て気づきます。逆なら 1970 年が出て、これも気づきます。気づけないのは、勝手に決めてそれを言わない道具です。

UTC と現地時間は表示上の細部ではありません

数字自体はタイムゾーンを持ちません。絶対的な瞬間です。ゾーンは日時として書き出すときに現れ、この変換で最も高くつく誤解がそこから生まれます。同じタイムスタンプを見ている 2 人が、別の時間帯にいるために別の日を読む。

だから両方を出します。日本標準時は UTC より 9 時間進んでいます。したがって 15 時 00 分 UTC のイベントは、日本ではもう翌日です。ログと管理画面の表示が食い違うとき、その半分はまさにこれです。

日本に夏時間はなく、それでも日付はずれます

日本標準時は 1 年を通して UTC+9 で固定です。夏時間は 1948 年から 1951 年まで実施されて廃止されたきり、戻っていません。ヨーロッパやアメリカのレポートを悩ませる「1 日に 2 度ある時刻」と「存在しない時刻」は、国内のデータには現れません。

代わりに来るのが日付境界です。UTC の 1 日と日本の 1 日は 9 時間ずれているので、UTC で日ごとに集計したレポートと日本時間で集計したレポートは、15 時から 24 時 UTC のあいだに起きたことすべてを別の日に置きます。海外のシステムのログと国内の管理画面を突き合わせるときの、最初に疑うべきずれです。

2038 年

符号付き 32 ビット整数に格納されたタイムスタンプは、2038 年 1 月 19 日に溢れて 1901 年へ飛びます。遠い先の話に聞こえて、もう遠くありません。20 年先を見るあらゆる計算——住宅ローン、証明書、償却計画——は今日その境界をまたぎます。

現代のシステムは 64 ビットを使うのでこの問題を持ちません。残っているのは古いバイナリ形式、組み込みシステム、ずっと前に宣言されたデータベースの列です。遠い日付を誰かが入力するまで現れず、そのとき一斉に現れる種類の不具合です。

ISO 8601 と、並べ替えがうまくいく理由

`2023-11-14T22:13:20Z` という形は、テキストとして並べ替えると日付としても並ぶように設計されています。ファイル名、キー、そして日付を見ていると知らないまま何かが辞書順に並べる場所では、これが適した形です。

末尾の `Z` は UTC を意味します。これがないことは尽きせぬ誤りの源です。ゾーンのない文字列は、システムごとに自前の想定で解釈され、2 つのサービスが同じテキストを数時間離れた 2 つの瞬間として読みえます。日付を書くなら、ゾーンを書いてください。

うるう秒はここに存在しません

UNIX 時間は、すべての日がちょうど 86,400 秒であるかのように振る舞います。これは事実ではありません。地球の自転の不規則さを補うために、1972 年以降 27 回のうるう秒が挿入されてきました。この形式はそれを単に無視します。

ほとんどの用途にとって正しい判断です。日付の算術が成り立つからです。天文学、測位システム、一部の科学的な測定では正しくなくなります。そこでは本当にうるう秒が問題になり、そして UNIX 時間ではなくそれを数える時刻系が使われます。

ISO 週番号と、一致しない年

ISO の週番号は、その年の最初の木曜日を含む週を第 1 週と定め、週は月曜に始まります。そこから、1 月 1 日が前年の第 52 週に入りうること、12 月 31 日がもう翌年の第 1 週でありうることが出てきます。

この細部が毎年 1 月に週次レポートを壊します。実務上の規則は「週の年は必ずしも日付の年ではない」で、週単位で集計する人は 2 つを一緒に保存する必要があります。年のない「第 1 週」は、最も参照される時期にちょうど曖昧になります。

どれくらい前か、そして何の役に立つか

相対表示の行——「3 年前」「11 分前」——が足すのは精度ではなく尺度です。そのログが今朝のものか先月のデプロイのものかを一目で答えます。タイムスタンプを見る背後にある本当の問いは、たいていそれです。

ブラウザーに組み込まれた書式化機能を使って日本語で書かれるので、英語のひな型を訳したものではなく、日本語として自然な形が出ます。正確な答えは他の行が受け持ちます。これは見当をつけるためのものです。

個人情報保護法から見たときの位置

タイムスタンプが単独で旅することはほとんどありません。ログの 1 行、データベースの行、隣にユーザー識別子が並んだペイロードからコピーされます。変換はページの中で行われるので、数字も、それに付いてきたものも端末から出ません。

それに、お使いのタイムゾーンは見た目より多くを特定する情報です。ここではブラウザーの設定を使い、それがどこかへ出ることはありません。現地時間への変換をするのはあなたの端末で、それを知る必要がある唯一の場所です。

UNIX タイムスタンプを変換:よくある質問

秒かミリ秒かはどうやって判断しているのですか。

数字の桁数です。現在の日付は秒なら 10 桁、ミリ秒なら 13 桁になります。しきい値は現実的などの日付からも遠く、答えにはどちらとして読んだかが必ず書かれます。

日本時間の表示がログと合わないのはなぜですか。

ログがほぼ確実に UTC だからです。日本標準時は UTC より 9 時間進んでいるので、15 時 00 分 UTC 以降のイベントは日本ではもう翌日になります。

2038 年に何が起きるのですか。

符号付き 32 ビット整数に格納されたタイムスタンプが 2038 年 1 月 19 日に溢れ、1901 年へ飛びます。64 ビットのシステムに問題はありません。残るのは古いバイナリ形式、組み込み機器、ずっと前に宣言された列です。

週番号が日付の年と一致しないのはなぜですか。

ISO の第 1 週が、その年の最初の木曜日を含む週だからです。1 月 1 日が前年の第 52 週に入ることがあります。週単位で集計するなら、週の年を番号と一緒に保存してください。

数字はどこかへ送られますか。

いいえ。変換はこのページの中で行われ、タイムゾーンはお使いのブラウザーが使うだけで外へは出ません。タイムスタンプはほぼ必ず何かと一緒にコピーされますが、その何かも動きません。

他のツール