X
2038年、みんなどうする？
0001あぼーん
垢版 |
NGNG
俺の保守担当している製品、ためしに2038年にしたら
見事にあぼーん。

time_tどうなんのよ。
ちなみに俺の定年まであと35年・・。
微妙。
0153名無しさん＠お腹いっぱい。
垢版 |
2006/11/03(金) 19:18:09
年４０レス…２０年で８００レス。２０３８年までは持たないが、２０２７年まではこの調子なら持ちそうだな？
0155名無しさん＠お腹いっぱい。
垢版 |
2006/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
>

とか
0156名無しさん＠お腹いっぱい。
垢版 |
2006/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
>

など
0157名無しさん＠お腹いっぱい。
垢版 |
2006/12/16(土) 20:18:07
俺はすでに引退し死でるか老人ホームだろうから知らんがそのころは今のＯＳの概念はないだろう。
0159名無しさん＠お腹いっぱい。
垢版 |
2006/12/16(土) 21:08:02
2001年には木星か土星に有人飛行できるだろうと予想されていたのが
見事に外れている現実を見ても、2038年になっても
今のOSと状況はほとんど変わっていないだろう。
0160名無しさん＠お腹いっぱい。
垢版 |
2006/12/16(土) 21:29:46
タクシー金払えばどこまででも行くぜ！
0161名無しさん＠お腹いっぱい。
垢版 |
2006/12/16(土) 22:07:30
JavaのSystem.currentTimeMillisって対策されてる？
型はint64かも知れんけど、内部でtime_t使ってたらアウトだよね
0167名無しさん＠お腹いっぱい。
垢版 |
2007/02/13(火) 11:22:02
ジャバって聞くと、風呂の湯沸し器の穴掃除する奴思い出す
0168名無しさん＠お腹いっぱい。
垢版 |
2007/02/13(火) 11:38:58
test
0169名無しさん＠お腹いっぱい。
垢版 |
2007/02/21(水) 13:26:44
>>159
コンピュータ関係は進歩速いと思うけどな。8bit CPU が流行っていたのが
約30年前、20年前は16bit、10年前は32ビット、で、この頃は64bitが流行り
始めた。てことは128bitは10年後で、256bitが20年後。2038年は多分512bit。w
0171名無しさん＠お腹いっぱい。
垢版 |
2007/02/21(水) 16:40:16
未来なんてどっちに転ぶかなんてわからんよ。
秋葉原でメイド喫茶がこれほど乱立する未来を誰が予測できただろうか。
0173名無しさん＠お腹いっぱい。
垢版 |
2007/02/21(水) 17:44:10
一般家庭は兎も角、事務系のぼろいパソコンはいまだDOSだったり、なんだかよく分からないOSだったりするぞ
0184名無しさん＠お腹いっぱい。
垢版 |
2007/03/29(木) 22:54:18
そのシステムはかつて私がかかわった事もあるものだ。
根幹部分のロジックもわかっている。私が退いたあと
の変更点の情報はないが、これまでの改修を追って来た
限りでは大規模な変更は行われていない。

私は静かにその時を待った。OS,ミドルウェアのアップ
デートが適切が行われているならシステムが致命的な
挙動を示し停止するということは起きないだろう。

だが、その上で動作している内製のアプリケーション
はどうか。私の知る限りでは小さな問題が内在されて
いた。その問題自体はアプリケーションに即座に致命
的な問題を引き起こすわけではない。
しかし、ある特殊なシークェンスの入力を受け付けた場
合にそれとわかるイレギュラーな挙動を示すのである。

私がただ待っているのは今のシステムを担当しているエ
ンジニアたちがその問題に気づいたか、適切な対応をお
こなったかを知りたいからである。
そして私はこのために注意深く作り上げたスクリプトを
実行する時を待っていた。
0187名無しさん＠お腹いっぱい。
垢版 |
2007/06/04(月) 17:20:48
特車二科の面々も分散していた。

南雲しのぶ=>海保派失脚のため一躍キャリアに、警視庁最大の粛正人事が行われる。=>現在警視総監
後藤喜一=>しかし海保案はそのまま継承され（美味しいし）、
　　　　　　　　成立した特車大隊隊長に就任　しかし昼行灯は変わらず=>いつも所在を掴むのが困難。
他の面々　適当にｗ　
0188名無しさん＠お腹いっぱい。
垢版 |
2007/09/30(日) 19:00:43
UNIX TIMEも11億9千万を超え、来年には12億突破だな(Fri Jan 11 2008 06:20:00 GMT+0900)。
突破して一週間後には、2038年問題の日まで残り30年を切るわけだ。
0194名無しさん＠お腹いっぱい。
垢版 |
2008/01/21(月) 19:46:24
どうもこのまま行くと2038年頃には革の鎧を着たモヒカン男が
一般市民を襲ってる時代が来そうなのであまり心配する必要はないと思えてきた。
0195名無しさん＠お腹いっぱい。
垢版 |
2008/01/21(月) 21:28:42
>>194
だが、コマンドラインのUnixなマシンは尚も稼働していたのだった。
新世紀Unix伝説　ラヲウさまはUnixによる覇道完遂　ケンシロウは…

