【システム】コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす

いわゆるコンピュータの“西暦2038年問題”といわれる事象が日本で発生し、日常生活に影響を与えたことが明らかになった。
2038年問題による日常生活への影響が確認されたのは、世界でもほぼ初めて。コンピュータの西暦2038年問題とは、
C言語を使って開発したシステムをUNIX環境で利用している場合に、グリニッジ標準時の2038年1月19日3時14分8秒を過ぎると、
システムが正しく時刻を認識できなくなる問題を指す。UNIX環境では、システム内部の時刻を
グリニッジ標準時1970年1月1日0時0分0秒からの経過秒数で保持している。経過秒数で表す時刻データに、
4バイトの符号付き整数を使っている場合には、2038年1月19日を過ぎると、本来数字の正負を判断するために使う部分まで
時刻を表示するために使わざるを得なくなる。その結果、正しい時刻を認識できなくなるのである。
2038年問題による影響はすでに広く報道されている。1月11日に23行の銀行でATMが一部の取引で
正常に利用できなくなったトラブルの原因が、この2038年問題によるものだった。
この問題が起きた銀行はいずれも日本IBMのソフトを使っていたが、このソフトの内部に、
時刻の2倍に足し合わせる処理があり、ちょうど1970年と2038年1月19日の2分の1を超えた2004年1月11日の朝から、
2038年問題が顕在化して、システムが正常に稼動しなくなった。

http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040202/139212/

2ダ？

2get!

すんげ・・・・

あれはそんな理由だったのか・・・。
なぜ二倍する必要があるんですかねぇ

日本ＩＢＭ駄目ぽ。
北城駄目ぽ。

このATMって何使ってるんだろうね
AIX？　それともLinux？

２０００年問題は空騒ぎだったけど？
今度はほんとなの？

>>8
あれは個々のソフトのアンポンタンさによるものだから大抵大丈夫だった。
今度は OS に起因するものだから不可避。

Ｙ２Ｋ（＜なつかしい）の時のアンケート

「Ｑ１　御社は2000年問題に対応していますか」　＞　いや、うち手作り食品だから
「Ｑ２　製造ラインが止まったらどうしますか」　＞　いや、だからそんな上等な機械はないから
「Ｑ３　印字系システムは万全ですか」　　＞　日付も判子だっつうの
「Ｑ４　出荷のシステムは万全ですか」　　＞　伝票も請求書も手書きだから。計算も電卓だから。
「Ｑ５　ほかに関係事項がありましたら．．．」　＞　ごくろうさまです。

>>9
あれもOSに起因するものだったんだよ。
しかし、大きな問題にならなかったのは問題を起こすOSが既に
使われていない場合が多かった事と、事前に問題を検地する各種ツールが
出回りチェックや修正をしたから大きな問題にならなかった。

今回も、2038年の時点では今使っているOSも世代交代してるだろうから
その時は大丈夫だと思うけど、今回のように先に進めて計算するロジックが
あるとやばいかもね。

これって 2038 年問題じゃないと思うけど。

しかし 2038 年までに time_t が 64bit になっている
OS が普及するのかな、問題回避の困難さは 2000
年問題の比ではないんですけど。

ごめん、もう少し具体的に判り易く説明して。

>>11
>あれもOSに起因するものだったんだよ。
ﾍｪﾍｪ

64bit化すればほぼ無制限に使える
１秒刻みどころか
1/1000秒刻みでも到底使い切れないYO

対応は30年後くらいからかな、
漏れは定年退職してるからいいや。

30年もすればいろいろ変わるさ、なんとかなるよきっと。

そうか localtime は 1900 引いてたな

まだ誰も気づいていない2004年問題とかってないのか？
ちと不安・・・

>>8
空騒ぎっつーか対応ﾃﾞｽﾏｰﾁが多発した結果です、はい

>>8
空騒ぎじゃねーよ。
名も知られぬ多数のエンジニアがどんだけ不眠不休の対応したことか。
だから大事が起こらなかったんだよ。

つかスレのURLにある1075781325ってのがそもそもlocaltime秒だったような。
２０３８年まで２ちゃんねるがあるかどうかは別として。

