facebook twitter hatena line google mixi email
★お気に入り追加


  • 1
  • あぼーん
  • 2002/05/12 23:00
俺の保守担当している製品、ためしに2038年にしたら
見事にあぼーん。

time_tどうなんのよ。
ちなみに俺の定年まであと35年・・。
微妙。

ここまで見た
  • 217
  •  
  • 2008/03/11(火) 22:23:56
あと30年

ここまで見た
  • 218
  •  
  • 2008/03/28(金) 12:02:41
>>79
これって、予言されていたんだよね・・・。

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

ここまで見た
  • 219
  •  
  • 2008/03/31(月) 16:23:44
死んでたらむなしいな〜

ここまで見た
  • 220
  •  
  • 2008/05/05(月) 10:19:03
日付関係の問題

【緊急警告】5月6日にシステム障害の恐れ
http://namidame.2ch.net/test/read.cgi/news/1209948320/l50

おせーよw

ここまで見た
  • 221
  •  
  • 2008/06/02(月) 01:01:12
2038年問題他のカウントダウンRSS作ってみた
http://sunpillar.jf.land.to/cgi-bin/RSS/rss.cgi?rss=countdown

2038年問題が発動するまでサイトが持つかどうかわからないし、
今後RSSなんて廃れた技術になっちゃうかもしれないがw

あと日で計算してるから、秒計算のカウントダウンタイマーとは1日ずれる時間帯がある

--
2038年問題発生まであと10822日

ここまで見た
  • 222
  •  
  • 2008/09/20(土) 18:08:03
2038年問題じゃないが、2036年問題まで残り9999日。

ここまで見た
  • 223
  •  
  • 2008/09/25(木) 00:36:15
昨日は12億2222万2222秒があった

NHK教育を見て24188倍賢いスレ番
http://live23.2ch.net/test/read.cgi/liveetv/1222222222/

ここまで見た
  • 224
  •  
  • 2008/10/02(木) 12:45:08
2038年〜新しいウィルスが開始した

2040年前半〜限界のウィルスが壊れた

2040年後半〜ウィルスでゾンビ達になった。アメリカから


2041年〜世界全滅


2056年〜世界で20人は生き残っています

ここまで見た
  • 225
  •  
  • 2008/12/10(水) 18:06:09
>>208-209
extだけじゃなくてxfsやjfsも32bitなのを見ると
38年問題を意図的にばら撒いてないか?w
地雷仕込んで30年後に一儲けですかww

ここまで見た
  • 226
  •  
  • 2008/12/10(水) 18:19:47
とりあえずbtrfs町という状況がよく分かったわ

ここまで見た
  • 227
  •  
  • 2008/12/11(木) 17:00:23
ファイルシステムは簡単に乗り換えがきくからではないだろうか。

ここまで見た
  • 228
  •  
  • 2008/12/12(金) 01:54:25
システムコールはそうでないから、/* e.g.stat(2) */
ファイルシステムだけ64bitにしても、
結局は既存のls(1)等が利用できるように32bitにして渡してやらないといけない。
つまりユーザ側からは64bitになったことは見えない。
というわけで、急いで64bitにする必然性がない。
fpos_tが64bitになった時のように、
システムコールを二枚立てにするんじゃないかな。

ここまで見た
  • 229
  •  
  • 2008/12/12(金) 17:40:14
coreutilsを64bitOSで動かせばいいんじゃないの?
ファイルシステムが32bitだから64bitOS使っても38年問題が残るという話なんだけど

ここまで見た
  • 230
  •  
  • 2008/12/12(金) 18:16:54
いや、嘘言ってしまった
Linux立ち上げて確認したら38年以降の日付に出来た。スマソ

ここまで見た
  • 231
  •  
  • 2008/12/12(金) 22:15:23
64bitOS(ILP64)では、sizeof(size_t)は必然的に8になってるだろうが、
sizeof(time_t)を必ず8にする必要はない。
逆にIP32でもtime_tは64bitにした方が良い。IP16でさえ。

ここまで見た
  • 232
  •  
  • 2008/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
  •  
  • 2008/12/24(水) 23:57:18
>>208自己レス(随分前だけど、たしか自分のレス)
ext4は1901年12月14日から2514年4月25日までだった。ただしソースはウィキペディア

http://ja.wikipedia.org/wiki/Ext4

>>232
それだと1970年以前の日付が表記できなくなる。でも、1970年以前の日付使う必要性がないからまあいいかw

--
あと、参考までにこの間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
  •  
  • 2008/12/25(木) 09:45:21
>>233
> あと、参考までにこの間x86-64で試した結果

OS書かないと意味ねえ。

