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

time_tどうなんのよ。
ちなみに俺の定年まであと35年・・。
微妙。
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年。まだまだ先だけど、着実にその時は近づく…
0254名無しさん＠お腹いっぱい。
垢版 |
2010/09/04(土) 07:53:04
残り10000日を切った。

残り9999日と4時間20分ぐらい
0256名無しさん＠お腹いっぱい。
垢版 |
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
0260名無しさん＠お腹いっぱい。
垢版 |
2011/01/21(金) 21:48:30
残り27年age
0265名無しさん＠お腹いっぱい。
垢版 |
2011/04/22(金) 23:55:09.29
アプリケーションが完全に対応するのに10年以上はかかるだろうから
OSは今から10年以内に対応を終える必要がある
0268名無しさん＠お腹いっぱい。
垢版 |
2012/01/21(土) 18:53:05.70
残り26年age
そして、もうすぐスレ立って10年だな
0269名無しさん＠お腹いっぱい。
垢版 |
2012/05/13(日) 17:02:25.07
スレ10周年・・・・って昨日だったかw

2038年問題って大分解決したんだろうか。最近知った話だと、B-CASも2038年問題があるらしい
（契約終了日を表す変数の最大値が0xffff=2038年4月22日なのでそれ以降使えない）
0271名無しさん＠お腹いっぱい。
垢版 |
2012/06/15(金) 20:56:33.88
デジタル放送は20年以内に再び移行させられる（krmmk3） - BLOGOS（ブロゴス）
http://blogos.com/article/41076/
0273名無しさん＠お腹いっぱい。
垢版 |
2012/09/20(木) 09:29:46.02
2038には全く異なるアーキテクチャが出現している筈だった。
なのにおまいらときたら、古いしきたりをいつまでも引き摺りおって
0274名無しさん＠お腹いっぱい。
垢版 |
2012/09/20(木) 20:05:43.24
なんかipv6と話が似てるな
0275名無しさん＠お腹いっぱい。
垢版 |
2013/01/24(木) 00:04:00.02
あと25年
0278名無しさん＠お腹いっぱい。
垢版 |
2013/06/27(木) 01:25:38.34
あと25年か
0279名無しさん＠お腹いっぱい。
垢版 |
2013/08/08(木) NY:AN:NY.AN
最近の気象は異常だと思うよ。人間として生活できる環境が既に崩れつつある。
人としての子作りは、幸福という名の自己満足。今どきの少子は、老後の保険。
お金に余裕があって、水と食料がなければ、適応できなければ自然淘汰される。
0280名無しさん＠お腹いっぱい。
垢版 |
2013/11/21(木) 19:50:46.01
市販のウイルス対策ソフトが、Nationalスパイウェアに化ける時代だよ、みんなどうする？
0282名無しさん＠お腹いっぱい。
垢版 |
2013/11/26(火) 19:05:19.29
米国からの要請で急いでいる特定秘密保護法案
0283名無しさん＠お腹いっぱい。
垢版 |
2013/11/26(火) 20:52:04.77
TPP参加条件
0286名無しさん＠お腹いっぱい。
垢版 |
2015/01/31(土) 19:47:34.65
あと23年。今年の11月14日には7億秒を切る
0288名無しさん＠お腹いっぱい。
垢版 |
2015/12/10(木) 01:53:17.82
ハゲ侍 サブコミュ イケメン スカイプ マリリンマンソン Twitter マリオ64 ゲーム実況者 マリオカート
ハゲ侍 ツイッター 星のカービィ64 マリオサンシャイン ニコニコ超会議 ポケモン フレコ MH4G アメブロ
ハゲ侍 アメーバブログ 仕事 Skype ツイキャス モンハン 歌い手 スプラトゥーン マニアック
ハゲ侍 動画 顔 ドリームクラブ 好き 刃牙 サイレントヒル ドラゴンボール イケボ
ハゲ侍 漫画 フレンドコード NG縛り ニコニコ生放送 歌ってみた 太刀 ニコニコ超パーティー コミュニティ
ハゲ侍 大学 アキネーター 配信 ニコ生 サブコミュ マリリンマンソン イケメン 学歴
ハゲ侍 マリオカート Twitter スカイプ マリオ64 ツイッター ゲーム実況者 星のカービィ64 ニコニコ超会議
ハゲ侍 ポケモン マリオサンシャイン フレコ MH4G アメーバブログ 仕事 Skype ツイキャス
ハゲ侍 モンハン 歌い手 マニアック 動画 アメブロ スプラトゥーン 刃牙 ドリームクラブ
ハゲ侍 好き サイレントヒル ドラゴンボール 漫画 顔 NG縛り フレンドコード ニコニコ生放送
http://kanae.2ch.net/test/read.cgi/pcqa/1421101110/51
http://kanae.2ch.net/test/read.cgi/pcqa/1415921104/55
http://kanae.2ch.net/test/read.cgi/pcqa/1436852775/17
0289名無しさん＠お腹いっぱい。
垢版 |
2015/12/15(火) 07:27:49.85
このスレ2038年まで持つかな？
0290名無しさん＠お腹いっぱい。
垢版 |
2016/01/24(日) 21:53:19.93
西暦じゃなくて皇紀表記にしてしまえばよくないか？
今でも役所のシステムは裏で、昭和91年1月24日21時53分18秒って表記されてるんだろ？
新着レスの表示
レスを投稿する

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