ATM動いているんだから、もう問題解決できてるんでないの

大変です！うちのトイレが詰まりました

俺の電脳もｱﾎﾞｰｿだな。

>>10
で、電卓が使えなくなってたら笑ったんだけどな。

なんとか問題、もうおなか一杯！

そういえば今年もうるう年だな。
前の会社でやったなんちゃって2000年問題対応がやばいな。

もう関係ないから良いけど。

人工衛星が墜落して、原子力発電所が大爆発するのか？

>>28
2chの新規スレッドが立たなくなる。

>>11
C言語とは違うの？

人間ってアホだね

>>30
ん？　C言語特有の問題だったかって意味？
違うよ。

汎用機の場合は、メモリやデータ領域を節約する為に西暦を２桁表示する
事が（大昔は）一般的だったから、00と2000の区別の問題が発生。
パソコンなんかの場合は、言語に関係なくシステム関数として日付を２桁で処理し
てたけど、内部で４桁持って、しかし00年を1900年と処理する問題が発生。

どちらにしても、00年が99年よりも前になるので様々な問題が発生されると
予想されたって事です。

>>32
ああごめん、２０００年じゃなくて２０３８年の方。

>>33
違う
UNIX系の日付関連のデータの持ち方の問題
その証拠に、Perlで動いてる2chもこのまま使い続けたら障害が出ます。

>>34
�dクス

>>1
日付を倍にしてオーバーフローって、どんなんだよ。。。

30年も先のことなんてどうでもいいよ。

問題が起こったら直せばいい。それだけじゃん。

>>37
そういって、２０００年問題は起きました

1999年当時に、10数年前のPG組んだ奴が残っていて、当時は2000年まで
動くなんて思っていなかったし、気にもしなかったという事を、誇らしげいうので
マジで殴りたくなった

2007年だか2014年だかに起きると言われてる問題は大丈夫なんだろうか。
それはDWORD型の限界とか何とか言ってた気がしたけど。

2038年問題はわからないでもないけど、
2000年まであと数年というときに作られたソフトが2000年問題を起こした
のには、呆れるしかないな。
おまえら馬鹿か、と。

>>39
けどこういう糞PGが残っているおかげで更新作業という仕事が出てくるわけで。
折れ的にはありがたいな。
今後もこういう風にどこかにミスを残したままのプログラムってのはあり続けるんだろうな。

2038年には淘汰されるか

2038年ってまだまだ先だね。
やっぱり今のスパコン以上のものが家庭のＰＣで楽しめる時代なのかな？

ってか2038問題はもう始まってるのか・・・。

まったくこゆうコストが永遠かかるなぁ。。
うちに来た会社も２０００年問題も一週間で終わる作業を一ヶ月もかけるし
　完全にやってないし。。

おまえら疫病神か。。

>>10
そういえば手書きの帳票で、日付を書く欄が
「１９　　年　　月　　日」
と印刷されていて、「あー、この帳票、2000年問題対応してねえ」と
思った記憶がある。

以前、Perlのlocaltime関数では月の値が0〜11なのを1〜12と勘違いして組まれたCGIが、夏に納品されてて12月になった瞬間に止まった、という間抜けなものを見たことがある。

確かどっかに2000年問題対策のページがあったんだけど、
そこのカウンタ壊れてたよ。2000年問題の影響で。
あれには笑ってしまった。

ｺﾝﾆｬｸ

確かどっかに2000年問題対策のページがあったんだけど、
そこのカウンタ壊れてたよ。2000年問題の影響で。
あれには笑ってしまった。

ｺﾝﾆｬｸ

ウチの会社に起こった２０００年問題
２０００年１月の給与明細が、
「１９９９年１３月」
となってた。
苦笑するしかなかった・・・

まだ大丈夫とお考えになっている糞PGの方々へ。

住宅ローンの返済なんかだと、ずーいぶん先の日付で計算する必要があったりしないのかい？

==========ひたすら自作自演あらわる。（痛すぎ）===========
http://school.2ch.net/test/read.cgi/shikaku/1053458042/
http://school.2ch.net/test/read.cgi/shikaku/1052906008/

