【ヤバすぎ】2038年問題再び!32bitシステム死亡のお知らせwww

挿話
今日知ったこと:2038年問題という、もう一つのY2Kがある。これは、時刻処理に32ビット整数を使うシステムが、64ビットに更新されないと致命的なエラーを起こすというものだ。

どんな話題?

2038年問題、ご存知ですか? 「Y2K問題」を覚えている人もいるかもしれませんが、今度は32ビットシステムのUnix時刻がオーバーフローする「Y2K38問題」が迫っています!

1970年1月1日0時0分0秒からの経過秒数を32ビットで記録するシステムでは、2038年1月19日3時14分7秒に上限値を超え、システムエラーが発生する可能性があるのです。 これは、JavaScriptのような古くから使われ続ける言語や、Unix系システムデータベースなどに深刻な影響を与えます。既にいくつかのシステムではエラーが発生しているとの報告も…。

私の調査では、多くのシステムが未だに32ビット環境で稼働していることが分かりました。まるで時限爆弾💣が仕込まれているかのよう…。 さらに、64ビットへの移行は、単なるOSのアップデートだけでは済まないケースも多く、ライブラリの更新なども必要になるそうです。 多くの企業は、Y2K問題の教訓を活かし、対策を進めているものの、老朽化したシステムメンテナンス不足の問題も懸念されます。 2038年まであと15年余り。大丈夫でしょうか?

まるでSF映画のような話ですが、現実の問題です。私たちはこの「Epochalypse(エポック終末)」と呼ばれる事態を、どう乗り越えるべきなのでしょうか? 今から対策を始めるべきだと痛感します。


みんなの反応


64bitシステムだと約2900億年後に同じ問題が発生するってよww 今からITシステムの準備始めといた方がいいんじゃね?
そんなの1998年にY2Kバグ直した時に既に準備済みだわw
笑えるのは、Y2Kを知らないITのプロが今働いてるって事だよな。あのクソ面倒くさかった時代を知らん奴ら、マジで羨ましいわ。
2035年くらいから心配し始めないとダメだな。
エポック・フェイルwwww
Y2Kの時はITで働いてたけど、2035年には引退してるはず!(願望)
ふーん、まだ30年も先の話じゃん。
Y2Kって「year 2000」の略だったんだよな。
(補足:1995年12月に初めて実装されたJavascriptは、2桁の年を「西暦-1900」で返す2桁の年関数を持ってた。だから2001年は「101」になる。4桁の年関数は「2桁の年の前に’19’を追加する」って定義で、2001年は「19101」になる。はい、2000年よりたった4年前にリリースされた、そしてその後最も広く使われる言語の1つになる言語で、こんな事やってたんだよ。このわけわからん挙動は、その挙動に依存するレガシーアプリケーションを壊さないように、今も残されてる。ちゃんと動く2つ目の関数セットも追加されたけどね。
2004年から稼働してる大型国際科学実験で働いてて、2035年まで延長されたんだけど、使ってるソフトウェアの一部は未だに同じものなんだよね。Unix時間にも heavily depend してるし… でも2035年までしか延長してないんだよね😅 2035年に終了するかどうかを決める上で、これがどれくらい大きな役割を果たすのか…気になるわ。
スペインが昨日テストランやってたぞ。時計を2039年に設定して、万事OKか確認してたみたいだ。
PCの空きスロットに挿せるカオスからPCを守るカードを用意しとくか。
2038 =1970+((2^31 )/60/60/24/365)
ビット戦争は続く…!
緊急告知!2038年1月18日午後11時にはCompaqコンピュータの電源を切ってください!!
まあ、その頃にはコンピュータが自我に目覚めて自分で直してくれるだろうさ。
去年仕事でこの問題に遭遇したわ。Javaで動いてるETLツールが、起動時に読み込む隠しファイルのタイムスタンプを、起動するたびに更新するようになっててな。しかも信頼性も低くて何回も再起動するし、複数のインスタンスが実行されてたりして… 結局10年くらい経ってそのファイルがエポックリプシスに到達してオーバーフローして、「負の時間」エラーが出て起動しなくなったんだ。ベンダーも巻き込んで丸1週間かかったわ。
つまり、Windows XPで動いてるATMとレジ全部クラッシュするってこと?
今回は直さない。Y2Kの戦場で十分苦労したからな。
………もういいや。このタイムラインの話は終わりだ。*荷物をまとめて帰宅する*
(簡単に説明すると)コンピューターは、1970年1月1日0時からのミリ秒数を数えて内部的に時間を管理してる。「エポック時間」ってやつだ。これは32bitの変数型「int」として格納される。2038年には、あまりにも多くのミリ秒が経過し、「int」のサイズ制限を超える(オーバーフロー)ことになる。
64bit OSに移行するだけじゃダメで、ライブラリも更新する必要がある。64bitのライブラリでも、datetime関数は内部的に32bitのままの場合があるからな。
ジョン・タイターのタイムトラベル野郎が今必要な時に限ってどこにいるんだ?
幸いなことに、InatechにはPeterが展開を担当してる。TPSレポートに表紙を追加する必要があるだけだ。
#2034年問題 #巨大CME問題
32bitのUnix時間だけど、2070年までには尽きないらしい…
ま た か よ !
例えば、タイムスタンプを保存するために通常は整数型、サイズ11を使うよね。2038年までにタイムスタンプはサイズ12になる。間違った日付にオーバーフローして、当然問題を引き起こす。
この問題の計画が始まる前に引退してるから安心だ。
エポックリプシス
その頃には引退してるか死んでる☠️
ジョン・タイターが直す予定だったのはこれのことじゃなかったっけ?
本当のやっかいな点は、UnixとSQLが時間をこうやって数えてるってことだ。
2K38って2038の略し方、なんか変だなw
それって2037年の問題じゃね?
でも、その頃には全てのシステムがスカイネットに制圧されてるんじゃね?
なんでY2Kはそんな大問題だったの?

コメント