Debian、2038年問題を待たず全面的に64ビット時間体系へ移行

• DebianがY2K38（Unix Epochalypse）問題を事前に防ぐため、次期バージョン Debian 13 から32ビットアーキテクチャも含めて64ビット time_t の適用を正式化
• 従来の32ビット time_t の限界により、2038年1月19日以降は時刻が1900年へ巻き戻る現象が発生しうるため、この問題をこれ以上放置しない方針
• 64ビットハードウェアはすでに安全だが、組み込み、IoT などコスト重視の32ビットデバイスではDebian需要が残っており、事前対応の必要性が強調されている
• 全6,429パッケージに分散した time_t 型を、ABI互換性の破壊を受け入れて一斉に切り替える大規模作業が進められた
• i386、hurd-i386 など一部のレガシー対応アーキテクチャは例外として残す一方、新しい64ビット time_t ベースの x86（i686）アーキテクチャ導入の可能性にも言及

---

DebianのY2K38バグ対応: 64ビット時間への移行

• Debianは、迫るY2K38またはUnix Epochalypse問題を避けるため、サポート対象の最も古いハードウェアの一部を除き、すべての環境で64ビット時間へ移行する
• これにより、2038年1月19日に発生予定の32ビット signed int の範囲超過による時刻値エラーを防止する

Y2K38およびUnix Epochalypse問題の背景

• Y2K38問題は、1970年1月1日以降の経過秒数を32ビット signed int で表現するUnixシステムで、2038年を過ぎるとオーバーフローが発生し、時刻が1900年など過去へ誤って巻き戻る現象
• これは、過去のY2K（2000年問題）と同様に、短いデータ形式を選んだアーキテクチャ上の判断に起因する
• Y2Kの際には、開発者たちの事前対応のおかげで大混乱を防ぐことができた
• 64ビットハードウェア向けソフトウェアはすでに安全だが、Debianは組み込み、低スペック、レガシー環境で今なお広く使われている

Debianの主な対応

• Debian 13 "Trixie" リリースから、すべての主要アーキテクチャで64ビット time_t をデフォルトで適用する
• 64ビットハードウェアはすでに安全だが、32ビットプロセッサベースの組み込み機器やレガシーハードウェアでは問題が起きやすい
• こうした機器は、自動車制御、IoT、テレビ、ルーターなど、コスト重視かつ大量出荷される分野で今なお使われている
• 多くの新型機器は OpenEmbedded、Alpine、Android、Gentoo などの独自ビルドLinuxを使っているが、Debianベースの組み込み機器の利用先も今後数年は続く見通し

適用内容と変更点

• time_t 変数は関連コードの6,429パッケージに分散しており、大規模な作業が必要だった
• 今回の変更はABI（アプリケーション・バイナリ・インターフェース）互換性を壊す可能性があるため、関連するすべてのライブラリとパッケージで同時に調整された
• メンテナンスチームによれば、この作業は完了しており、十分なテストも実施済み

例外と今後の計画

• i386 ポート（従来の x86）は32ビット time_t を継続し、既存バイナリの実行互換性を目的として残される
• i686 アーキテクチャについては、64ビット時間と最新ISA（命令セットアーキテクチャ）の適用が別途議論される可能性がある
• hurd-i386 ポートはカーネル側のサポート不足により移行せず、代わりに hurd-amd64 へ移す案が進められている

開発者向けの参考事項

• 開発者は、自身のソフトウェアが64ビット時間変数の適用によって壊れないかを、Debian Wikiで案内されている方法を通じてテストできる
• 詳細情報および技術文書は Debian wiki で提供されている

[GN⁺]

Hacker News の意見

• Steve Langasek は人生最後の数年間、この問題の解決に集中して大きな進展を導いた。今後 64ビットの time_t を見るたびに彼を思い出すだろう
  • 良い話をあらためて知らせてくれてありがとう。Steve がいなくて寂しい。Joey は今も Debian で活動を続けているのだろうか
• Y2K 問題（2桁の年表記によって生じた 2000 年問題）については、当時は 2バイト節約する価値が非常に大きかった。70〜90年代のソフトウェアは変化が速く、5年以上使われるとは期待されていなかったので、あまりに見下した見方だと思う
  • 今でも 2桁の年はよく使われている。たとえばクレジットカードの有効期限（mm/yy）は短く書けて便利なので 2桁表記を使う。カードの寿命には十分だが、2100年には変換の問題が起きるかもしれない。Y2K の多くは UI の問題に由来していた（2文字の text field、+1900 のハードコードなど）。自分が直接遭遇した Y2K バグは、インターネットフォーラムが 1999 年から 19100 年に飛んだものだった（単なる表示バグ）。Y2K は COBOL だけの問題ではなかった
  • こういうケースでは「時期尚早の最適化」のほうがむしろ役に立ったはずだ。1900年を 0 とする単純な int 値で日付を表していれば、さらに多くのバイトを節約できた。3バイトなら 1900年から約 44,000 年先まで、2バイトでも 2070 年ごろまでカバーできる
  • 人々が混同しているのは、2バイト追加ではなく 2文字追加が必要だったという点だ。COBOL では数値でもデータでも文字数ぶんの固定幅で割り当てるので、4桁の年を入れるには 4文字分の領域が必要だった。こうしたフィールドサイズは、データアクセス、UI、バッチファイル、中間ファイル、受け渡しファイルなどプログラム全体にハードコードされていた
  • Y2K 直前に、大手銀行の株価暴落を見込んで put オプションを大量に買った知人がいたが、実際には大事はほとんど起きなかった
  • 80年代後半に COBOL で仕事をしていたとき、1桁の年だけを保存するプログラムを見たことがある。構造の説明を聞いたときは奇妙だと思ったが、記録は 4年ごとに自動削除されるので運用上の問題はなく、どの年かは常に明確だった