橋下弁護士スレッドと北村弁護士スレッド
に現われた彼。名前　ミイチャン　ＩＤ　bkvMI33u
ＩＤとメール欄が全く同じなのに
自作自演を繰り返し（一目でわかる）
必至で取り繕ってるイタィ香具師が出現しました。

これは満足していただけると思います。
すさまじい痛さをお召し上がりください。

Y2K問題に乗じて借金なんかを抹消してくれる機関があったそうだよ。

64bit対応OS のSolaris9にすればいいの？

>>10
ウチの事務が正にこれ。

OSやＣＰＵが一度に何千億bit処理出来るものだろうと時間を4バイトの符号付き整数で表現してたら意味無し

なんで時刻を２倍にしてたの？

[linux-users:70300] y2k+4 problem.
http://search.luky.org/linux-users.7/msg00300.html

>y2k問題も無事に過ぎ2038年問題にはまだまだ先
>ですが、もうすぐ2004年問題が起こりそうです(?)

>>57
なんでだろうね
まさか、暗号化関係でランダムの基数の数字を出したくて、現在日付を2倍したとか
だったら、思いっきり笑うんだけど・・・

NTP（Network Time Protoco）とかで中にはﾏｽﾞ!!があるってこと？

時刻＋1bit の情報を作ろうとして、
最下位bit に意味を持たせるためにそうしたとか・・
そうとう無知でないと不用意にそんなことしないか？

２０３７には仕事がまわってくるのか　それまで仕事してないな　(´･ω･`)

Windows95/98が現役でいる限り、
2001〜12年問題に追われ続けます。

9月9日問題もLinuxだけの問題かと思ったら、
WindowsMeでも発生。他人事ではない。

2000年問題で一番残念な結果になったのは
EOSystemの大部分の機能が使えなくなったこと…
('A`)

>>65
９８年ころより前のデジカメの日付機能は大半があぼーんだったね

IBMの銀行ﾄﾗﾌﾞﾙってﾀｲﾑｱｳﾄしてた処理が原因でその処理を外すことは簡単だ
って言ってなかったか？
まあ、よくよく解析してみたら違ってたってことかｗ
登録時刻をATMとｻｰﾊﾞの中間時刻とかにしてたﾌﾟﾛｸﾞﾗﾑのﾊﾞｸﾞだったのかなｗ

こわい,こわい

レスされたスレの番号をlocaltimeと比較、あまりにも差が大きかったら上げ荒らし判定
→2038年に、新規にたったスレにレスしようとしたら自動アク禁者続出、とかｗ
まあこんなアホなことは起こらないと思うけど。

2038年には死んでると思うから関係なし。

>>69
寿命か？
いまいくつだよ？

ところで
「２ＫＹ問題」はだれも語らないのですか？

>>69
それ以前に、日本が日本州か日本省になってる悪寒

Y2Kがものすごく昔に感じるな。
社会がマヒして、最悪ミサイルが飛んでくるかも！なんて騒ぎ立ててた評論家もいたっけ・・・・

Ｃは不滅さ・・たてえムーアの法則が崩れたとしてもＣだけは生き続けるのら。

2038年問題の対処は一般にtime_tの64bit化で済むはず。
再コンパイルのみ。
2chなんかは Perlを対応版に入れ替えるだけでOK

ま、おいらは死んでいるからいいや♪

>>50

旧暦使ってるなんてなんて風流

>>71
２１世紀の日本人の記念碑になるに違いない。百年単位で育ってきたものを、
瞬時に傷付けて恥じない、精神の貧しさの、すさんだ心の。
にしても、いったい２ＫＹってだれだ。

MSのサイトの"20000年問題"も懐かしいね。
って、誰も覚えてないですか。
そうですか。

win2000は2099年まで日付が設定できるね。

皇紀にしとけばこんな問題は起きなかったのに。

さすがに３０年は使わないと思うけど、２０年ぐらいなら平気で使い回しそうなので、
今からリプレースに着手しないと大変な事に…

