2038年、みんなどうする？ [sc](★0)
-
- 1
- あぼーん
- 2002/05/12 23:00
-
俺の保守担当している製品、ためしに2038年にしたら
見事にあぼーん。
time_tどうなんのよ。
ちなみに俺の定年まであと35年・・。
微妙。
-
- 192
- 2008/01/21(月) 10:02:07
-
俺曾孫と遊んでるか土の中に入ってる。
-
- 193
- 2008/01/21(月) 13:29:08
-
>>192
土葬はないだろうから
死体遺棄か？
-
- 194
- 2008/01/21(月) 19:46:24
-
どうもこのまま行くと2038年頃には革の鎧を着たモヒカン男が
一般市民を襲ってる時代が来そうなのであまり心配する必要はないと思えてきた。
-
- 195
- 2008/01/21(月) 21:28:42
-
>>194
だが、コマンドラインのUnixなマシンは尚も稼働していたのだった。
新世紀Unix伝説 ラヲウさまはUnixによる覇道完遂 ケンシロウは…
最終決戦で、ラヲウさまは天にボードを突き上げ咆哮「我がうにくす人生に一片の悔い無し」
-
- 196
- 2008/01/26(土) 12:50:18
-
今日になって、あと 30 年ないことに気がついた・・。
-
- 197
- 2008/01/26(土) 14:30:12
-
まだ、30年もある訳だ。
-
- 198
- 2008/01/26(土) 14:54:32
-
そんなの関係ない、そんなの関係ない、そんなの関係ない・・・
おれ多分現役じゃありませんから。
-
- 199
- 2008/01/26(土) 17:40:31
-
>>197
いや、だから、 30 年もないです。
あと、 29 年 11 カ月とちょっとです。
-
- 200
- 2008/01/26(土) 20:50:45
-
今のうちに高台へ非難する
-
- 201
- 2008/01/28(月) 20:05:31
-
預言者ジュセリーノは2042年に人類は滅亡すると言っている。
2038年と4年しか違わない
2038年が人類のタイムリミットに思えてくる。
預言は本当かもしれない、と思うのはやっぱ歳をとったからか
-
- 202
- 2008/01/29(火) 22:47:22
-
恐怖の大王は2000年問題だってじっちゃんが...
-
- 203
- 2008/01/30(水) 02:33:06
-
後付けはいいよ、もっとダイナミックな物を考えてくれｗ
-
- 204
- 2008/01/30(水) 04:16:53
-
2000年問題の後に2038年問題が起こる
一度起きた事をもう一度繰り返す。
それってただの馬鹿じゃん。
問題を先延ばしにしてもそれは解決した事にはならない
根本的な問題を解決できなければそこでUNIXは終わりだな
-
- 205
- 2008/01/30(水) 05:21:43
-
>二度繰り返す
いや、Y2K需要が記憶から消えた辺りで38を仕掛ければ
大概の企業の担当は世代が入れ替わっているので
ほくほく、同じ手でボッたくれるのです。
-
- 206
- 2008/02/03(日) 10:11:37
-
特に>>204のようなのが役職に就いている会社から搾れるだけ
搾り取るとよいでしょう。
-
- 207
- 2008/02/03(日) 13:14:42
-
>>203
動的というなら
メモリがでかくなりすぎて、そろそろmallocの引数が悲鳴を上げるんじゃね？
特に32bit版でコンパイルして、64bit版で使った場合。互換性あるようコンパイルしとけば、そのまま使えるでしょ。たしか
2GB以上一度に確保するとやばいことになる予感
-
- 208
- 2008/02/11(月) 19:59:53
-
ext2, ext3, ext4も2038年問題抱えてるみたいだな。つい最近出たext4でも直さないなんて大丈夫か？
-
- 209
- 2008/02/11(月) 21:31:42
-
そういうのは気にならない人たちが使うものだから
-
- 210
- 2008/02/15(金) 12:51:02
-
Matzにっき(2008-02-09)
http://www.rubyist.net/~matz/20080209.html
_ [言語] use Perl | Perl is now Y2038 safe
http://use.perl.org/articles/08/02/07/197204.shtml
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
- 2008/02/20(水) 11:58:06
-
UNIX誕生から約40年、これから約30年あることを考えれば、
そのうちなんとかなるべよ、って気もする
-
- 212
- 2008/02/22(金) 02:58:32
-
>>207
別に確保に失敗すればNULLを返すだけでしょ。
今も何も変わらない。
-
- 213
- 2008/02/22(金) 09:11:08
-
>>79あたりが折り返し地点だったみたいですね。
64bit time_tもsignedにしてくれると過去への応用が広がるね。
-
- 214
- 2008/02/22(金) 09:12:01
-
>>210
この実装は洒落でしょ?
rubyで実装してどうすんだよ。
-
- 215
- 2008/02/23(土) 11:36:03
-
>>135
今更だがおまえだけ生き残っている理由が知りたい
-
- 216
- 2008/02/27(水) 02:09:58
-
せっかくの特需を自分たちの手で摘み取ってしまうこともあるまい
-
- 217
- 2008/03/11(火) 22:23:56
-
あと３０年
-
- 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
おせーよｗ
-
- 221
- 2008/06/02(月) 01:01:12
-
2038年問題他のカウントダウンRSS作ってみた
http://sunpillar.jf.land.to/cgi-bin/RSS/rss.cgi?rss=countdown
2038年問題が発動するまでサイトが持つかどうかわからないし、
今後RSSなんて廃れた技術になっちゃうかもしれないがｗ
あと日で計算してるから、秒計算のカウントダウンタイマーとは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年問題を意図的にばら撒いてないか？ｗ
地雷仕込んで30年後に一儲けですかｗｗ
-
- 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年以前の日付使う必要性がないからまあいいかｗ
--
あと、参考までにこの間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億秒。
このページを共有する
おすすめワード