最終決戦で、ラヲウさまは天にボードを突き上げ咆哮「我がうにくす人生に一片の悔い無し」
0196名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 12:50:18
今日になって、あと 30 年ないことに気がついた・・。
0198名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 14:54:32
そんなの関係ない、そんなの関係ない、そんなの関係ない・・・

おれ多分現役じゃありませんから。
0199名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 17:40:31
>>197
いや、だから、 30 年もないです。

あと、 29 年 11 カ月とちょっとです。
0200名無しさん＠お腹いっぱい。
垢版 |
2008/01/26(土) 20:50:45
今のうちに高台へ非難する
0201名無しさん＠お腹いっぱい。
垢版 |
2008/01/28(月) 20:05:31
預言者ジュセリーノは2042年に人類は滅亡すると言っている。
2038年と4年しか違わない

2038年が人類のタイムリミットに思えてくる。
預言は本当かもしれない、と思うのはやっぱ歳をとったからか
0204名無しさん＠お腹いっぱい。
垢版 |
2008/01/30(水) 04:16:53
2000年問題の後に2038年問題が起こる
一度起きた事をもう一度繰り返す。
それってただの馬鹿じゃん。
問題を先延ばしにしてもそれは解決した事にはならない
根本的な問題を解決できなければそこでUNIXは終わりだな
0205名無しさん＠お腹いっぱい。
垢版 |
2008/01/30(水) 05:21:43
>二度繰り返す
いや、Y2K需要が記憶から消えた辺りで38を仕掛ければ
大概の企業の担当は世代が入れ替わっているので
ほくほく、同じ手でボッたくれるのです。
0207名無しさん＠お腹いっぱい。
垢版 |
2008/02/03(日) 13:14:42
>>203
動的というなら

メモリがでかくなりすぎて、そろそろmallocの引数が悲鳴を上げるんじゃね？
特に32bit版でコンパイルして、64bit版で使った場合。互換性あるようコンパイルしとけば、そのまま使えるでしょ。たしか

2GB以上一度に確保するとやばいことになる予感
0210名無しさん＠お腹いっぱい。
垢版 |
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バグでえらい苦労した)、あまり自分ではやりたくないなあ。

誰か手をあげてくれないかなあ。
0211名無しさん＠お腹いっぱい。
垢版 |
2008/02/20(水) 11:58:06
UNIX誕生から約40年、これから約30年あることを考えれば、
そのうちなんとかなるべよ、って気もする
0212名無しさん＠お腹いっぱい。
垢版 |
2008/02/22(金) 02:58:32
>>207
別に確保に失敗すればNULLを返すだけでしょ。
今も何も変わらない。
0221名無しさん＠お腹いっぱい。
垢版 |
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日
0224名無しさん＠お腹いっぱい。
垢版 |
2008/10/02(木) 12:45:08
2038年〜新しいウィルスが開始した

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

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


2041年〜世界全滅


2056年〜世界で20人は生き残っています
0228名無しさん＠お腹いっぱい。
垢版 |
2008/12/12(金) 01:54:25
システムコールはそうでないから、/* e.g.stat(2) */
ファイルシステムだけ64bitにしても、
結局は既存のls(1)等が利用できるように32bitにして渡してやらないといけない。
つまりユーザ側からは64bitになったことは見えない。
というわけで、急いで64bitにする必然性がない。
fpos_tが64bitになった時のように、
システムコールを二枚立てにするんじゃないかな。
0229名無しさん＠お腹いっぱい。
垢版 |
2008/12/12(金) 17:40:14
coreutilsを64bitOSで動かせばいいんじゃないの？
ファイルシステムが32bitだから64bitOS使っても38年問題が残るという話なんだけど
0231名無しさん＠お腹いっぱい。
垢版 |
2008/12/12(金) 22:15:23
64bitOS(ILP64)では、sizeof(size_t)は必然的に8になってるだろうが、
sizeof(time_t)を必ず8にする必要はない。
逆にIP32でもtime_tは64bitにした方が良い。IP16でさえ。
0232名無しさん＠お腹いっぱい。
垢版 |
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%消滅してるはずなので、
これが一番現実的かも。
0233名無しさん＠お腹いっぱい。
垢版 |
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
0244名無しさん＠お腹いっぱい。
垢版 |
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
0246名無しさん＠お腹いっぱい。
垢版 |
2010/01/10(日) 14:06:28
19 日であと 28 年かぁ。
0247名無しさん＠お腹いっぱい。
垢版 |
2010/01/19(火) 18:58:56
2038年1月19日は今日と同じ火曜日でうるう年の2年後。
月日曜日だけが問題になるシステムなら2010年か1982年に戻せばいいかもしれないがそんなシステム少ないですよね。
0248名無しさん＠お腹いっぱい。
垢版 |
2010/01/19(火) 23:36:01
残り28年。まだまだ先だけど、着実にその時は近づく…
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況