おっと言い忘れ
2chってPerlで動いてるの？C言語だと思ってたのだが
転送量とか実行速度とかいろいろ困ってるのにPerlはないだろうと思うのだが

まあ、RFC2550ぐらい読んでおけと
http://www.ietf.org/rfc/rfc2550.txt
http://www8.ocn.ne.jp/~yama-b/rfc2550j.txt

・サルにしかわからない2038年問題、もといサルでもわかる2038年問題

パソコンを使えば、何兆、何億の計算も可能だ。もっとでかい数ももちろん計算できる。
しかし、計算が出来ることと実際に計算することは別物だ。

普通メモリは節約して使われる。計算にはメモリの機能を使う。
パソコンを使えば、でかい数の計算も出来るが、あえてメモリを節約するために、パソコンには2038年までしか
使いませんと、宣言する。それが上でもでてきたtime_t関数だ。

別に何千年さきまででもパソコンは扱えるがメモリの節約のためにあえて2038年までしか使わないと宣言したのだ。
だから2038年を超えると時間を正確に表せれなくなる。
時間は時間を表示するためだけに使われているわけでなく、ランダム関数の種やら、お金の計算やら色々使われて
いる。だから時間を表示できないという問題は、それ以上に深刻なのである。

ちなみに時間は>>1にもあるように1970年から秒単位で計算されている。単純に計算すると、2004年1月1日は
（34年*365日*24時間*60分*60秒）である。補足よろ

No Problem!
ノー　プロブレマ（タガログ語　講座）

P.S
ダイブージ（大丈夫じゃ〜ぁない！）

WindowsならOSのアップデートで簡単に対応できる。

Windowsは30828年問題がおきるからおまいら気をつけろ。

まて、日本は西暦ではなく皇紀を採用して、2004年を2664年にすればいいだけじゃん。

どっちも伝説上の話だからさ

[linux-users:70300] y2k+4 problem.
http://search.luky.org/linux-users.7/msg00300.html

>実行結果:
> t1: Sat Jan 10 22:37:04 2004
> t2: Sat Jan 10 22:37:06 2004
>ave1: Mon Dec 23 19:22:57 1935 <-これが変。
>ave2: Sat Jan 10 22:37:05 2004

ほぼピッタリ。１月１０日２２時３７分に予想されていて、今回のは１月１１
日の朝に問題が生じている。

後30年とかいって奴もいるけど、
住宅ローンの計算とか数十年先の日付使うからな。
利息計算おかしくてもしらんぞ。

>>46
同じようなのに

「H　　年　　月　　日」

って言うのがあるね（＾＾；

コレも、いつ変わるか判らないから結構嫌な感じ・・・陛下・・・長生きしてください。

>>90
こりゃ見事ですな。

たしかtime関数のほとんどはinlineだから
単にOSのライブラリをちょいと交換すれば解決するっていう
甘い問題じゃなかったと思う。

全てのソフトにおいて再コンパイルが必要。

>>94
データファイルや、データ通信のプロトコルやフォーマットもね。

2038と新元号切り替え、どっちが先かな？

>>92
俺の作ったソフト、
年号が変わるという万が一の自体に裏技で対応できるようになっているのだが
考えてみるとそれって不敬かもしれない。

部屋に転がってる9821の時計が毎回2053年にﾘｾｯﾄされまつ。

デジキャラットのなんかのソフトが、２０００年問題で誤動作してたような。

会社の経理システムは西暦から和暦に変更して対処。
何も問題なし。
いまの天皇陛下にはぜひ長生きしていただきたい。

>>100
それって、例えば40年以上なら昭和とか、40年未満なら平成って判断してる？
それとも、昭和のデータは残ってないから無視？

Y2Kよりは面倒そうだな

2038年・・・定年が70歳にでもならん限りはただのヂヂィだな。
職業はIT関連だし、いったいどうなっているのやら。

うちの会社で古いバージョンのエクセルに打ち込んでいる時刻データは、よく見ると
「１９００／〜」と表示されている。
２０００年問題を知らない新人に「これが２０００年問題だ」というと、みんな感心する。
ま、ワープロとしてしか使っていないから全く実害は無いが。

