記事へのコメント59

    • 注目コメント
    • 新着コメント
    Cru
    Cru 少なくとも今世紀のシステム上で作ればもちろん大丈夫な訳だが、失われた30年のおかげでシステムのリプレースも進んでないだろからな。日本が世界で一番被害が大きくなるかも

    2024/10/19 リンク

    その他
    asakura-t
    asakura-t 心当たりがあるのはMySQLのtimestamp型と、なぜかunixtimeでintに突っ込んでるヤツだな…/timestamp型は64bitに拡張されるじゃろと思ってたらそんなことはなかった(64bitなtimestamp2型とかあればALTERで済ますのに)

    2024/10/16 リンク

    その他
    defiant
    defiant この記事をおすすめしました

    2024/10/16 リンク

    その他
    tetsutalow
    tetsutalow 記事にして頂きました。まだ時間があるとはいえ、インフラの入れ替えは本当に時間が必要なので、そろそろ真剣に心配しましょう。

    2024/10/15 リンク

    その他
    azumi_s
    azumi_s 頑張れ10年後のみんな(そこに自分が含まれるかどうかは神のみぞ知る

    2024/10/15 リンク

    その他
    strawberryhunter
    strawberryhunter もう8年くらいしかないのか。弊社はそういうレガシーシステムとはつながりが無いので無縁。64bitへの再コンパイルで直ればラッキー、ファイルや電文に含まれるならレイアウト変更か。

    2024/10/15 リンク

    その他
    taguch1
    taguch1 2000年問題対応してる頃は38年もワンチャン対応しないといけないとは思わなかった。

    2024/10/15 リンク

    その他
    hideaki_kawahara
    hideaki_kawahara BMLもそうだけど、サテラ◯ューもそうだな、まあサテラ◯ューは消滅しているけど

    2024/10/15 リンク

    その他
    daishi_n
    daishi_n そりゃまあ、32bitアプリは現役だし、32bit intなtime_tを使ってる処理を洗い出すのは至難の業。OSの問題なら移行とアプリの再ビルドも必要なので簡単ではないね

    2024/10/15 リンク

    その他
    hi6y
    hi6y またいい感じのタイミングでリマインドしてくれや。今は何の関心もない。

    2024/10/15 リンク

    その他
    kiku72
    kiku72 “一部システムが2038年1月19日3時14分8秒以降の時刻になると誤作動を起こす可能性があるとされる「西暦2038年問題」。”

    2024/10/15 リンク

    その他
    xanaduuu
    xanaduuu クラウドサービスプロバイダが対応してくれると楽なんかな。この問題、彼らにとって良いプロモーションになりそう。組み込み系は、、、頑張ってください。

    2024/10/15 リンク

    その他
    osaka_ajing
    osaka_ajing 10年以上使われることがほぼない、webシステム系でよかったわ。

    2024/10/15 リンク

    その他
    cad-san
    cad-san 32bit版Linuxカーネルが2038年問題に対応したのもここ数年のことなので、古い機器は最新ハードに乗り換えるか、OSを最新化するか選択を迫られる

    2024/10/15 リンク

    その他
    toria_ezu1
    toria_ezu1 "KDDIの一部システムは0.5秒単位で時刻を認識していたため、1秒単位で時刻を認識するのに比べて半分しか経過秒数を保持できず、1970年と2038年の真ん中に当たる2004年1月10日にオーバーフローが発生。"

    2024/10/15 リンク

    その他
    k-holy
    k-holy MySQLで考え無しにtimestamp型を使ってた人はハマるかもね…。PHPはまともな人はもうPHP7時代には DateTimeInteface 実装クラスに移行してるんじゃないの。金も掛けられないようなレガシーシステムは悲惨だろうけど。🙏

    2024/10/15 リンク

    その他
    utsuidai
    utsuidai 容易に更新とか交換が出来ない組み込み系は喫緊の問題だろうなぁ。

    2024/10/15 リンク

    その他
    houyhnhm
    houyhnhm 昭和100年問題かなり対応されてないと思うよ。費用が湧くわけではないし、ミニマムで見積もる圧力はかなり高い。要件にない事やっても費用損するだけだしな。/テストしてなきゃ大丈夫かどうかも分からん。

    2024/10/15 リンク

    その他
    JULY
    JULY 2000 年問題の時もそうだったけど、十把一絡げでコンピュータで動くものはすべてヤバい、みたいな話が広まるだろうなぁ。問題なケースが存在するのは間違いないんだけど、それが大半を占める、みたいに。

    2024/10/15 リンク

    その他
    Windfola
    Windfola "C言語は広いシステムで使われる上、『処理Aの●秒後に処理Bを行う』といった経過時間を扱うありとあらゆるシステムが対象" "日付の起点の見直しという非常に難しく重い作業" ただの遅延処理すら疑う必要あるのかあ

    2024/10/15 リンク

    その他
    monbobori
    monbobori 1970年代には2038年は遠い未来だったのだろうか。扱えるデータ量が限られてたから仕方なかったんだろうな

    2024/10/15 リンク

    その他
    dltlt
    dltlt 2000年問題を割と無傷で乗り切ったことが、社会にとって良くない学習になってそうだ。|車載ソフトウェアで、昔のCのコードが未だ流用されてないだろうか?

    2024/10/15 リンク

    その他
    yfukuda827
    yfukuda827 PHPerだけどけっこう対策必要。だけど2038年までシステムは生きて無さそう😅

    2024/10/15 リンク

    その他
    Tamemaru
    Tamemaru でも1年前にならないと対策予算下りないんですよ

    2024/10/15 リンク

    その他
    queeuq
    queeuq PHPのtimestamp型が同じというブコメ。データ型変える前にとっとと64bit対応すればいいのでは・・・?/古のソースもないなんかよくわからないバイナリがうまく動いてる環境とかは恐怖だなぁ

    2024/10/15 リンク

    その他
    grankoyan2
    grankoyan2 実装時型が無いからしゃーないってのと、どうせこんなシステム長々と使わんやろ? ってのがあったんだっけ? 単体ではオーバーフロー(限界値)試験やってても…

    2024/10/15 リンク

    その他
    tonocchokun
    tonocchokun この日がやばい、と思ってる人多そうだけどローン金利とかでとっくに出るとこでは出てる事はあまり知られていない

    2024/10/15 リンク

    その他
    yamadar
    yamadar これがジャッジメント・デイと呼ばれる日になろうとは、まだ誰も想像していなかったのだ...

    2024/10/15 リンク

    その他
    crybb
    crybb 人類は日付と時刻のカラムを分けるべきだったのでは? 2038年問題を危惧する状況で時刻を気にするケースは少ないだろう。 タイムスタンプ型に比べてデータ量は増えるが、障害対応で発生するコストは無くなる。

    2024/10/15 リンク

    その他
    letra
    letra 直前というか記事にも書いてるけど今からn日後、とかでもオーバーフローするわけだから2038年にやっても手遅れなのよね

    2024/10/15 リンク

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック!
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    「2038年問題」が2000年問題と比べ桁違いにヤバい…社会インフラで障害も

    「gettyimages」より 一部システムが2038年1月19日3時14分8秒以降の時刻になると誤作動を起こす可能性が...

    ブックマークしたユーザー

    • Cru2024/10/19 Cru
    • akishin9992024/10/16 akishin999
    • funaki_naoto2024/10/16 funaki_naoto
    • asakura-t2024/10/16 asakura-t
    • ChillOut2024/10/16 ChillOut
    • k_oshima2024/10/16 k_oshima
    • defiant2024/10/16 defiant
    • yug12242024/10/16 yug1224
    • yuki0321kun2024/10/16 yuki0321kun
    • nishitki2024/10/16 nishitki
    • mazuizm2024/10/16 mazuizm
    • wushi2024/10/15 wushi
    • ken31542444362024/10/15 ken3154244436
    • dhrname2024/10/15 dhrname
    • tetsutalow2024/10/15 tetsutalow
    • pikopikopan2024/10/15 pikopikopan
    • azumi_s2024/10/15 azumi_s
    • strawberryhunter2024/10/15 strawberryhunter
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事