もう年を取ったと感じますか？規制のせいで一日が台無しになるかもしれません。2000年問題（そう、Y2Kから8,049日です）以来、2038年問題（5,849日）は大幅に近づいています。
なぜこのことを取り上げるのでしょうか？鋭い観察眼を持つReg読者のCalum Morrison氏のおかげで、前者の一部、そしてBBCのデジタルプレゼンスの裏に隠された秘密を垣間見ることができました。モリソン氏が送ってくれたスナップショットによると、Old AuntieがiPlayerで32ビットLinuxを使用しており、しかもカーネルもLinux 5.10よりも古いものを使用している可能性があるとのことです。
2020 年のカーネル リリースは、2038 年 1 月 19 日の 03:14:07 UTC 以降も動作するように設計された 32 ビット システムのベースとして機能することができた最初のカーネル リリースでした。
一部のiPlayerプログラムの締め切り日は2038年1月18日です。
昔、iPlayer サービスは、当初は Windows XP、Windows Media Player 10 以降、Internet Explorer を実行する必要があり、問題を抱えたスタートを切りました。そして、うっとうしい、うぬぼれた Mac および Linux ユーザーのために、その大部分が既製の技術に置き換えられました。
有効期限に注目してください。Unix愛好家にとって、その日付はDOS愛好家にとって2000年がそうであったように、非常に目立ちます。これは単にペイリン氏のプログラムの有効期限が切れる日ではなく、どこかで人質に取られている32ビットLinuxマシンからのささやくような嘆願なのかもしれません。
この運命の日は、様々な場所で話題になります。DOTA2ファンにとっては、永久BANの期限が切れる日です。そして、Atlassian JIRAユーザーも、（現在は修正済みの）バグの被害に遭いました。
Y2K問題は、プログラマーが年を2桁で保存することでメモリを節約しようとしたことが原因でした。これは、2桁の年号を節約することが相当な金額の節約になった数十年前であれば、完全に正当化された行為でした。2038年問題はより深刻で、Linuxだけの問題ではありません。
- 2038年のLinuxクロックポカリプスが迫っているが、「本格的な計画」はない
- 2038年以降も32ビットLinuxを使い続けるには？カーネルバージョン5.6がリリースされれば、素晴らしい体験が待っています。
- Linux 5.10は2038年問題を2486年問題にする
- 見逃していたかもしれない10のPCゲーム
Y2K問題と同様に、説明も修正も簡単です。UNIXは伝統的に、1970年1月1日からの経過秒数として時刻を保存していましたが、符号付き32ビット値で保持していました。つまり、2038年1月18日午前（UTC）の円周時7秒後、つまり「紀元」から2,147,483,647（2³¹）秒後、次の時刻は1901年12月13日午後20時45分52秒、つまり-2³¹になります。
Linuxやその他最近のUNIX系OSでは既に修正されています。簡単な方法は、64ビット値に移行して、どちらでも2920億年の範囲を確保することです。これで十分でしょう、豚野郎。
面白いのは、この（古くてずっと前から修正されている）MongoDBのバグのように、発生する可能性のある場所をすべて見つけることです。MongoDBは日付を正しく保存し、Pythonも日付を正しく保存しますが、日付は32ビット値を使用して互いに受け渡されていました。
年金基金に深刻な打撃を与えているこのTwitterスレッドもご覧ください。この件は延々と続くでしょう。でも、これを修正すれば、今後16年間、かなりの利益が期待できます。1週間程度の誤差はありますが。
iPlayerのバグについてBBCに問い合わせました。記事公開時点では説明が得られませんでしたが、説明が得られ次第、この記事を更新します。この問題について何か情報をお持ちの方は、ぜひこちらまでお知らせください。®