しかし、不動産業界の２００３年問題は、かなりダメージがあったようだな。

一度変数に移してたりすると、time_tを64bit化しただけじゃﾀﾞﾒﾎﾟ。
リコンパイルする前にソースのチェックが必要･･･大変な事になりそう。

>>101

そうです。
扱っている商品の性質上4年以上前のデータいらないので破棄しています

特需が来るというわけですね？

>>105
２次的に他の変数や構造体に入れたりしてると確かにやっかいっすよね・・・
(特に古い)ハードウェア的には時刻ってどこまで表現できるんだろう。

たぶん年金とか30年国債の計算がエラー？

int time
↓
unsigned int time
これだけで解決。

ちょうどイイや！全部Linuxに変えてしまえ！

2038年問題はWindowsOSの問題だから！

ま、あとの事はあとで考えようや。
そんな先の事どうなってるかわかんねえし。


…という感じだったんでしょうか？

でも、Y2K問題にしろ、2038年問題にしろ、Y5B問題に比べたら可愛いもんだ。
どんなに頑張ってもまず間違いなく不可避だし、人類は必ず滅ぶしな。

>>111
Linuxも同じ問題抱えているんですけど……。
っていうか、事情はLinuxの方が深刻かも。

virtualPCのようなものでシュミレーションして確認できれば前もって対策が
できそうだけど。でも大変。

>>111
知識がないのはまあいいとしても、せめてログぐらい読んでから書けよ

Y2K問題って、携帯がかからなくなったアレだろ？

オームショップのこと

>>115
日付を変えるだけで・・・・
Y2Kの時もそうしましたけど

2000年問題の時にあれだけいったのに無視するからだ。

主要OSは１０年も前大半が64ビットに移行しているから統一規格さえ出来れば切り替えは容易。
なのに、ミドルウエアやら、ファイアーウォールやらの64bit対応が遅れ、未だに32bitOSで有る某MSが
規格策定の邪魔をしていたと聞くが。。。Itanumの遅れも某MSに気兼ねして開発送れたらしいね。

時間に関する緒元は、最低限でも現在を挟んで４５億年前〜４５億年後
ぐらいのスケールでサポートしないとダメだよな

まあ、２０年前のPCやシステム使うのなんて通常の水準ではレトロヲタしかいないからいいよ別に
会社？システムに予算けちってんじゃないよ

あ

®®®®®®

>>123
Y2Kになる前の1980代もそういってたそうだよ
そして、ハードはリプレースで代わって逝ったけど、プログラムは
残っていた

>>126
会社？システムに予算けちってんじゃないよ

２０００年問題のプログラムの不都合を
必死でかきかえた１９９９年の記憶がよみがえってきた。

>>15
64bitsだと0.01秒刻みで±２９億年分サポートOK。もっとも秒刻み細かくしたいなら、128bitsにしないといけないな

しかし何１０億年と言うスパンになると、太陽の公転周期と原子時計がはじき出す秒との微妙な計算誤差が問題になってくるのではなかろうか
あとグレゴリオ歴の妥当性とか（せいぜい何万年しか使えない？）

http://www.google.co.jp/search?hl=ja&inlang=ja&ie=Shift_JIS&q=50%89%AD%94N%96%E2%91%E8+2000%94N%96%E2%91%E8+2038%94N%96%E2%91%E8&lr=
http://www.linux.or.jp/general/year2000.html

>>20
風の中の昴〜♪

>>21
総入れ歯、２ちゃんねるの過去ログ総容量ってどれぐらいなんだろう？
SATA 300GB \25,000ぐらいに収まる？

2038年問題に救世主登場！！

http://codepure.s18.xrea.com:8080/upload/img/019.jpg
http://codepure.s18.xrea.com:8080/upload/img/020.jpg

>>130
ときどき閏秒とかで調整してんじゃないの？

>>133
http://www1.odn.ne.jp/mimizun/spec.html

