2024/10/14 15:42
cinefuk
「LinuxなどのUNIX環境、C言語プログラムのUNIX timeで表現されたタイムスタンプ値が32bit符号付き整数型で定義されている場合、2038年1月19日3時14分8秒以降の時刻で整数オーバーフローが生じ」
2024/10/14 15:48
xlc
今年が「昭和99年」で今まさに昭和百年対策が佳境であることは意外と知られていないな。汎用機のCOBOLだけの問題だと思うけど。
2024/10/14 15:50
timetosay
就活でこれ聞いてみるっていうのはどうだろ。
2024/10/14 16:17
circled
直前になるまで動けない人間の怠惰な性格が一番ヤバいよね
2024/10/14 16:41
komo-z
2038年問題！ずっと先のことと思ってたけど数年以内に対策しないとヤバイ時期になってるのね！私が使ってる某ソフトウェア、対策してなさそうだけど大丈夫かな？
2024/10/14 17:03
napsucks
動いてるシステムは対策するか対策済みのものに入れ替えるから大丈夫だろうけど、過去のソフトウェア資産は時刻を戻さないと起動しないとかになりそうね。大規模なキャズムが発生することそのものが問題になりそう。
2024/10/14 17:13
ginga0118
毎度思うが昔の人ってアホなの？
2024/10/14 17:16
hobbiel55
当日は飛行機に乗るのは止めておこう。
2024/10/14 17:35
ducktoon
未然に防いでもなんの評価もされなさそうなのでほっとこう
2024/10/14 17:43
poliphilus
広く使われてる Laravel+MySQL でも Eloquent の created_at/updated_at が timestamp 型で、同様の問題が生じる。datetime 型に変更した方がいいが、タイムゾーン無視なので困る場合も
2024/10/14 18:04
versatile
こんな適当に急いで作ったプログラム数年もつかわんだろ、こんな適当なサービス数年もたんだろ、って作ったサービスだけが十年以上も使われる運命にあるという皮肉
2024/10/14 18:16
nezuku
2038年問題は異常を起こす箇所を探すのが難しいってのがそれまでの年問題との違いとしてありそう。 そして来年の昭和100年問題への対応が佳境にあったりするんだろうか。
2024/10/14 18:25
mohno
「「西暦2038年問題」。新たな論文が発表され、一般的に想定されているより広い範囲で大きな影響が出るのではないか」←あと13年ちょっとか。世界の終末を見る機会があるのかどうか。
2024/10/14 18:54
domimimisoso
寒そうな季節の火曜日の未明。夜中に暖房が切れても朝までしのげるようにその前の晩は布団と毛布をいっぱい出しておこう。
2024/10/14 19:33
commecco
社会インフラ系の会社に入って一年目のとき、「これだと2038年に耐えられないけど大丈夫ですかね」って上司に聞いたことを思い出した。上司は「俺はもうそのときにはいないから」って言ってたな
2024/10/14 19:35
rokusan36
軍事系に影響なければいいけど。。
2024/10/14 20:10
honma200
カーネル的にはLinuxは2038年対応してるのでOS的には問題なくてDBとかもアップデートでうまくいきそうな気がするけどIoTとか怪しいのではないか togetter.com
2024/10/14 20:21
matchy2
桁違いって32bitってことでしたか
2024/10/14 20:31
hibiki0358
10年以上先の、しかもIT系の話を｢ヤバい」とかいう方がよっぽどヤバい
2024/10/14 21:13
daibutsuda
組み込み系とか心理的安全性ゼロな世界でやっている人真似できんなと感心する。
2024/10/14 21:23
Chisei
とりあえずMySQLのテーブルにタイムゾーンを認知させる構造はやめた方がいい。タイムゾーン絡みの演算は別の機構で。
2024/10/14 21:50
legnum
昭和100年問題は2000年問題時点で平成がいたんだからついでに改修されてるでしょ。和暦使ってるの役所ばかりだし。ただoracleのパッチ当たってなくて平成36年になってるシステム今年見たから微妙ではあるな…
2024/10/14 22:04
GARAPON
まだ慌てるような時間じゃない
2024/10/14 22:17
aya_momo
自分が時間を使うのは疑似乱数くらいだと思うけど、シードが負になると困るのかな？
2024/10/14 22:42
srng
様々な事情でアップデートできないされてない組み込みシステムは山のように動いてるだろうしなあ
2024/10/14 23:13
spark7
その頃にはもうコード書く仕事はしてないので低みの見物である。
2024/10/14 23:45
tech_no_ta
組み込みに近い側にいるのでインパクトがデカそうなのが直感的にわかる…
2024/10/14 23:51
toro-chan
組み込みはよく分からないが、今やってるシステムでは特に気にしてない。LLはtime_tを生で使うことはないのでな。PerlでさえTime:Pieceか64bit time_tなので楽観的。低みの見物だな。。
2024/10/15 00:04
alt-native
“time_t型が64bit型ではないシステムは現在も数多く残っており” 例えが欲しかった。
2024/10/15 01:17
letra
直前というか記事にも書いてるけど今からn日後、とかでもオーバーフローするわけだから２０３８年にやっても手遅れなのよね
2024/10/15 01:35
crybb
人類は日付と時刻のカラムを分けるべきだったのでは？ 2038年問題を危惧する状況で時刻を気にするケースは少ないだろう。 タイムスタンプ型に比べてデータ量は増えるが、障害対応で発生するコストは無くなる。
2024/10/15 01:49
yamadar
これがジャッジメント・デイと呼ばれる日になろうとは、まだ誰も想像していなかったのだ...
2024/10/15 03:20
tonocchokun
この日がやばい、と思ってる人多そうだけどローン金利とかでとっくに出るとこでは出てる事はあまり知られていない
2024/10/15 03:32
grankoyan2
実装時型が無いからしゃーないってのと、どうせこんなシステム長々と使わんやろ？　ってのがあったんだっけ？　単体ではオーバーフロー（限界値）試験やってても…
2024/10/15 04:08
queeuq
PHPのtimestamp型が同じというブコメ。データ型変える前にとっとと64bit対応すればいいのでは・・・？/古のソースもないなんかよくわからないバイナリがうまく動いてる環境とかは恐怖だなぁ
2024/10/15 04:53
Tamemaru
でも1年前にならないと対策予算下りないんですよ
2024/10/15 06:03
yfukuda827
PHPerだけどけっこう対策必要。だけど2038年までシステムは生きて無さそう😅
2024/10/15 07:47
pigorilla
雇用が増えるから良かったじゃん。氷河期でもY2K要員で正社員になれたしありがたいよ
2024/10/15 07:48
dltlt
2000年問題を割と無傷で乗り切ったことが、社会にとって良くない学習になってそうだ。｜車載ソフトウェアで、昔のCのコードが未だ流用されてないだろうか？
2024/10/15 07:58
monbobori
1970年代には2038年は遠い未来だったのだろうか。扱えるデータ量が限られてたから仕方なかったんだろうな
2024/10/15 08:06
Windfola
"C言語は広いシステムで使われる上、『処理Aの●秒後に処理Bを行う』といった経過時間を扱うありとあらゆるシステムが対象" "日付の起点の見直しという非常に難しく重い作業" ただの遅延処理すら疑う必要あるのかあ
2024/10/15 08:26
JULY
2000 年問題の時もそうだったけど、十把一絡げでコンピュータで動くものはすべてヤバい、みたいな話が広まるだろうなぁ。問題なケースが存在するのは間違いないんだけど、それが大半を占める、みたいに。
2024/10/15 08:30
houyhnhm
昭和100年問題かなり対応されてないと思うよ。費用が湧くわけではないし、ミニマムで見積もる圧力はかなり高い。要件にない事やっても費用損するだけだしな。／テストしてなきゃ大丈夫かどうかも分からん。
2024/10/15 08:45
utsuidai
容易に更新とか交換が出来ない組み込み系は喫緊の問題だろうなぁ。
2024/10/15 09:28
k-holy
MySQLで考え無しにtimestamp型を使ってた人はハマるかもね…。PHPはまともな人はもうPHP7時代には DateTimeInteface 実装クラスに移行してるんじゃないの。金も掛けられないようなレガシーシステムは悲惨だろうけど。🙏
2024/10/15 09:54
cad-san
32bit版Linuxカーネルが2038年問題に対応したのもここ数年のことなので、古い機器は最新ハードに乗り換えるか、OSを最新化するか選択を迫られる
2024/10/15 09:54
toria_ezu1
"KDDIの一部システムは0.5秒単位で時刻を認識していたため、1秒単位で時刻を認識するのに比べて半分しか経過秒数を保持できず、1970年と2038年の真ん中に当たる2004年1月10日にオーバーフローが発生。"
2024/10/15 09:55
osaka_ajing
10年以上使われることがほぼない、webシステム系でよかったわ。
2024/10/15 10:57
xanaduuu
クラウドサービスプロバイダが対応してくれると楽なんかな。この問題、彼らにとって良いプロモーションになりそう。組み込み系は、、、頑張ってください。
2024/10/15 11:13
kiku72
“一部システムが2038年1月19日3時14分8秒以降の時刻になると誤作動を起こす可能性があるとされる「西暦2038年問題」。”
2024/10/15 11:19
hi6y
またいい感じのタイミングでリマインドしてくれや。今は何の関心もない。
2024/10/15 11:29
daishi_n
そりゃまあ、32bitアプリは現役だし、32bit intなtime_tを使ってる処理を洗い出すのは至難の業。OSの問題なら移行とアプリの再ビルドも必要なので簡単ではないね
2024/10/15 12:18
hideaki_kawahara
BMLもそうだけど、サテラ◯ューもそうだな、まあサテラ◯ューは消滅しているけど
2024/10/15 12:40
taguch1
2000年問題対応してる頃は38年もワンチャン対応しないといけないとは思わなかった。
2024/10/15 15:44
azumi_s
頑張れ10年後のみんな(そこに自分が含まれるかどうかは神のみぞ知る
2024/10/15 15:44
strawberryhunter
もう8年くらいしかないのか。弊社はそういうレガシーシステムとはつながりが無いので無縁。64bitへの再コンパイルで直ればラッキー、ファイルや電文に含まれるならレイアウト変更か。
2024/10/15 18:22
tetsutalow
記事にして頂きました。まだ時間があるとはいえ、インフラの入れ替えは本当に時間が必要なので、そろそろ真剣に心配しましょう。
2024/10/16 10:50
defiant
この記事をおすすめしました
2024/10/16 17:07
asakura-t
心当たりがあるのはMySQLのtimestamp型と、なぜかunixtimeでintに突っ込んでるヤツだな…／timestamp型は64bitに拡張されるじゃろと思ってたらそんなことはなかった（64bitなtimestamp2型とかあればALTERで済ますのに）