1 ：
仕様書無しさん：
全然話題にならないのはなぜですか？
2001/9/9
それ、2015年9月じゃないの？
3 ：
仕様書無しさん：2001/06/13(水) 00:23
>>2 あほ？10進数で10桁。16進数だとMAX何桁か知ってる？
4 ：
仕様書無しさん：2001/06/13(水) 00:28
ウニは汎用機/COBOLのアホプログラムほどには、基幹業務に
普及してないからじゃないの？
5 ：
仕様書無くしさん：2001/06/13(水) 00:29
２０３８年１月１９日の心配をするとは
用意周到な人ですね（ﾜﾗ
ていうか単なる痴呆ですね☆
6 ：
仕様書無くしさん：2001/06/13(水) 00:34
２０３８年までにはほぼ全てのＵＮＩＸマシンは
まず間違いなく６４ビット以上のものになってる。
すると今度は５８００億年も数えられるから杞憂だっての。
ていうかチューボーはクソして寝ろ！
2001/9/9問題は（重要かはさておき）2038年問題とは別だよ。10進数であらわした時の桁数が
9桁から10桁になる。
>>1 よほどヴァカな作りでなければ何ら問題ないから。
2038年が楽しみだな。
9 ：
仕様書無しさん：2001/06/13(水) 01:03
10 ：
名無しさん＠１周年：2001/06/13(水) 01:36
UNIX というか EXCEL-VBA とかもバグる可能性あるね
a) 900000000.dat
b) 999999999.dat
c) 1000000000.dat
ファイル名を文字列比較で、一番古い奴を削除すると
いままで a が削除されていたものが c が削除される。
古いソースのＣ言語とか perl は絶対トラブル。
11 ：
仕様書無しさん：2001/06/13(水) 01:36
２０００年問題が意外と何事もなかったので、
今後同様の問題があってもたいしたことないだろうと思ってるんです・・・
13 ：
名無しさん＠１周年：2001/06/13(水) 01:58
>>11 逆に Y2K ほど騒がれてないから、やばいと言う気がする。
しかも、古いＣのソースは会社自体が残ってないなんてケースもある。
データファイルが 999999999.dat 形式のシステムは要注意。
14 ：
仕様無しさん：2001/06/13(水) 06:16
>>10 DOS/Win3.1の頃なら8+3しかないのでその形式にはならない。
15 ：
仕様書無しさん：2001/06/13(水) 17:53
>>13 だれもつっこまないが、そうすると2chのスレIDも10桁になるけど
これはどないなん？
16 ：
仕様書無しさん：2001/06/13(水) 18:08
つか、これに一票
「記念に999999999と1000000000を狙う厨房どもでサーバが落ちる」
17 ：
仕様書無しさん：2001/06/13(水) 18:33
>>6 2038年問題は単にマシンとOSを64bit化するだけで済む話じゃないって
こと知ってる？
19 ：
名無しさん＠１周年：2001/06/13(水) 18:42
20 ：
17：2001/06/13(水) 20:16
>>18 UNIX内部で時間を管理しているtime_tを32bit整数型から64bit整数型へ
変更してしまえば、ひとまずOK。これはいいよね？
で、問題なのはtime_tの値を“32bit整数型”と決めつけて参照している
アプリケーションの方。どんな影響が出るかは想像してみ。
>>20 >で、問題なのはtime_tの値を“32bit整数型”と決めつけて参照している
>アプリケーションの方。どんな影響が出るかは想像してみ。
んと、4バイト決めうちでファイルに掃き出したりしてる場合でしょうか？
確かにありそうだけど、場所を特定しやすいので、それほど大きな
問題にはならないような気もする･･･。
22 ：
19：2001/06/13(水) 20:51
>>15 とある2ch型掲示板スクリプトをみてみましたが
一応 time 値を数値比較してるみたいなんで、大丈夫っぽいです。
ひょっとしたら、別な派生バージョンで文字列比較してる奴があるかも・・・
23 ：
17：2001/06/13(水) 21:22
>>21 問題が発生する/しないはともかく、既存のプログラムを洗いざらい
チェックする必要が出てくるからねぇ…。
(特に客先に出してるシステムやプログラム)
時間参照のAPIを叩いているプログラムなんて山ほどあるから、
2038年問題は2000年問題を越える一大フェスティバルになるのでは
ないかと個人的には思っている。
24 ：
仕様書無しさん：2001/06/13(水) 21:29
2038年なんか、ここにいる中年プログラマーどもは死んでると思われる
25 ：
仕様書無しさん：2001/06/13(水) 21:42
2038年なんか、ここにいる新人プログラマーどもはヨボヨボであると思われる
26 ：
仕様書無しさん：2001/06/13(水) 21:47
2038年なんか、プログラマーなんて存在しないと思われる
27 ：
仕様書無しさん：2001/06/13(水) 22:03
2038年なんか、今のＵＮＩＸなんてほとんど生き残っていないと思われ。
28 ：
入社1年目：2001/06/13(水) 22:20
2038年かぁ
生きてるかなぁ
29 ：
仕様書無しさん：2001/06/13(水) 22:47
PGの寿命は35歳と言われています。
これは35歳以上になるとPGを続けられないという意味ではなく
35歳までにPGの50%overが転職/自殺/服役/隔離という
統計的事実に基づくものです。
2038年になったら2001/1/1 0:00を0にするってことで対処するんだよきっと。
2000年問題で同じようなことやったやつはどうなるんだろ?
31 ：
仕様書無しさん：2001/06/13(水) 23:59
2038年になったら当の昔にプログラムを書かなくなった管理職が
対策に駆り出されると思われ
32 ：
仕様書無しさん：2001/06/14(木) 00:00
2038年までは食っていけるかもしれんな。
34 ：
仕様書無しさん：2001/06/20(水) 21:59
３７年前にはコンピュータすらなかった
>>35 そうなんだ？
37年後は人工知能できてるかな。
37 ：
仕様書無しさん：2001/06/24(日) 06:22
38 ：
ドラエモソ：2001/06/24(日) 22:38
>>36 コンピュータがそれ以前のパラダイムから大きく離れたモノです。
37年後には現在のパラダイムから大きく離れた「ヒンタボ」と言うものが
コンピュータを駆逐しています。
という妄想をしてみる。
39 ：
仕様書無しさん：2001/06/24(日) 23:21
>>30 2001/01/01に作成された文書の日付は？
まぁいいや。俺は定年退職した後だし。
>>35 1949年に世界初のプログラム内蔵型の電子計算機は出てたので37年前には
とっくにコンピュータはあった。 無知な文系卒は氏んでくれ。
>>38 半世紀以上たっても大抵の計算機はCPU一個で逐次処理だから37年後に現在の
パラダイムから大きく離れたものができてるか疑問。
#個人的な希望としては大きく離れてるものｷﾎﾞｰだけどね
#まあ、よっぽど変なやつじゃない限りは新しいパラダイムのものなんて
#考えつかないだろうけど（w