問題は、2038年以降の事まで考えて計算する処理が必要な場合、対処は今すぐやらなければならんと言うことだ
でもって対処が必要になるシステムの数は2038年に近づくほど増加する。

スラッシュドット ジャパン | 明日でepochから2^30秒
http://slashdot.jp/articles/04/01/08/172200.shtml?topic=80

Linuxだっだそんな変な問題おこらなかったのにね。

関係あるから乗っけとくね！
2004/02/10 17:02:00
Longhornまでの空白の2年。MSはどう乗り切るか
http://www.itmedia.co.jp/enterprise/0402/10/epic01.html

テスト不足

お　前　ら　な　、　販　売　中　止　如　き　で　普　段　来　て　な　い　吉　野　家　に　来　て　ん　じ　ゃ　ね　ー　よ　、　ボ　ケ　が　。

テスト条件を考えるのもしょせん人間だしな。
無駄なテストのしすぎで開発コストが上がれば
やって行けなくなる。

すでに日本特有の2004年問題に追われてます。
4月1日から始まる「総額(内税)表示」のことですが。
金額計算を扱うシステムの開発者は大パニック。
当日前後は不眠不休体制を取るところも多いでしょう。

ユーザーからは「2000年問題でシステムを変えたばかり
なのに、また変えろと？　無償でやれ！」と非難囂々。
せめて市町村合併が一段落する来年4月以降にして
ほしかった、というのが開発者の本音です。

>>144
マスタで内税、外税、無税とフラグ持たせてなたっかのか？

>ちなみに時間は>>1にもあるように1970年から秒単位で計算されている。単純に計算すると、2004年1月1日は
>（34年*365日*24時間*60分*60秒）である。補足よろ
　うるう年くらいは入れておいてくれ。（補足）

>同じようなのに
>「H　　年　　月　　日」
>って言うのがあるね（＾＾；
>コレも、いつ変わるか判らないから結構嫌な感じ・・・陛下・・・長生きしてください。
　2月に祝日はいらない。・・・陛下・・・長生きしてください。

>すでに日本特有の2004年問題に追われてます。
>4月1日から始まる「総額(内税)表示」のことですが。
　これはプログラマーのボケだろ。今現在使用されている表示法に対応させなかったのか？

>>143
人手に頼ってテストしているようなソフト会社は早々にあぼ〜ん
ソフトのテストは自動的にソフトウェアでするのが当然

>>147
そんな物使っても条件設定するのは人手

>まあ、２０年前のPCやシステム使うのなんて通常の水準ではレトロヲタしかいないからいいよ別に
>会社？システムに予算けちってんじゃないよ
無職の発想だな。

>>149
そっとしといてやれｗ
コンピュータシステム＝パソコン並と思っているみたいだから。

>人手に頼ってテストしているようなソフト会社は早々にあぼ〜ん
>ソフトのテストは自動的にソフトウェアでするのが当然

世間知らずな発想だな。

>>145
大抵のシステムは税率同様、内税・外税の区分も持っています。
指定日以降の税率アップを事前に登録する機能も備えています。
しかし内税・外税の「一括」変更は盲点でした。

現行では3月31日の閉店後から4月1日の開店前に、業種によっては
数百〜数千件もある商品マスタを1件ずつ変更するしかない、という
システムもあるのです。この手間を省くためには・・・

全商品の単価を一括で5%アップさせ、かつ外税から内税に更新する。
これを指定日以降適用できるよう、事前に登録する機能を追加する。
口で言うと簡単ですが、開発者は血の涙を流してます。 ( ┰ ┰ )

>>152
それは開発者というか営業は糞なだけでは？
マスタの管理は完全にユーザー側の所掌範囲なわけだから、それを効率的に
するための相談がきたとしたら、それは別途だろ？

それに、このパターンならマスタを1週間くらい前にバックアップを取り、一括更新の
ツールを一本組んで、それを反映させた物と置き換えるだけじゃだけなのか？
マスタを変えると、問題が出るのもあるだろうから、俺だったら一括変換じゃなく
既存のマスタに新規レコードとして内税にしたものを予め登録させるね。
色んな面を考えると、外税で計算した製品と内税の製品は別なものと考える
方が良くないかい？