ここまで見た
  • 235
  •  
  • 2008/12/27(土) 13:48:06
>>234
Linux (Fedora 9), gccは4.0だったか4.1だと思う。サイズって同一アーキテクチャ用でも*BSDとLinuxじゃ違うのか?

ここまで見た
  • 236
  •  
  • 2009/01/11(日) 14:20:45
19 日であと 29 年かぁ。

ここまで見た
  • 237
  •  
  • 2009/01/11(日) 15:00:51
そういうわれるととても先の話に思えるな

ここまで見た
  • 238
  •  
  • 2009/01/12(月) 15:44:37
来年で2000問題から10年

ここまで見た
  • 239
  •  
  • 2009/01/20(火) 23:58:22
1日オーバーしたけど、残り29年切ったね

ここまで見た
  • 240
  •  
  • 2009/02/11(水) 22:03:03
2009年2月14日 08:31:30(JST)にUNIX TIMEが1234567890になる。

UNIX time が「1234567890」になる
http://slashdot.jp/articles/09/02/09/012251.shtml



ここまで見た
ここまで見た
  • 242
  •  
  • 2009/05/22(金) 03:21:55
保守

ここまで見た
  • 243
  •  
  • 2009/07/13(月) 20:14:10
2038年問題まであと9億秒。

ここまで見た
  • 244
  •  
  • 2009/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
  •  
  • 2009/09/16(水) 14:12:30
永眠するから関係ないよ

ここまで見た
  • 246
  •  
  • 2010/01/10(日) 14:06:28
19 日であと 28 年かぁ。


ここまで見た
  • 247
  •  
  • 2010/01/19(火) 18:58:56
2038年1月19日は今日と同じ火曜日でうるう年の2年後。
月日曜日だけが問題になるシステムなら2010年か1982年に戻せばいいかもしれないがそんなシステム少ないですよね。

ここまで見た
  • 248
  •  
  • 2010/01/19(火) 23:36:01
残り28年。まだまだ先だけど、着実にその時は近づく…

ここまで見た
  • 249
  •  
  • 2010/01/20(水) 00:02:46
2038年に備えて脱it化を目指そう

ここまで見た
  • 250
  •  
  • 2010/01/20(水) 00:05:17
ゆとり世代涙目wwwww

ここまで見た
  • 251
  •  
  • 2010/01/20(水) 12:19:54
あと28年たったら見られてまずいデータは全部自動的に処分されると考えればOK

ここまで見た
  • 252
  •  
  • 2010/02/07(日) 16:45:04
2036年2月6日 6時28分15秒 (UTC)

2036 年問題までも、あと 26 年をきったか。

ここまで見た
  • 253
  •  
  • 2010/02/07(日) 17:27:11
おめ

ここまで見た
  • 254
  •  
  • 2010/09/04(土) 07:53:04
残り10000日を切った。

残り9999日と4時間20分ぐらい

ここまで見た
  • 255
  •  
  • 2010/09/04(土) 11:04:52
おめ

ここまで見た
  • 256
  •  
  • 2010/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

ここまで見た
ここまで見た
  • 258
  •  
  • 2010/12/02(木) 01:05:39
OSレベルでは結構対応進んでるから大丈夫って感じ

ここまで見た
  • 259
  •  
  • 2010/12/02(木) 13:34:14
現役引退してますw

ここまで見た
  • 260
  •  
  • 2011/01/21(金) 21:48:30
残り27年age


ここまで見た
  • 261
  •  
  • 2011/01/21(金) 22:39:06
生きてるかな

ここまで見た
  • 262
  •  
  • 2011/01/24(月) 08:11:36
そこまで生きてる自信がイマイチでス

ここまで見た
  • 263
  •  
  • 2011/03/17(木) 17:06:14.64
高専生の俺がなんとかする
大人は黙って待っとけ

ここまで見た
  • 264
  •  
  • 2011/04/08(金) 10:34:23.92
がんばれ

ここまで見た
  • 265
  •  
  • 2011/04/22(金) 23:55:09.29
アプリケーションが完全に対応するのに10年以上はかかるだろうから
OSは今から10年以内に対応を終える必要がある

ここまで見た
  • 266
  •  
  • 2011/05/09(月) 13:02:44.72
仕事で使ってるんではなければ時計をを10年戻せばいいだけだろ

ここまで見た
  • 267
  •  
  • 2011/05/10(火) 21:52:05.69
OSは既に割と対応してる感じ

ここまで見た
  • 268
  •  
  • 2012/01/21(土) 18:53:05.70
残り26年age
そして、もうすぐスレ立って10年だな


砂時計アラームタイマー
フリックゾンビ
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email
おすすめワード