• 64ビットの time_t で Epochalypse は解決するだろうが、すべてのシステムが単純に 64ビット秒へ移行するわけではない。ext4 はすでに 30ビットの小数解像度（ナノ秒級）と 34ビットの秒解像度に変わっているが、やはり数百年後にはまた問題が起きる見込みだ。いずれ 64ビット秒 + 64ビット小数の 128ビットタイムスタンプに落ち着くのではないかと思う。そうなれば人類史で予見可能な未来はすべてカバーできる
  • 64ビット秒は約 5850億年に相当する。WolframAlpha の計算結果
  • 64ビットの小数解像度でも足りないかもしれない。プランク時間に近づけるには 144ビット必要だ
  • ext4 のタイムスタンプが気になっていたが、zfs と btrfs のファイルシステムが時間をどう扱っているのかも気になる。btrfs はたぶん 64ビットだろうし、zfs も（ext4 と混同しているかもしれないが）似たようなものだと期待している
• Debian が Y2K38、つまり Unix Epochalypse 問題を解決すると言っているが、実際には i386 を除くすべての 32ビットポートで time64_t への移行はすでに完了している。互換性のため i386 だけが例外で、それ以外は m68k を含めすべて変更済みだ。自分で m68k、powerpc、sh4、hppa を移行した
• time_t は変数ではなくデータ型だ
  • 記事の内容は Debian Wiki に基づいている。原文には「time_t は本当にあちこちに登場する。35,960 パッケージのうち 6,429 のソースコードに現れる。time_t を含む構造体を ABI として公開するパッケージは、ABI 全体を同時に移行しなければならない」と明記されている。Wiki のほうが記事よりも明確に説明していた
  • “For everything” は armel、armhf、hppa、m68k、powerpc、sh4 を指しており、i386 は含まれない。i386 に未来はなく、既存のバイナリや動的ライブラリを動かすのが主目的なので、壊したくないのだろう
  • 「Debian 13 Trixie リリース後に適用予定」というのは、実際には Trixie に含まれるという意味だ
• コマンドライン長の制限も無制限または動的にしてくれるといいのに。96GB のメモリがあるのに “argument list too long” エラーが頻繁に出て不便だ
  • カーネルを再コンパイルしてコマンドライン長（約 10万文字）の制限を外せる。stackoverflow の参考。ただ、根本的な解決には思えない。4k JPEG ほど長い引数を何に使うのか疑問だ
  • RLIMIT_STACK の値を増やせばよい。たとえば ulimit -s 4000 なら 4MB スタックだ。さらに大きくするなら /etc/security/limits.conf を修正して再ログインが必要になる
  • Electron にパッケージして http post json リクエストとして渡せばいいのでは
  • MAX_ARG_STRLEN を再定義してカーネルを再コンパイルすればよい。ページサイズが大きいマシン（例: 64k ページサイズの RHEL Arm カーネル）を使う手もある。ただし、コマンドバッファの代わりにパイプを使ってプロセス間でデータを渡すほうがはるかに簡単だ
  • ファイルパス長の制限も同じ問題だ。いくつかのビルドシステム（Debian + python + dh-virtualenv など）ではパスが非常に長くなることがあるので、単に許容してくれるほうが楽だ
• 64ビットにしても、いつかは限界が来る。292277026596年 12月4日 15時30分7秒（UTC）に人類が何をしているのか気になる
  • おそらくそのころには、ipv6 完全導入 100周年を祝っているだろう
  • 50億年以内に太陽は赤色巨星になり、地球表面はすべて蒸発しているはずだ
  • そのころまでには、もっと良い暦システムに移行していてほしい。もちろんタイムスタンプの問題自体は残るだろうが
  • 128ビット時間にすればよい
  • RFC 2550(Y10K & beyond) が使えるかもしれない。1999年4月1日に公開された
• OpenBSD 5.5 が同じ変更を適用してから、もう 11年も経っている。OpenBSD 5.5 リリースノート
  • これは完全に先行していた例だ。90年代に OS/2 の 32ビット API が 64ビット時間を返すのを見つけ、自分で 64ビット time_t の C++ 標準ライブラリを書いて使っていた
  • 少し話はそれるが、こういう時期になると Linux ではなく OpenBSD にサーバーを移したくなる
  • OpenBSD は互換性をそこまで気にしなくてよく、利用者もずっと少ないので、変更時のバグやエッジケースの可能性も低くなる
• 「Debian は十分に完成してテストも済んだので、Trixie リリース後に切り替え予定」とあると、Trixie には適用されないのか気になる
  • Trixie のリリースノートには適用されると書かれている。Trixie リリースノート
• Y2K38 を Unix Epochalypse と呼ぶのは初めて聞いたが、かわいい名前なので広まるかもしれない
  • Wikipedia の Year 2038 Problem にもその名前が出ている。2017年ごろから冗談として使われ始め、広まった
  • epochalypse-project.org というプロジェクトもある
  • “it’s kind of fetch” という表現には Mean Girls のネタっぽさがある
  • Epochalypse まであと約 12年 5か月 22日 13時間 22分