AZ Tools

エポック時刻変換 (Unix, FILETIME, Excel)

時間

OS やアプリは時刻を '選んだ基準点から経過した秒(または何らかの単位)' で測定しますが ─ それぞれ別の基準点を選んでいます。Unix は 1970-01-01 UTC。NTP は 1900-01-01 UTC。Windows NT は 1601-01-01 UTC を取って 100 ナノ秒単位で計数(FILETIME)。.NET DateTime ticks は 0001-01-01 から 100 ナノ秒単位。Classic Mac OS HFS+ は 1904-01-01 秒単位。Apple Cocoa CFAbsoluteTime は 2001-01-01 秒単位。Microsoft Windows Excel は 1899-12-30 から日単位(Lotus 1-2-3 が 1900 をうるう年と誤処理したバグを Excel が互換のため継承);Mac Excel は 1904-01-01 から。人間が読む形式も: ISO 8601 ('2026-06-05T00:00:00.000Z')、RFC 2822 ('Fri, 05 Jun 2026 00:00:00 GMT')。SQL Server BIGINT、Windows イベントログ、Numbers の CSV がすべて同じ瞬間を別形式で表現していたら ─ 翻訳が必要。本ツールが一発で: 左で形式を選び値を貼り付ければ、他のすべての形式が正しいエポックオフセットと単位で即座に表示。FILETIME と .NET ticks は BigInt 演算で処理 ─ JavaScript の 53 ビット浮動小数点を超える遠未来日付でも精度が保たれます。

基準時刻
全形式
ISO 8601
UTC ISO 8601 日時文字列
2026-06-10T04:05:03.600Z
RFC 2822
GMT RFC 2822 / HTTP 日付文字列
Wed, 10 Jun 2026 04:05:03 GMT
Unix(秒)
エポック 1970-01-01 UTC · 秒
1781064303.6
Unix / JS(ミリ秒)
エポック 1970-01-01 UTC · ミリ秒
1781064303600
NTP(秒)
エポック 1900-01-01 UTC · 秒
3990053103.6
Windows FILETIME
エポック 1601-01-01 UTC · 100ns 単位
134255379036000000
.NET Ticks
エポック 0001-01-01 UTC · 100ns 単位
639166611036000000
Mac HFS+(秒)
エポック 1904-01-01 UTC · 秒
3863909103.6
Apple Cocoa
エポック 2001-01-01 UTC · 秒(CFAbsoluteTime)
802757103.6
Excel 1900 シリアル
エポック 1899-12-30 · 日単位(Lotus バグ互換)
46183.1701806
Excel 1904 シリアル
エポック 1904-01-01 · 日単位(Mac Excel)
44721.1701806
変換の詳細

内部基準値: 1970-01-01 UTC からの JavaScript ミリ秒(53 ビット浮動小数点、1970 基準で約 ±285 614 年有効)。FILETIME と .NET ticks は BigInt 演算で厳密整数精度を保持。Excel 1900 はオフセット 25569(1899-12-30 から 1970-01-01) ─ 1900-03-01 以降のすべての日付で正確、Lotus の幻 1900-02-29 は無音で省略。ISO 8601 と RFC 2822 出力は常に UTC/GMT。

使い方

  1. ドロップダウンでソース形式を選択(既定: ISO 8601、現在時刻)。
  2. その形式で値を入力/貼り付け ─ 11 表現が即座に更新。
  3. 形式ドロップダウンを切り替えると変換: 表示値が新形式で入力欄に再充填。
  4. プリセットで定番基準時刻を投入: 現在·Unix エポック(1970)·Y2K·Y2038 問題·NTP 32 ビットロールオーバー(2036-02-07)。
  5. 各行のコピーボタンでその表現をクリップボードへ。

よくある質問

Excel 1900 シリアルはなぜ 1900-01-01 ではなく 1899-12-30 から数える?
Lotus 1-2-3 が 1900 をうるう年と誤処理(実際はうるう年でない ─ 1900 ÷ 100 = 19 余り 0 だが 1900 ÷ 400 ≠ 整数で、グレゴリオ暦規則で除外)。Microsoft は Excel 開発時にスプレッドシート互換性のため Lotus のバグをそのまま複製 ─ なので Excel には幻の 1900-02-29 が存在。1900-03-01 以降のすべての日付できれいに動くよう 25569(1899-12-30 から 1970-01-01 までの日数) オフセットを使用 ─ 実日付すべてで正しい結果。Excel の 1900-03-01 以前は 1 日ずれますが実務ではまれ。
FILETIME と .NET Ticks に BigInt を使う理由は?
FILETIME は 1601-01-01 UTC から 100 ナノ秒単位。2100 年頃で ~1.6 × 10¹⁷ ─ Number.MAX_SAFE_INTEGER(~9 × 10¹⁵) を大きく超える。通常の JavaScript Number で保存すると下位桁が無音でずれる。.NET ticks も同様(2100 年頃 ~6.6 × 10¹⁷)。BigInt は JavaScript の任意精度整数 ─ 全桁を厳密に保持 ─ そのため FILETIME を本ツールで往復しても完全に同じ桁数が返ります。
Y2038 問題とは?本ツールの Unix 出力に影響は?
多くのレガシー C プログラムは Unix 時刻を符号付き 32 ビット整数で保存 ─ 2³¹ − 1 秒後の 2038-01-19 03:14:07 UTC でオーバーフロー。本ツールは時刻を JavaScript ミリ秒(64 ビット浮動小数点、1970 基準で ±285 614 年有効) で保存するため Y2038 は問題なし。Y2038 をプリセットで公開しているのでその瞬間を各形式がどう表現するか確認できます。NTP は 32 ビット秒カウンタが再起動する 2036 年に独自ロールオーバー ─ それもプリセット。
なぜ Excel 1900 と Excel 1904 両方?
Excel for Windows は 1900 基準、Excel for Mac(と最近まで Numbers) は 1904 基準。Windows アナリストと Mac アナリストでスプレッドシートをやり取りすると各アプリ内では正しく見えますが、シリアル数字を生のままコピーすると ~4 年ずれます。両形式を公開して検出/変換できるようにしています。

関連ツール