02/05/12 23:02
2 get
3:名無しさん＠お腹いっぱい。
02/05/12 23:09
今年生まれる子が、2038年には36歳。
心配しなくてもこいつらがなんとかしてくれる。
4:名無しさん＠お腹いっぱい。
02/05/12 23:16
すでに論じられて大方の解決策も出てるもよん↓
ｽﾚﾘﾝｸ(denpa板)
5:名無しさん＠お腹いっぱい。
02/05/12 23:23
>>4
確かにうたがう余地無しだな。こんちくしょう
6:名無しさん＠お腹いっぱい。
02/05/12 23:38
>>3
その通り。年金問題も国債債務問題も靖国問題も環境問題も
官僚問題も同和問題も憲法第9条も特殊法人問題も構造改革も全て先送り。
私達の子孫が何とかしてくれる。
7:名無しさん＠お腹いっぱい。
02/05/13 00:09
>>6
そして子孫達は問う。
なぜ私達の祖先は何もしなかったのかと。
8:名無しさん＠お腹いっぱい。
02/05/13 00:14
>>3
金属バットで楽にしてくれるかもYo!
9:名無しさん＠お腹いっぱい。
02/05/13 00:23
>>3
「もうUNIXがわかる技術者は君達しかいない」と再召集される罠
10:名無しさん＠お腹いっぱい。
02/05/13 00:23
>>6
って事は、急いで子孫を作らねば。
11:名無しさん＠お腹いっぱい。
02/05/13 01:38
そういう結論になるのか。㌧㌦（ｗ
12:名無しさん＠お腹いっぱい。
02/05/13 02:42
>>9
ﾜﾗﾀ
13:名無しさん＠お腹いっぱい。
02/05/13 10:33
time_tを64bitにすれば解決、とかいう話ではない？
もちろんファイルシステムとかバイナリデータの互換性は失われるけど。
14:2000年、みんなどうする？
02/05/13 10:58
年号を4桁にすれば解決、とかいう話ではない？
もちろんデータベースとかバイナリデータの互換性は失われるけど。
15:名無しさん＠お腹いっぱい。
02/05/13 11:19
>>8
なぜ、そーゆうコンテクストでは、「金属」バットなんだろ？
木製の方がイケテルとおもうんだけどなぁ。
16:うひひ
02/05/13 11:47
>>13-14
誰かが勝手にちめを1970に決めてしまったのだから
また誰かが2010くらいに起点を決めて
うすらとぼければいいのではという話ではない？
17:名無しさんｎ
02/05/13 12:37
ところでSunとその上にのるメジャーな商用ソフトは
38年問題は解決済みなのかな？もちろんレガシー
の話は抜きにして。
18:うひひ
02/05/13 13:45
>>17
2038にサポートしてない現在のOSやハードに商用ソフトが
（サポート終了しているといえばいいか）
あえて解決策をとったりソレを公にアピールする必要は無いと思われ。
64bit化の過程で偶然解決された（される）ことはあるだろうが
2000年問題の事例をみればわかるだろうが
30年経ったらまた書き込むとベスト
19:名無しさん＠お腹いっぱい。
02/05/13 13:51
つーかこのご時世、そこまでつかいつづけんでしょ。
2038年が来る前に、旧いマシンの部品供給がでけんよーになってあぼーんヨ。
アホな会社が、1990年代のソースを2038年まで使いつづけてたら知らんけど。
20:名無しさん＠お腹いっぱい。
02/05/25 21:52
このスレは2038年まで継続決定
21:名無しさん＠お腹いっぱい。
02/07/16 00:22
1021212011
なにげに(ﾟДﾟ)ｳﾏｰ
22: ◆jadeDaMePo
03/01/11 04:49
2003年sage
23:名無しさん＠お腹いっぱい。
03/01/11 05:00
hage
24:山崎渉
03/01/15 13:30
（＾＾）
25:（ ´∀｀）さん ◆esDQN1fUPM
03/01/22 14:34
あげ
26:スペースカウボーイ。
03/01/22 19:54
>>9
ありえない話じゃないような気が。
老人になった俺らがBSDを再起動させるのさ。
27:sage
03/04/01 11:56
sage
28:sukatappa
03/04/05 14:34
記念カキコ♪
29:名無しさん＠お腹いっぱい。
03/04/05 15:32
記念sage♪
30:名無しさん＠お腹いっぱい。
03/04/06 03:31
おまたのボタンお押して再起動させてみるテスト
俺が定年になってるころには出てるはずだ～!!!!!!!!
だれか作ってくれ～!!!!
31:名無しさん＠お腹いっぱい。
03/04/06 12:27
Registrant:
2038 (2038-N-DOM)
planterarv 19 120 48 enskede gard
stockholm, se 120 48
SE
Domain Name: 2038.COM
Administrative Contact, Technical Contact:
J.E, Namnet (EB3084)domain-registry@MRFRIDAY.COM
erik bar
Administrator Sdra Hamnvgen 48 115 41
STOCKHOLM
STOCKHOLM
SWEDEN 115 41
SE
+46-8-641 95 9 +46-8-641 95 9
Record expires on 22-May-2003.
Record created on 22-May-1998.
Database last updated on 5-Apr-2003 22:26:03 EST.
Domain servers in listed order:
NS1.SKARPODATA.COM 193.45.208.2
NS2.SKARPODATA.COM 193.45.208.3
32:名無しさん＠お腹いっぱい。
03/04/06 13:46
32bitなんて、30年後には今の8bitマシン以下の用途になってるだろう。
Windowsもビルゲイツが死んだら終り。
33:名無しさん＠お腹いっぱい。
03/04/06 17:10
ま～ time_t を unsigned にしちゃえば22世紀頃まで持つんで、
ファイルシステムとかDBとかのバイナリデータはあんま問題ないと思うけど。
問題はsignedで大小比較してるプログラムのほうだな。
34:名無しさん＠お腹いっぱい。
03/04/13 03:03
ほんとだ。time_tってsignedだったんだ。知らなかった。
unsigned intにしたら2106年までもつのね…死んでるからそれでいいや。
35:名無しさん＠お腹いっぱい。
03/04/13 03:39
てことは、逆に考えると前世紀はまるまる今のtime_t で表せるってこと？
36:名無しさん＠お腹いっぱい。
03/04/13 12:07
/* LP64 の環境なら解決済みじゃない？ */
#ifndef _TIME_T
#define _TIME_T
typedef long time_t; /* time of day in seconds */
#endif /* _TIME_T */
37:名無しさん＠お腹いっぱい。
03/04/13 15:55
2038年にＵＮＩＸって存在するのか？
ＣＵＩ自体ほとんどつかわれていないんじゃないか？
そうでもないかな・・・
38:あぼーん
あぼーん
あぼーん
39:名無しさん＠お腹いっぱい。
03/04/13 19:35
>>37
おまえが使ってないだけではと小一時間．．．（ｒｙ
40:名無しさん＠お腹いっぱい。
03/04/13 20:26
>>37
正直、低能力なハードウェア性能のせいで
■無闇やたらに視覚に依存しすぎ、かつ重厚長大で能力の低い出力デバイス
■思った通りに操作するために高い習熟が必要で、かつ体に余計な負荷がかかる
入力デバイス
にべったりと依存せざるを得ない、今の形式の「ＧＵＩ」というシロモノも、
35年先には骨董品としてしか生き残っていないような気がするけどなぁ
41:名無しさん＠お腹いっぱい。
03/04/13 22:25
まあ>>37は世間しらずのﾋｷｰ ﾄﾞｻﾞかﾏｶ｡
2038年には、ソラリスもAIXもHP-UXもないだろうな。
残るのは、Win BSD Linux .
ただし、このどれも現状とは全く違う環境だろうけど。
もしくは、まったく違うOSが出て
MSが、そこ潰しにかかって買収して生き残って
技術的な事は公開せず、乗り遅れたBSDやらlinuxは死ぬか。
もしくは、linuxやBSDコミュニティから新しい物が出てくるか。
42:名無しさん＠カラアゲうまうま
03/04/13 22:44
>>41
ようするに分からんということだな。
43:名無しさん＠お腹いっぱい。
03/04/13 23:11
>>42
そうそう
44:名無しさん＠お腹いっぱい。
03/04/15 05:10
JFKの死の真相がPAM! PAM!
45:山崎渉
03/04/17 11:53
（＾＾）
46:あぼーん
あぼーん
あぼーん
47:名無しさん＠お腹いっぱい。
03/04/28 23:08
記念パピコ
漏れの誕生日が1021 妹1212 因縁を感じますた。
48:名無しさん＠お腹いっぱい。
03/05/02 13:19
1021年生れか
神だな
49:名無しさん＠お腹いっぱい。
03/05/02 13:19
ageとこ
50:名無しさん＠お腹いっぱい。
03/05/04 04:35
>>1
今のうちに全てのシステムを64bitに移行で解決。いじょ
51:あぼーん
あぼーん
あぼーん
52:名無しさん＠お腹いっぱい。
03/05/05 11:17
URLﾘﾝｸ(homepage.mac.com)
どうよ？
53:あぼーん
あぼーん
あぼーん
54:あぼーん
あぼーん
あぼーん
55:名無しさん＠お腹いっぱい。
03/07/02 14:35
保守（sageでもできるよ！）
56:あぼーん
あぼーん
あぼーん
57:あぼーん
あぼーん
あぼーん
58:名無しさん＠お腹いっぱい。
03/08/04 12:57
UNIXってCのタイプシステムにべったりじゃん。
しかもCの言語的ないい加減さで実装依存だったりするし。
もちろん、それを言い出したらWindowsやMacだってそうなんだけど。
最終的な答えだとは勿論思わないけど、.NETの目指すCommonTypeSystemってのは
この辺りのやっかいな問題も含めて考えられているから好きだ。Javaには
こういう視点はなかった。以後2038年問題を、time_tをunsigned intにするとか、
時間の起点を2010年にするなどといった珍案で、小手先の回避をするのではなくて
38年までには根本的な解決がなされている方がいいなあ。ある意味、UNIXを
部分的に否定することを意味するけど。
59:あぼーん
あぼーん
あぼーん
60:トシ
03/09/10 21:35
UNIX系のOS自体も止まっちゃうの？
61:名無しさん＠お腹いっぱい。
03/09/12 00:05
試しに、PC の日付いぢくってみれば？
62:名無しさん＠お腹いっぱい。
03/09/12 00:12
プロジェクト X
63:キャンベラ
03/10/10 19:54
サゲ
64:名無しさん＠お腹いっぱい。
03/10/16 18:08
１９７０年１月１日からの秒数だからな
ライブラリがダメっぽ
perl のtimeとか・・・
ＧＰＳもあれだっけ？
65:ばかぼーん
03/10/16 18:30
ばかぼーん
66:名無しさん＠お腹いっぱい。
03/10/16 18:37
MSのlibcが2036年で溢れたような気がするので、
その対策を真似すればいいだろう。
67:名無しさん＠お腹いっぱい。
03/10/16 19:06
一緒に溢れてみるとか
68:名無しさん＠お腹いっぱい。
03/10/21 01:11
その頃には現行システムは無いだろうなぁ・・・
若者達に期待ｗ
つーか、虫歯無くしたら歯医者が潰れる、ってのと一緒なんでｗ
まぁ2038年特需だ罠。その前にIPv6特需もありそうだが。
69:名無しさん＠お腹いっぱい。
03/11/09 16:11
つーか、unsigned longかハードとOSが64bit対応して解決しそうなんだけど、、、
70:名無しさん＠お腹いっぱい。
03/11/10 17:57
つーか, おいらその頃隠居してますが...
71:名無しさん＠カラアゲうまうま
03/11/10 19:14
生きてるかどうかすら分からん。
72:名無しさん＠お腹いっぱい。
03/11/10 19:45
今すぐ死にたい
73:名無しさん＠お腹いっぱい。
03/11/10 19:51
がんばれ。
74:C-bus
03/11/13 23:39
いいかげんに、PC9801DX捨てろって！
75:名無しさん＠お腹いっぱい。
03/11/14 10:48
時計を巻き戻して使うのがデフォルトのOSが出るとか。
76:名無しさん＠お腹いっぱい。
03/11/15 01:38
来年まで生きているか分からないので、どうでもいいや…
77:名無しさん＠お腹いっぱい。
03/11/22 03:34
>>76
そういう人に限って、2037年に引っ張り出されていろいろ苦労するだろう、
と想像してみる。
78:名無しさん＠お腹いっぱい。
03/11/24 02:47
定年超えてる・・・・
79:名無しさん＠お腹いっぱい。
04/02/01 13:09
この前、ATM止まったでしょ。あれプチ2038年問題と言えなくもない。
time_tが0x3FFFFFFFから0x40000000になった途端、バッファが溢れてあぼーん。
ま、そういうコード書いた香具師が悪いんだけど。
80:名無しさん＠お腹いっぱい。
04/02/01 23:09
>>79
いまさらそんなこと誇らしげに書かれても。
81:名無しさん＠お腹いっぱい。
04/03/06 00:57
2038年問題のチェック漏れで、KDDIが誤請求
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
82:社長
04/03/06 03:06
38年特需が今から待ち遠しいです。
そのために問題解決をよりこんなんな方向に仕向ける
何かが必要です。マシンをリプレースして万事OKなんて
お手軽なやつじゃダメなんです。
83:名無しさん＠お腹いっぱい。
04/03/06 09:55
2037年をもって全廃とか
84:名無しさん＠お腹いっぱい。
04/08/29 21:49
10000万年問題、みんなどうする？
85:名無しさん＠お腹いっぱい。
04/08/29 22:30
RFC2550
86:名無しさん＠お腹いっぱい。
04/08/29 22:50
1038年まで人類がいるとは思えんが・・・
87:名無しさん＠お腹いっぱい。
04/08/29 22:52
>>86
お前は何年生まれだ
88:名無しさん＠お腹いっぱい。
04/08/30 00:13
>>86-87
ﾜﾗﾀ
89:名無しさん＠お腹いっぱい。
04/08/31 17:05
128bitUNIXと2038年問題はどっちが先にやってくるでしょうか？
90:名無しさん＠お腹いっぱい。
04/10/13 22:07:04
２ちゃんねるは大丈夫？
91:名無しさん＠お腹いっぱい。
04/10/14 11:59:57
UNIXの終わりの方が早いから心配ない
92:
05/03/15 04:21:54
93:名無しさん＠お腹いっぱい。
UNIX時間(+0900)35/04/01(金) 16:29:38
とりあえず
94:!omikuji
UNIX時間(+0900)35/04/01(金) 22:42:55
てすと
95:テスト
UNIX時間(+0900)35年,2005/04/02(土) 16:55:13
日付欄変わった･･･？
96:名無しさん＠お腹いっぱい。
UNIX時間(+0900)35年,2005/04/02(土) 17:29:54
時間の進み方を1/10に定義しなおせばいい。
97:名無しさん＠お腹いっぱい。
05/05/10 00:55:08
64ビットにすればよくね？
ﾃﾗｶｼｺｽwww
98:名無しさん＠お腹いっぱい。
05/05/13 21:24:47
>>97
ﾃﾗﾜﾛｽ
99:名無しさん＠お腹いっぱい。
05/07/14 11:18:00
time_tってそもそも32ビットのうち１ビットは正負の符号に使ってるの？
100:名無しさん＠コート脱いだらハワイのミポリソ萌え
05/07/17 14:09:26
101:名無しさん＠お腹いっぱい。
05/07/24 21:41:55
俺はそのころ４７歳か・・・。
もうそんな歳になっちまったら、正直世の中どうなってても何ともおもわんよ。
102:名無しさん＠お腹いっぱい。
05/07/24 23:10:34
0x47か?
103:名無しさん＠お腹いっぱい。
05/08/16 22:18:34
ぬるぽ
104:名無しさん＠お腹いっぱい。
05/08/18 00:39:08
がつ
105:名無しさん＠お腹いっぱい。
05/08/19 02:33:37
>>99
signed longですから。しょうがない。
106:名無しさん＠お腹いっぱい。
05/08/19 03:45:46
2000念問題が何事もなかったんだから何も起こらない。
就労
107:名無しさん＠お腹いっぱい。
05/08/19 15:23:17
2038年問題を安心して見届けてぽっくり死ぬ奴がこのスレにいるだろうな。
108:名無しさん＠お腹いっぱい。
05/08/19 16:34:47
Y10Kがまだですが何か？
109:名無しさん＠お腹いっぱい。
05/10/02 02:33:45
それよりもY1000Kが気になります。
110:名無しさん＠お腹いっぱい。
05/10/04 17:42:47
それよりも30828年問題が気になります。
(WindowsのFILETIMEがオーバーフロー)
111:名無しさん＠お腹いっぱい。
05/10/16 17:31:22
2038年、２ちゃんが動かなくなっちゃうぞ！あとc言語のプログラムも。。。
たいへんだぁ。２０００ねん問題よりも深刻らしいぞ。
タダ単にプログラムを書き換えればいい問題じゃないぞ。
112:名無しさん＠お腹いっぱい。
06/01/02 00:26:00
確かに2ちゃんは長くて2038年にはなくなる。
113:名無しさん＠お腹いっぱい。
06/03/25 15:24:09
で、何もしないまま>>1から1413日経過したわけだが
2038年問題勃発まであと11622日と20時間50分
URLﾘﾝｸ(sunpillar2004.hp.infoseek.co.jp)
今年中には残り時間10億秒を切っちゃうよ。
114:名無しさん＠お腹いっぱい。
06/05/07 06:28:10
BTAMの時刻オーバーフローが懐かしい。
歴史は何度も繰り返すだろう。
115:1147483648
06/05/13 12:26:57
本日10時27分28秒、Xデーまで残り10億秒を切りました。
116:おまけ
06/05/13 13:19:34
1234567890 2009/02/14 08:31:30
2000000000 2033/05/18 12:33:20
2047483648 2034/11/19 02:27:28（残り1億秒）
117:名無しさん＠お腹いっぱい。
06/05/17 23:06:37
焦ってるのはお前ら小物だけで、
ゲイツやジョブスやリナズはもう策を見出しているよ。
118:名無しさん＠お腹いっぱい。
06/05/19 11:10:42
>117はツンデレ
119:名無しさん＠お腹いっぱい。
06/05/19 11:55:42
>>117
そいつらはツンデル
120:名無しさん＠お腹いっぱい。
06/06/01 22:05:35
2038年に年金の支給年齢に達してれば良いけどな。
少しづつ遠ざかっているような気がするな。
121:名無しさん＠お腹いっぱい。
06/06/02 09:27:18
逃げ水と同じ現象です。
122:名無しさん＠お腹いっぱい。
06/06/02 15:57:06
そういや2ちゃんねるのスレのURLって 1970/1/1 0:00:00 GMT からの秒数を使ってるよな…
てことはやっぱ time() 使ってるということで、2038年には2ちゃんねるが終わるということだな。
123:名無しさん＠お腹いっぱい。
06/06/05 22:49:06
64ビットマシンがいくつかあるみたいだからどうなんでしょ？
124:名無しさん＠お腹いっぱい。
06/06/05 22:55:03
おーい、２０３８年の奴、見てる？
今は２００６年の世界だよ
125:名無しさん＠お腹いっぱい。
06/06/05 23:05:00
>>124
見てるよ。
2030年に、タイムスタンプの1970-1999年の30年間の分を、
60年加算して2030-2059年までの意味を表すものとして
再利用する方法が採択されました。
以降、30年毎にこの方式でタイムスタンプをエンドレスに使い回します。
これにより、タイムスタンプは過去最低30年間分しか表現できなくなりますが、
オーバーフローすることはなくなります。
126:名無しさん＠お腹いっぱい。
06/06/05 23:20:34
それってBIOSの時計は巻き戻して使うって事？
127:名無しさん＠お腹いっぱい。
06/06/06 06:52:19
あと32年後に、今のマシンが動いてるかどうか。
OSがあっても動いているマシンがない。
アプリケーションなんかもお蔵入り。
よって心配する必要はない。
128:名無しさん＠お腹いっぱい。
06/06/06 07:18:42
と、思っていた時期がオレの時代にはありました……
129:名無しさん＠お腹いっぱい。
06/06/06 19:48:54
>>123
それだと584942417318年ぐらいで終わりだよね。
130:名無しさん＠お腹いっぱい。
06/06/08 00:29:35
>>129
宇宙の寿命より長いって。
131:名無しさん＠お腹いっぱい。
06/06/08 00:58:03
人間の成せる業だね
132:名無しさん＠お腹いっぱい。
06/06/08 06:53:52
2038年かぁ・・・
生きて無いだろうなぁ
133:名無しさん＠お腹いっぱい。
06/06/08 09:35:21
２０３７年まで放置して
やばくなったら大騒ぎして対応する。
山奥に非難する人とかいっぱい出るだろう
134:名無しさん＠お腹いっぱい。
06/06/08 20:39:39
>>132
同意。
135:名無しさん＠お腹いっぱい。
06/06/09 19:37:11
よくわからないが長生きしてしまい、のんびり暮らしていたら2038年になり、
金のない後進国の古いシステムが暴走してミサイルが発射され、最初の弾が
>>132に当たって死亡。2発目の弾は山奥に飛んで行き>>133に当たって死亡。
核が搭載されていたので時間を掛けて>>1-131,>>134が死亡。
136:名無しさん＠お腹いっぱい。
06/06/09 20:11:01
寝てる、2038年 寝たきりで電脳化して択捉島あたりで…
137:名無しさん＠お腹いっぱい。
06/06/11 13:26:43
1150000000
138:名無しさん＠お腹いっぱい。
06/06/16 16:22:13
UNIXも68歳。俺も同い年。
嫌だねえ、自分の糞もふけなくなる前に自殺するか。
139:名無しさん＠お腹いっぱい。
06/06/17 14:48:14
あと30年位だろ
保険とか年金のシステムだともう対応済のはずだよな
140:名無しさん＠お腹いっぱい。
06/06/20 13:13:46
保険とか年金のシステムだと
そもそも破綻してそうだな。
141:名無しさん＠お腹いっぱい。
06/06/22 18:22:23
perl -e 'print "UNIX滅亡まであと",0x80000000-time,"秒\n";'
142:名無しさん＠お腹いっぱい。
06/06/22 19:02:04
>>141
おぃおぃ、それくらいperl使わずにシェルでやれよ。
echo 'UNIX滅亡まであと'`expr 2147483648 - \`date -u +%s\``'秒'
143:名無しさん＠お腹いっぱい。
06/06/22 19:17:20
2038年 相変わらず魔法使いは健在なのであった。
144:名無しさん＠お腹いっぱい。
06/07/19 16:58:27
$ crontab -l
14 12 19 1 * if [ `date +%Y` -eq 2038 ]; then echo 'UNIX滅亡まであと7秒' ; fi
$ ■
145:名無しさん＠お腹いっぱい。
06/07/19 16:59:12
>>144
よく考えたら間に % があるから駄目かな…
146:名無しさん＠お腹いっぱい。
06/07/20 04:46:58
14 12 19 1 * if [ `date +%%Y` -eq 2038 ]; then echo 'UNIX滅亡まであと7秒' ; fi
こうじゃね？
147:名無しさん＠お腹いっぱい。
06/07/20 04:49:21
14 12 19 1 * if [ `date +\%Y` -eq 2038 ]; then echo 'UNIX滅亡まであと7秒' ; fi
こうだったorz
148:名無しさん＠お腹いっぱい。
06/07/20 21:58:56
しかし7秒前にメールが来ても困る。
149:名無しさん＠お腹いっぱい。
06/10/09 18:30:59
1億1600万秒オーバー保守
1億1700万秒は2007年1月29日午前1時丁度。
150:名無しさん＠お腹いっぱい。
06/10/09 18:32:00
桁間違えたorz
11億6000万秒 と11億7000万秒だな
151:名無しさん＠お腹いっぱい。
06/10/22 19:44:11
【近未来】西暦2035年直径約1kmの小惑星が地球に衝突の可能性"ロシア科学アカデミーの研究者グループが発表"★２
ｽﾚﾘﾝｸ(newsplus板)l50
解決だな。
152:名無しさん＠お腹いっぱい。
06/10/27 05:35:31
とりあえず暇つぶしに俺のHPw
URLﾘﾝｸ(afox.s206.xrea.com)
uuussatm@gmail.com
153:名無しさん＠お腹いっぱい。
06/11/03 19:18:09
年４０レス…２０年で８００レス。２０３８年までは持たないが、２０２７年まではこの調子なら持ちそうだな？
154:名無しさん＠お腹いっぱい。
06/11/08 00:05:08
>>147
相手鯖のBOXまで逝くのに7秒以上かかったり、中継路の鯖の時計が少し進んでたら・・・
155:名無しさん＠お腹いっぱい。
06/12/16 03:39:19
たとえば
> date -u -r 2147483647
Tue Jan 19 03:14:07 UTC 2038
> date -u -r 2147483648
Tue Jan 19 03:14:08 UTC 2038
> uname -mrs
FreeBSD 6.2-RC1 amd64
>
とか
156:名無しさん＠お腹いっぱい。
06/12/16 03:44:43
あるいは
> uname -rms
FreeBSD 6.1-RELEASE-p10 i386
> date -u -r 2147483647
Tue Jan 19 03:14:07 UTC 2038
> date -u -r 2147483648
Fri Dec 13 20:45:52 UTC 1901
>
とか
> uname -mrs
FreeBSD 6.1-RELEASE-p10 sparc64
> date -u -r 2147483647
Tue Jan 19 03:14:07 UTC 2038
> date -u -r 2147483648
Tue Jan 19 03:14:08 UTC 2038
>
など
157:名無しさん＠お腹いっぱい。
06/12/16 20:18:07
俺はすでに引退し死でるか老人ホームだろうから知らんがそのころは今のＯＳの概念はないだろう。
158:名無しさん＠お腹いっぱい。
06/12/16 20:26:58
すべて脳内にあったりしてな、そして頸椎あたりの首筋にプラグ挿入口が
159:名無しさん＠お腹いっぱい。
06/12/16 21:08:02
2001年には木星か土星に有人飛行できるだろうと予想されていたのが
見事に外れている現実を見ても、2038年になっても
今のOSと状況はほとんど変わっていないだろう。
160:名無しさん＠お腹いっぱい。
06/12/16 21:29:46
タクシー金払えばどこまででも行くぜ！
161:名無しさん＠お腹いっぱい。
06/12/16 22:07:30
JavaのSystem.currentTimeMillisって対策されてる？
型はint64かも知れんけど、内部でtime_t使ってたらアウトだよね
162:名無しさん＠お腹いっぱい。
06/12/16 22:22:37
Javaは走らせるマシンしだいだろ？常識的に考えて。
163:名無しさん＠お腹いっぱい。
06/12/16 22:24:05
2038年までにはJavaは消えてるだろ?
164:名無しさん＠お腹いっぱい。
06/12/16 22:47:34
一度多少なりとも流行った言語はそう簡単に消滅しないだろ
165:名無しさん＠お腹いっぱい。
06/12/19 22:22:08
初心者だけどjavaで食ってる俺参上
166:名無しさん＠お腹いっぱい。
06/12/21 02:45:39
>>165
どーよ
167:名無しさん＠お腹いっぱい。
07/02/13 11:22:02
ジャバって聞くと、風呂の湯沸し器の穴掃除する奴思い出す
168:名無しさん＠お腹いっぱい。
07/02/13 11:38:58
test
169:名無しさん＠お腹いっぱい。
07/02/21 13:26:44
>>159
コンピュータ関係は進歩速いと思うけどな。8bit CPU が流行っていたのが
約30年前、20年前は16bit、10年前は32ビット、で、この頃は64bitが流行り
始めた。てことは128bitは10年後で、256bitが20年後。2038年は多分512bit。w
170:名無しさん＠お腹いっぱい。
07/02/21 14:00:09
だが、どうやって開発の為の小銭を稼ぐかだな。
32bit以上では、一般に対する更新喚起は望めないぞ。
171:名無しさん＠お腹いっぱい。
07/02/21 16:40:16
未来なんてどっちに転ぶかなんてわからんよ。
秋葉原でメイド喫茶がこれほど乱立する未来を誰が予測できただろうか。
172:名無しさん＠お腹いっぱい。
07/02/21 17:07:46
>>171
あそこのヤッチャバで江戸弁の職人が
マイドと言わず
メードって言ってたころ予見していたよ
173:名無しさん＠お腹いっぱい。
07/02/21 17:44:10
一般家庭は兎も角、事務系のぼろいパソコンはいまだDOSだったり、なんだかよく分からないOSだったりするぞ
174:名無しさん＠お腹いっぱい。
07/02/21 18:06:33
某理髪店なんて、レジの管理システムPC-9821とDOS＋DOSアプリケーションだぞ。
175:名無しさん＠お腹いっぱい。
07/02/21 18:14:57
俺らも業務内容を散髪に転換すれば、OSなんかDOSで良くなるわけだよ。
176:名無しさん＠お腹いっぱい。
07/02/26 05:51:00
なるほど
177:名無しさん＠お腹いっぱい。
07/02/28 15:32:38
なんだかわからないOSやDOSで済むといいなあ
178:名無しさん＠お腹いっぱい。
07/03/01 17:19:28
2038年に備えて、とりあえずcut(1)を丹念に読んどけばいいのか?
179:名無しさん＠お腹いっぱい。
07/03/02 01:12:53
2038年 ... どうでもいいや。引退しているぉ。
180:名無しさん＠お腹いっぱい。
07/03/02 13:18:18
寝てる、頸椎にはプラグ挿入 そしてネットの海へダイブ。
181:名無しさん＠お腹いっぱい。
07/03/11 21:15:18
CPUもOSも64bitにしちゃえというのは解決しているようで、
現実的には何も解決してないよな
182:名無しさん＠お腹いっぱい。
07/03/11 21:22:25
コストの壁か……
183:名無しさん＠お腹いっぱい。
07/03/12 18:02:41
>>181
どのようになって欲しい？
184:名無しさん＠お腹いっぱい。
07/03/29 22:54:18
そのシステムはかつて私がかかわった事もあるものだ。
根幹部分のロジックもわかっている。私が退いたあと
の変更点の情報はないが、これまでの改修を追って来た
限りでは大規模な変更は行われていない。
私は静かにその時を待った。OS,ミドルウェアのアップ
デートが適切が行われているならシステムが致命的な
挙動を示し停止するということは起きないだろう。
だが、その上で動作している内製のアプリケーション
はどうか。私の知る限りでは小さな問題が内在されて
いた。その問題自体はアプリケーションに即座に致命
的な問題を引き起こすわけではない。
しかし、ある特殊なシークェンスの入力を受け付けた場
合にそれとわかるイレギュラーな挙動を示すのである。
私がただ待っているのは今のシステムを担当しているエ
ンジニアたちがその問題に気づいたか、適切な対応をお
こなったかを知りたいからである。
そして私はこのために注意深く作り上げたスクリプトを
実行する時を待っていた。
185:名無しさん＠お腹いっぱい。
07/03/30 02:20:43
ええと、帆場回顧録ですか？
186:名無しさん＠お腹いっぱい。
07/06/03 21:37:36
こうして、なんら解決を見出せぬまま>>1から五年の年月が経ったのであった
187:名無しさん＠お腹いっぱい。
07/06/04 17:20:48
特車二科の面々も分散していた。
南雲しのぶ=>海保派失脚のため一躍キャリアに、警視庁最大の粛正人事が行われる。=>現在警視総監
後藤喜一=>しかし海保案はそのまま継承され（美味しいし）、
成立した特車大隊隊長に就任 しかし昼行灯は変わらず=>いつも所在を掴むのが困難。
他の面々 適当にｗ
188:名無しさん＠お腹いっぱい。
07/09/30 19:00:43
UNIX TIMEも11億9千万を超え、来年には12億突破だな(Fri Jan 11 2008 06:20:00 GMT+0900)。
突破して一週間後には、2038年問題の日まで残り30年を切るわけだ。
189:名無しさん＠お腹いっぱい。
07/10/01 20:54:48
30年か……まだまだっ！
190:名無しさん＠お腹いっぱい。
08/01/19 20:22:47
2038年問題発生まで残り30年記念age
191:名無しさん＠お腹いっぱい。
08/01/19 20:32:41
>>190
どうせなら、それを今日の12時14分07秒にカキコしてほしかった。
192:名無しさん＠お腹いっぱい。
08/01/21 10:02:07
俺曾孫と遊んでるか土の中に入ってる。
193:名無しさん＠お腹いっぱい。
08/01/21 13:29:08
>>192
土葬はないだろうから
死体遺棄か？
194:名無しさん＠お腹いっぱい。
08/01/21 19:46:24
どうもこのまま行くと2038年頃には革の鎧を着たモヒカン男が
一般市民を襲ってる時代が来そうなのであまり心配する必要はないと思えてきた。
195:名無しさん＠お腹いっぱい。
08/01/21 21:28:42
>>194
だが、コマンドラインのUnixなマシンは尚も稼働していたのだった。
新世紀Unix伝説 ラヲウさまはUnixによる覇道完遂 ケンシロウは…
最終決戦で、ラヲウさまは天にボードを突き上げ咆哮「我がうにくす人生に一片の悔い無し」
196:名無しさん＠お腹いっぱい。
08/01/26 12:50:18
今日になって、あと 30 年ないことに気がついた・・。
197:名無しさん＠お腹いっぱい。
08/01/26 14:30:12
まだ、30年もある訳だ。
198:名無しさん＠お腹いっぱい。
08/01/26 14:54:32
そんなの関係ない、そんなの関係ない、そんなの関係ない・・・
おれ多分現役じゃありませんから。
199:名無しさん＠お腹いっぱい。
08/01/26 17:40:31
>>197
いや、だから、 30 年もないです。
あと、 29 年 11 カ月とちょっとです。
200:名無しさん＠お腹いっぱい。
08/01/26 20:50:45
今のうちに高台へ非難する
201:名無しさん＠お腹いっぱい。
08/01/28 20:05:31
預言者ジュセリーノは2042年に人類は滅亡すると言っている。
2038年と4年しか違わない
2038年が人類のタイムリミットに思えてくる。
預言は本当かもしれない、と思うのはやっぱ歳をとったからか
202:名無しさん＠お腹いっぱい。
08/01/29 22:47:22
恐怖の大王は2000年問題だってじっちゃんが...
203:名無しさん＠お腹いっぱい。
08/01/30 02:33:06
後付けはいいよ、もっとダイナミックな物を考えてくれｗ
204:名無しさん＠お腹いっぱい。
08/01/30 04:16:53
2000年問題の後に2038年問題が起こる
一度起きた事をもう一度繰り返す。
それってただの馬鹿じゃん。
問題を先延ばしにしてもそれは解決した事にはならない
根本的な問題を解決できなければそこでUNIXは終わりだな
205:名無しさん＠お腹いっぱい。
08/01/30 05:21:43
>二度繰り返す
いや、Y2K需要が記憶から消えた辺りで38を仕掛ければ
大概の企業の担当は世代が入れ替わっているので
ほくほく、同じ手でボッたくれるのです。
206:名無しさん＠お腹いっぱい。
08/02/03 10:11:37
特に>>204のようなのが役職に就いている会社から搾れるだけ
搾り取るとよいでしょう。
207:名無しさん＠お腹いっぱい。
08/02/03 13:14:42
>>203
動的というなら
メモリがでかくなりすぎて、そろそろmallocの引数が悲鳴を上げるんじゃね？
特に32bit版でコンパイルして、64bit版で使った場合。互換性あるようコンパイルしとけば、そのまま使えるでしょ。たしか
2GB以上一度に確保するとやばいことになる予感
208:名無しさん＠お腹いっぱい。
08/02/11 19:59:53
ext2, ext3, ext4も2038年問題抱えてるみたいだな。つい最近出たext4でも直さないなんて大丈夫か？
209:名無しさん＠お腹いっぱい。
08/02/11 21:31:42
そういうのは気にならない人たちが使うものだから
210:名無しさん＠お腹いっぱい。
08/02/15 12:51:02
Matzにっき(2008-02-09)
URLﾘﾝｸ(www.rubyist.net)
_ [言語] use Perl | Perl is now Y2038 safe
URLﾘﾝｸ(use.perl.org)
Perlが2038年問題を解決した、という話。
基本的なアルゴリズムは
1. Write a 64 bit clean gmtime().
2. Run your time through this new gmtime_64().
3. Change the year to a year between 2012 and 2037.
4. Run it through the 32 bit system localtime() to get time zone stuff.
5. Move the year back to the original.
というもの。もちろん、政治的に決まるDST(夏時間)には対応不可能だが、未来のことは誰にもわからない(ので対応は期待されない)ので大丈夫。
Rubyも同じやり方で対応しようかなあ。でも時間関数にはトラウマがあるので(DSTバグでえらい苦労した)、あまり自分ではやりたくないなあ。
誰か手をあげてくれないかなあ。
211:名無しさん＠お腹いっぱい。
08/02/20 11:58:06
UNIX誕生から約40年、これから約30年あることを考えれば、
そのうちなんとかなるべよ、って気もする
212:名無しさん＠お腹いっぱい。
08/02/22 02:58:32
>>207
別に確保に失敗すればNULLを返すだけでしょ。
今も何も変わらない。
213:名無しさん＠お腹いっぱい。
08/02/22 09:11:08
>>79あたりが折り返し地点だったみたいですね。
64bit time_tもsignedにしてくれると過去への応用が広がるね。
214:名無しさん＠お腹いっぱい。
08/02/22 09:12:01
>>210
この実装は洒落でしょ?
rubyで実装してどうすんだよ。
215:名無しさん＠お腹いっぱい。
08/02/23 11:36:03
>>135
今更だがおまえだけ生き残っている理由が知りたい
216:名無しさん＠お腹いっぱい。
08/02/27 02:09:58
せっかくの特需を自分たちの手で摘み取ってしまうこともあるまい
217:名無しさん＠お腹いっぱい。
08/03/11 22:23:56
あと３０年
218:名無しさん＠お腹いっぱい。
08/03/28 12:02:41
>>79
これって、予言されていたんだよね・・・。
[linux-users:70300] y2k+4 problem.
URLﾘﾝｸ(search.luky.org)
219:名無しさん＠お腹いっぱい。
08/03/31 16:23:44
死んでたらむなしいな～
220:名無しさん＠お腹いっぱい。
08/05/05 10:19:03
日付関係の問題
【緊急警告】5月6日にシステム障害の恐れ
ｽﾚﾘﾝｸ(news板)l50
おせーよｗ
221:名無しさん＠お腹いっぱい。
08/06/02 01:01:12
2038年問題他のカウントダウンRSS作ってみた
URLﾘﾝｸ(sunpillar.jf.land.to)
2038年問題が発動するまでサイトが持つかどうかわからないし、
今後RSSなんて廃れた技術になっちゃうかもしれないがｗ
あと日で計算してるから、秒計算のカウントダウンタイマーとは1日ずれる時間帯がある
--
2038年問題発生まであと10822日
222:名無しさん＠お腹いっぱい。
08/09/20 18:08:03
2038年問題じゃないが、2036年問題まで残り9999日。
223:名無しさん＠お腹いっぱい。
08/09/25 00:36:15
昨日は12億2222万2222秒があった
NHK教育を見て24188倍賢いスレ番
ｽﾚﾘﾝｸ(liveetv板)
224:名無しさん＠お腹いっぱい。
08/10/02 12:45:08
2038年～新しいウィルスが開始した
2040年前半～限界のウィルスが壊れた
2040年後半～ウィルスでゾンビ達になった。アメリカから
2041年～世界全滅
2056年～世界で20人は生き残っています
225:名無しさん＠お腹いっぱい。
08/12/10 18:06:09
>>208-209
extだけじゃなくてxfsやjfsも32bitなのを見ると
38年問題を意図的にばら撒いてないか？ｗ
地雷仕込んで30年後に一儲けですかｗｗ
226:名無しさん＠お腹いっぱい。
08/12/10 18:19:47
とりあえずbtrfs町という状況がよく分かったわ
227:名無しさん＠お腹いっぱい。
08/12/11 17:00:23
ファイルシステムは簡単に乗り換えがきくからではないだろうか。
228:名無しさん＠お腹いっぱい。
08/12/12 01:54:25
システムコールはそうでないから、/* e.g.stat(2) */
ファイルシステムだけ64bitにしても、
結局は既存のls(1)等が利用できるように32bitにして渡してやらないといけない。
つまりユーザ側からは64bitになったことは見えない。
というわけで、急いで64bitにする必然性がない。
fpos_tが64bitになった時のように、
システムコールを二枚立てにするんじゃないかな。
229:名無しさん＠お腹いっぱい。
08/12/12 17:40:14
coreutilsを64bitOSで動かせばいいんじゃないの？
ファイルシステムが32bitだから64bitOS使っても38年問題が残るという話なんだけど
230:名無しさん＠お腹いっぱい。
08/12/12 18:16:54
いや、嘘言ってしまった
Linux立ち上げて確認したら38年以降の日付に出来た。スマソ
231:名無しさん＠お腹いっぱい。
08/12/12 22:15:23
64bitOS(ILP64)では、sizeof(size_t)は必然的に8になってるだろうが、
sizeof(time_t)を必ず8にする必要はない。
逆にIP32でもtime_tは64bitにした方が良い。IP16でさえ。
232:名無しさん＠お腹いっぱい。
08/12/18 16:14:34
ext2のmtime unsigned int
struct inodeのmtime long
なので
64bitOSなら19700101を起点として2106まで使えるということみたいですね。
struct inodeの中の日付データはlongなのでキャッシュされてる時点では、
unsigned intの範囲外のデータも扱えるということですか。64bitOSにて、
2106以降の日付を誤って入力した場合、保存されるデータはすべて2106に直されるけど、
1970以前の値の場合はどんな値になるか、入力されたデータ次第ということですね。
30年後は分からないけど、100年後にはLinuxなんて100%消滅してるはずなので、
これが一番現実的かも。
233:名無しさん＠お腹いっぱい。
08/12/24 23:57:18
>>208自己レス（随分前だけど、たしか自分のレス）
ext4は1901年12月14日から2514年4月25日までだった。ただしソースはウィキペディア
URLﾘﾝｸ(ja.wikipedia.org)
>>232
それだと1970年以前の日付が表記できなくなる。でも、1970年以前の日付使う必要性がないからまあいいかｗ
--
あと、参考までにこの間x86-64で試した結果
sizeof(int) =4
sizeof(long int)=8
sizeof(long long int)=8
sizeof(void*)=8
x86だとこうなる
sizeof(int) =4
sizeof(long int)=4
sizeof(long long int)=8
sizeof(void*)=4
234:名無しさん＠お腹いっぱい。
08/12/25 09:45:21
>>233
> あと、参考までにこの間x86-64で試した結果
OS書かないと意味ねえ。
235:名無しさん＠お腹いっぱい。
08/12/27 13:48:06
>>234
Linux (Fedora 9), gccは4.0だったか4.1だと思う。サイズって同一アーキテクチャ用でも*BSDとLinuxじゃ違うのか？
236:名無しさん＠お腹いっぱい。
09/01/11 14:20:45
19 日であと 29 年かぁ。
237:名無しさん＠お腹いっぱい。
09/01/11 15:00:51
そういうわれるととても先の話に思えるな
238:名無しさん＠お腹いっぱい。
09/01/12 15:44:37
来年で2000問題から10年
239:名無しさん＠お腹いっぱい。
09/01/20 23:58:22
1日オーバーしたけど、残り29年切ったね
240:名無しさん＠お腹いっぱい。
09/02/11 22:03:03
2009年2月14日 08:31:30(JST)にUNIX TIMEが1234567890になる。
UNIX time が「1234567890」になる
URLﾘﾝｸ(slashdot.jp)
241:名無しさん＠お腹いっぱい。
09/02/14 08:37:30
ｽﾚﾘﾝｸ(news4vip板)
ｽﾚﾘﾝｸ(entrance板)
242:名無しさん＠お腹いっぱい。
09/05/22 03:21:55
保守
243:名無しさん＠お腹いっぱい。
09/07/13 20:14:10
2038年問題まであと9億秒。
244:名無しさん＠お腹いっぱい。
09/07/13 20:26:16
>>243
自己レス。残念、2秒遅かった・・・
ちなみに
残り10億 Sat May 13 2006 10:27:28 GMT+0900
残り 9億 Mon Jul 13 2009 20:14:08 GMT+0900
残り 8億 Thu Sep 13 2012 06:00:48 GMT+0900
残り 7億 Sat Nov 14 2015 15:47:28 GMT+0900
残り 6億 Tue Jan 15 2019 01:34:08 GMT+0900
残り 5億 Thu Mar 17 2022 11:20:48 GMT+0900
残り 4億 Sat May 17 2025 21:07:28 GMT+0900
残り 3億 Tue Jul 18 2028 06:54:08 GMT+0900
残り 2億 Thu Sep 18 2031 16:40:48 GMT+0900
残り 1億 Sun Nov 19 2034 02:27:28 GMT+0900
残り1000万秒 Fri Sep 25 2037 18:27:28 GMT+0900
残り 100万秒 Thu Jan 07 2038 22:27:28 GMT+0900
残り 10万秒 Mon Jan 18 2038 08:27:28 GMT+0900
残り 1万秒 Tue Jan 19 2038 09:27:28 GMT+0900
残り 1000秒 Tue Jan 19 2038 11:57:28 GMT+0900
残り 100秒 Tue Jan 19 2038 12:12:28 GMT+0900
残り 10秒 Tue Jan 19 2038 12:13:58 GMT+0900
残り 1秒 Tue Jan 19 2038 12:14:07 GMT+0900
245:名無しさん＠お腹いっぱい。
09/09/16 14:12:30
永眠するから関係ないよ
246:名無しさん＠お腹いっぱい。
10/01/10 14:06:28
19 日であと 28 年かぁ。
247:名無しさん＠お腹いっぱい。
10/01/19 18:58:56
2038年1月19日は今日と同じ火曜日でうるう年の2年後。
月日曜日だけが問題になるシステムなら2010年か1982年に戻せばいいかもしれないがそんなシステム少ないですよね。
248:名無しさん＠お腹いっぱい。
10/01/19 23:36:01
残り28年。まだまだ先だけど、着実にその時は近づく…
249:名無しさん＠お腹いっぱい。
10/01/20 00:02:46
2038年に備えて脱it化を目指そう
250:名無しさん＠お腹いっぱい。
10/01/20 00:05:17
ゆとり世代涙目wwwww
251:名無しさん＠お腹いっぱい。
10/01/20 12:19:54
あと28年たったら見られてまずいデータは全部自動的に処分されると考えればOK
252:名無しさん＠お腹いっぱい。
10/02/07 16:45:04
2036年2月6日 6時28分15秒 (UTC)
2036 年問題までも、あと 26 年をきったか。
253:名無しさん＠お腹いっぱい。
10/02/07 17:27:11
おめ
254:名無しさん＠お腹いっぱい。
10/09/04 07:53:04
残り10000日を切った。
残り9999日と4時間20分ぐらい
255:名無しさん＠お腹いっぱい。
10/09/04 11:04:52
おめ
256:名無しさん＠お腹いっぱい。
10/09/16 18:43:02
残り10億 Sat May 13 2006 10:27:28 GMT+0900
残り 9億 Mon Jul 13 2009 20:14:08 GMT+0900
残り 8億 Thu Sep 13 2012 06:00:48 GMT+0900
残り 7億 Sat Nov 14 2015 15:47:28 GMT+0900
残り 6億 Tue Jan 15 2019 01:34:08 GMT+0900
残り 5億 Thu Mar 17 2022 11:20:48 GMT+0900
残り 4億 Sat May 17 2025 21:07:28 GMT+0900
残り 3億 Tue Jul 18 2028 06:54:08 GMT+0900
残り 2億 Thu Sep 18 2031 16:40:48 GMT+0900
残り 1億 Sun Nov 19 2034 02:27:28 GMT+0900
残り1000万秒 Fri Sep 25 2037 18:27:28 GMT+0900
残り 100万秒 Thu Jan 07 2038 22:27:28 GMT+0900
残り 10万秒 Mon Jan 18 2038 08:27:28 GMT+0900
残り 1万秒 Tue Jan 19 2038 09:27:28 GMT+0900
残り 1000秒 Tue Jan 19 2038 11:57:28 GMT+0900
残り 100秒 Tue Jan 19 2038 12:12:28 GMT+0900
残り 10秒 Tue Jan 19 2038 12:13:58 GMT+0900
残り 1秒 Tue Jan 19 2038 12:14:07 GMT+0900
257:名無しさん＠お腹いっぱい。
10/09/16 18:44:47
URLﾘﾝｸ(www.timeanddate.com)
258:名無しさん＠お腹いっぱい。
10/12/02 01:05:39
OSレベルでは結構対応進んでるから大丈夫って感じ
259:名無しさん＠お腹いっぱい。
10/12/02 13:34:14
現役引退してますw
260:名無しさん＠お腹いっぱい。
11/01/21 21:48:30
残り27年age
261:名無しさん＠お腹いっぱい。
11/01/21 22:39:06
生きてるかな
262:名無しさん＠お腹いっぱい。
11/01/24 08:11:36
そこまで生きてる自信がイマイチでス
263:名無しさん＠お腹いっぱい。
11/03/17 17:06:14.64
高専生の俺がなんとかする
大人は黙って待っとけ
264:名無しさん＠お腹いっぱい。
11/04/08 10:34:23.92
がんばれ
265:名無しさん＠お腹いっぱい。
11/04/22 23:55:09.29
アプリケーションが完全に対応するのに10年以上はかかるだろうから
OSは今から10年以内に対応を終える必要がある
266:名無しさん＠お腹いっぱい。
11/05/09 13:02:44.72
仕事で使ってるんではなければ時計をを10年戻せばいいだけだろ
267:名無しさん＠お腹いっぱい。
11/05/10 21:52:05.69
OSは既に割と対応してる感じ
268:名無しさん＠お腹いっぱい。
12/01/21 18:53:05.70
残り26年age
そして、もうすぐスレ立って10年だな
269:名無しさん＠お腹いっぱい。
12/05/13 17:02:25.07
スレ10周年・・・・って昨日だったかw
2038年問題って大分解決したんだろうか。最近知った話だと、B-CASも2038年問題があるらしい
（契約終了日を表す変数の最大値が0xffff=2038年4月22日なのでそれ以降使えない）
270:名無しさん＠お腹いっぱい。
12/05/19 16:55:02.77
どうでもいいけどコンピュータの世界って
>>19
のまさかそこまでは使わないだろうでハマるパターンが結構あるよね
271:名無しさん＠お腹いっぱい。
12/06/15 20:56:33.88
デジタル放送は20年以内に再び移行させられる（krmmk3） - BLOGOS（ブロゴス）
URLﾘﾝｸ(blogos.com)
272:名無しさん＠お腹いっぱい。
12/09/16 19:38:20.64
2038年問題まであと8億秒
URLﾘﾝｸ(slashdot.jp)
273:名無しさん＠お腹いっぱい。
12/09/20 09:29:46.02
2038には全く異なるアーキテクチャが出現している筈だった。
なのにおまいらときたら、古いしきたりをいつまでも引き摺りおって
274:名無しさん＠お腹いっぱい。
12/09/20 20:05:43.24
なんかipv6と話が似てるな
275:名無しさん＠お腹いっぱい。
13/01/24 00:04:00.02
あと25年