タイムスタンプ変換
Unixタイムスタンプ変換は、タイムスタンプを、同じ瞬間を表すすべての実用的な表記へ、またその逆へも変換します。単位は桁数から判定したうえで明示されます。同じ整数でも、秒とミリ秒のどちらを数えているかで、1970年の時点にも2026年の時点にもなり得ます。黙って推測する変換ツールは、もっともらしく見えて1000倍もずれた日付を出力してしまいます。
上にタイムスタンプか ISO 日付を入力するか、「現在の日時」または「例を試す」を選んでください。
タイムスタンプ変換はどう動きますか？
計算そのものは単純です。難しいのは、目の前の数値が実際には何を表すのかを見極めることであり、間違いはまさにそこで起こります。
Unixタイムスタンプに単位はない
1757577600は1970年からの秒数で、2025年9月11日を指します。ミリ秒と読めば1970年1月21日です。マイクロ秒と読めば、1970年1月1日の午前0時から29分後です。値のどこにもどちらかの情報はなく、単位は桁数から推測されます。10桁以下なら秒、11桁から13桁ならミリ秒、という具合です。この推測は黙って適用されるのではなく、結果の横に表示されます。この違いは重要です。目に見える推測は、覆すことのできる事実です。
2038年問題は仮定の話ではない
符号付き32ビットのtime_tは、2038年1月19日03:14:07 UTCで上限に達し、1901年に巻き戻ります。現代のOSは何年も前に64ビットへ移行しましたが、組込みファームウェア、古いファイル形式、一部のデータベースカラムは移行していません。タイムスタンプをINTカラムに保存するコードも、同じ上限を持ちます。下の例に含まれているのは、この値でテストする価値があるからです。
タイムゾーンオフセットは地域ではなく瞬間に属する
ロンドンは1月に+00:00、7月に+01:00です。つまり「Europe/London」はオフセットを指すのではなく、日付からオフセットを導くための規則の集まりを指します。このツールのISO出力は、オフセットを計算するのではなく、プラットフォームのタイムゾーンデータベースから、その瞬間のオフセットを読み取ります。サマータイムの切替を挟んでも正しいのはこのためです。オフセットをハードコードしたものは、年に2回間違えます。
Unix時間にうるう秒はない
Unixタイムスタンプは、エポックからのうるう秒を含まない秒数と定義されています。つまり、うるう秒を表現する方法はありません。うるう秒が挿入される際、実装は同じ値を繰り返すか、余分な1秒を1日全体に平準化します。そのため、2つのUnixタイムスタンプの差は、物理的な経過時間そのものではありません。1972年以降27秒ずれており、ほとんど何にも影響しない一方で、影響する少数の用途では非常に重大です。
ISO週番号は人が期待するものではない
ISO 8601では週は月曜始まりで、第1週は最初の木曜日を含む週です。そのため、1月1日が前年の第52週や第53週に属することがあります。あるダッシュボードは第53週を表示し、別のものは第1週を表示する、ということが起こりますが、別の規則に照らせばどちらも正しいのです。
入力
1757577600
解析結果
unit seconds (10 digits or fewer) ISO 2025-09-11T08:00:00.000Z RFC 2822 Thu, 11 Sep 2025 08:00:00 GMT relative last year
タイムスタンプ変換が対応するオプションとエッジケースは？
| パラメータ | 型 | デフォルト | 動作とエッジケース |
|---|---|---|---|
| 10桁以下 | 秒 | 自動判定 | Unixエポックの古典的な単位で、ほぼすべてのAPIやデータベースがtimestampと言えばこれを指します。 |
| 11〜13桁 | ミリ秒 | 自動判定 | JavaScriptのDate.nowが返す値で、JavaScriptで書かれたJSON APIのほとんどがこれを出力します。 |
| 14〜16桁 | マイクロ秒 | 自動判定 | Postgresの内部的なtimestampや、Pythonのtime.time_nsを1000で割った値です。 |
| 17桁以上 | ナノ秒 | 自動判定 | Goのtime.UnixNanoや、Prometheusのexposition formatです。 |
| ISO 8601 | 日付文字列 | 受け付け | 2026-09-11T08:00:00Zとその亜種です。タイムゾーンのないISO文字列は、プラットフォームがローカル時刻として解釈します。これはこのツールの選択ではなく、フォーマット自体に備わる曖昧さです。 |
| 相対指定 | 式 | 受け付け | `3 days ago`、`2 hours`、`now`のような指定を受け付けます。月と年は長さが一定でないため、近似値として扱われます。 |
| タイムゾーン | IANA名 | ローカルのタイムゾーン | オフセットは、その瞬間ごとにプラットフォームの時刻データベースから取得します。そのためサマータイム切替の前後どちらでも正しい値になります。 |
| ISO週番号 | 1〜53 | 自動算出 | 週は月曜始まりで、第1週には最初の木曜日が含まれます。そのため1月1日が、前年の第52週や第53週に属することがあります。 |
よくある質問
タイムスタンプが1970年になってしまうのはなぜですか？
ほぼ間違いなく、ミリ秒を期待する場所に秒を貼り付けたか、その逆をしてしまっています。このツールは桁数から単位を判定し、どちらを選んだかを表示するので、まずその表示を確認してください。10桁なら秒、13桁ならミリ秒です。直す方法は1000で掛けるか割るか、それだけです。
秒とミリ秒、APIにはどちらを使うべきですか？
本当に1秒未満の精度が必要でない限りは秒にしてください。そしてどちらにしたにせよ、ドキュメントに明記しましょう。タイムスタンプと言えばUnixも、ほとんどのデータベースも、ほとんどの言語も秒を意味します。ミリ秒なのはJavaScriptです。バグはこの境界から生まれるので、実用的な規律は、フィールド名自体に単位を含めることです。created_atではなくcreated_at_msと。
2038年には実際に何が起こりますか？
符号付き32ビットのtime_tが2038年1月19日03:14:07 UTCでオーバーフローし、1901年12月に巻き戻ります。64ビットのシステムは問題なく、何年も前からそうです。問題なのは、これからも動き続ける組込みファームウェア、32ビットフィールドを持つファイル形式、BIGINTではなくINT型のデータベースカラムです。最後のものが、今まさにあなたのコードベースにある可能性が最も高いでしょう。
ISO文字列が1時間ずれるのはなぜですか？
たいていはサマータイムのせいです。オフセットはタイムゾーンではなく、特定の瞬間の属性です。ロンドンは1月に+00:00、7月に+01:00になります。このツールは、その瞬間のオフセットをプラットフォームのタイムゾーンデータベースから読み取るため、切替時点で変わります。それが正しい挙動であり、ハードコードされたオフセットが年の半分は間違った値になる理由です。
Unix時間はうるう秒を含みますか？
含みません。定義上、うるう秒を含まない秒数を数えるため、表現する方法がありません。うるう秒が挿入されるとき、システムはタイムスタンプの値を繰り返すか、余分な1秒を1日全体に平準化します。実際的な帰結として、2つのUnixタイムスタンプの差から得られるのは物理的な経過時間ではなく、暦の上の経過時間です。1972年以降、両者は27秒ずれています。
タイムスタンプはアップロードされますか？
いいえ。ここでの変換はすべて、算術とブラウザ内蔵のIntlタイムゾーンデータベースの組み合わせで、すでに開いているタブの中で動作します。日付の変換にサーバーは不要です。しかも変換されるタイムスタンプの多くは、本番環境のログから来ています。