小泉くんと、愉快な仲間達＆イラクへ派遣された方々と、派遣されなかった方々へ

http://hobby.2ch.net/test/read.cgi/engei/1076024713/56-

よく読め。
ゲリラと戦う極意だ。

ぶっちゃけた話し。
ゲリラ戦に勝つためには、ゲリラを含めた全てのアラブ人の味方になれ。

619 名前：全国で他行カード使えず 投稿日：04/02/10 12:02 ID:kKBxOvvK
全国の金融機関をまきこんだ他行カードが使えないというトラブルはIBMRS6000UNIXの2038年問題と全銀システムのNTTデータのシステムのダブルチョンボらしい。よく取り付け騒ぎにならなかったもんだ。

>>149
>>151
そんなこったからいつまで経っても永久にシステム屋のデスマーチが終わらないワケだが。

国が糞なだけだろ。内税にするのは税金アップを国民の目から伏せるため。
国民が正しい納税意識を持つには外税が正しい。

>>156
いつまで使うかわからないシステムに余計な工数使うのは、
単なる無駄だと思うのだが。
今回のようなケースは除くとしての話だけど。

昨日￥３００で仕入れてきた超旧型のＩＢＭのモノクロノートも、
２０３８年までは現役でしょうか？

電源が無事とは考え難い

>>159
液晶がへたれる
HDDに不良セクタが増加
内部コンデンサの液漏れ
蓋部分のヒンジの接触不良をおこす

Linuxは大丈夫なんだよね
だめなの？

１９８５年にはフォートラン、マシン語、コボルが人気でしたが
今は博物館行きでしょう。
機械が進化すれば、ドンドン重いコンパイラが出てくるでしょう。
ですが、枯れた技術は「安定した技術」ですので、学生さんは自分
が選んだ言語に集中して勉強しましょう。

>>162
time_tが32bitなUNIX/Linuxは駄目。しかも、
OSを変えれば良いだけの話ではないので、
根は深いです。

>>163
枯れて安定してても適用する場所が無ければ意味は無い

コボルでかいてJavaに変換する藤痛もあり。

とりあえず、signed int から unsigned int に変えようぜえ。
６８年ほど延長できる。

（intは32ビットということで）

>>165
それを扱う技術者も枯れて安定（墓の中）してますな

>>161
むかーし、水疱瘡と呼ばれる（誰もが一度は壊すことから）ほどフタのフレキ断線がめちゃくちゃ
多い機種があったな。530Csだったっけ。

が現役なうちは博物館というよりシーラカンス。2000年ではわざわざコボルから書き直した。

>>169

5300csね。最低最悪のノート。
完動品持っているけど、怖くて余り使わない。

＞＞１ 2038年って。。。。。。
そのころはもうコンピュータなんて使ってないだろう。

こないだのIBMのATMのトラブルは内部で日付をなんばいかする処理があったから年金や保険、住宅ローンでは致命傷が起きてるかも。

２０３８年問題経験したことある
１００年後まで使えるようにしてくれってゆうわけの
わからん注文が来て

画像や映像のパーミッション問題（実行権付き）を先にかたずけろ！

【本来の使い道】
ダウンロード後、アプリケーションで開くと、
1.　自動的にダイレクトMailが届いたり
2.　Webブラウザーが起動して、作成者のサイトに案内する。

【あやまった使い道】（単純な軽いプログラムで実行可能）
1.　ウイルス的な用途
2.　スパイウェアー
3.　その他もろもろ

2038年問題でコンピュータが誤動作。オレの年金がパーになったらどうし
よう。（生きてるかどうか不明だが。。。）
まぁ2000年問題より相当やっかいだと思う。

>>176

「パー」に勝つのは「貯金」です。

>>172
つっこみ入れてヨォござんすか？

上げ

test

>>167
signed int を６４ビットにすれば再コンパイルするだけで
多分、人類滅亡の日までもつだろ

再コンパイルしても32ビットでコンパイルされたライブラリとリンクされたらダメ
64ビットＯＳに入れ替えてから再コンパイル