日時変換ツール
Unix タイムスタンプ、JavaScript ミリ秒、ISO 8601、ISO 9075、RFC 3339、RFC 7231、Mongo ObjectID、Excel シリアル値を相互変換。入力形式は自動判別します。
ひとつの時刻を、必要なあらゆる形式に変換します。
タイムスタンプ形式の解説
秒かミリ秒か
日時を扱ううえで最も多い間違いが、この二つの混同です。Unix タイムスタンプは 1970-01-01 UTC からの秒を数えますが、JavaScript の Date.now() はミリ秒を数えます。Unix タイムスタンプを 1000 倍せずに Date コンストラクタへ渡すと、1970 年 1 月に飛んでしまいます。目安として 10 桁なら秒、13 桁ならミリ秒で、本ツールの自動判別もこの基準で動いています。
各標準の違い
- ISO 8601 は基本となる標準で
2024-01-15T10:30:00.000Zの形式です。Tが日付と時刻を区切り、Zは UTC を表します。 - RFC 3339 はインターネットプロトコル向けに ISO 8601 を厳格化したもので、オフセットの明示が必須のため
Zではなく+00:00と書きます。 - ISO 9075 は SQL 標準の形式
2024-01-15 10:30:00です。Tの代わりに空白を使い、タイムゾーンを持ちません。多くのデータベースが出力する形式です。 - RFC 7231 は
Date・Expires・Last-Modifiedヘッダーで使われる HTTP 日付形式で、常に GMT で表記されます。
特殊な二つの形式
Mongo ObjectID は 12 バイトで、先頭 4 バイトが Unix 秒による生成時刻です。つまり ObjectID には必ずタイムスタンプが埋め込まれています。本ツールはデコード時にそれを取り出し、生成時には machine / counter を捏造せず残り 8 バイトをゼロで埋めます。
Excel シリアル値は 1899-12-30 からの日数を表し、小数部がその日の時刻に対応します。この一風変わった起点は、1900 年を閏年として扱う Lotus 1-2-3 の不具合を Excel が意図的に再現しているためです。1899-12-30 を 0 日目とすることで 1900 年 3 月以降の日付がすべて整合するので、本ツールもこれを採用しています。
すべては同じ一瞬
どの形式を入力しても、ツールはまず単一の JavaScript Date として解釈し、その同じ一瞬を 11 種類すべての形式で描画し直します。変換はすべてブラウザ内で完結し、データが送信されることはありません。
よくある質問
Unix タイムスタンプが 1970 年になってしまうのはなぜ？
ミリ秒が期待される場所に秒を渡している可能性がほぼ確実です。1000 倍するか、入力形式で「Unix 秒」を選べばツール側で処理します。
ISO 8601 と RFC 3339 の違いは？
RFC 3339 はインターネットプロトコル向けに ISO 8601 を厳格化した部分集合です。RFC 3339 の日付はすべて妥当な ISO 8601 ですが逆は成り立ちません。RFC 3339 は +00:00 のような数値オフセットを必須とし、ISO 8601 は Z・週日付・年間通日なども許容します。
Mongo ObjectID から日時を取り出せますか？
できます。ObjectID の先頭 4 バイト（16 進 8 文字）が Unix 秒による生成時刻です。ObjectID を貼り付ければ、その瞬間を他のすべての形式にデコードします。
なぜ Excel の起点は 1900-01-01 ではなく 1899-12-30 なの？
Excel は 1900 年を閏年として扱う Lotus 1-2-3 の不具合を意図的に踏襲しています。起点を 1899-12-30 まで戻すとその 1 日のズレが相殺され、1900 年 3 月以降の日付が正しく変換されます。
データはサーバーに送信されますか？
いいえ。解析も整形もすべて標準の Date API を使ってブラウザ内で完結します。アップロードも記録も行いません。