2038年、みんなどうする？

**あぼーん** · NG

俺の保守担当している製品、ためしに2038年にしたら
見事にあぼーん。

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

**名無しさん＠お腹いっぱい。** · 2007/06/03(日) 21:37:36

こうして、なんら解決を見出せぬまま>>1から五年の年月が経ったのであった

**名無しさん＠お腹いっぱい。** · 2007/06/04(月) 17:20:48

特車二科の面々も分散していた。

南雲しのぶ=>海保派失脚のため一躍キャリアに、警視庁最大の粛正人事が行われる。=>現在警視総監
後藤喜一=>しかし海保案はそのまま継承され（美味しいし）、
　　　　　　　　成立した特車大隊隊長に就任　しかし昼行灯は変わらず=>いつも所在を掴むのが困難。
他の面々　適当にｗ　

**名無しさん＠お腹いっぱい。** · 2007/09/30(日) 19:00:43

UNIX TIMEも11億9千万を超え、来年には12億突破だな(Fri Jan 11 2008 06:20:00 GMT+0900)。
突破して一週間後には、2038年問題の日まで残り30年を切るわけだ。

**名無しさん＠お腹いっぱい。** · 2007/10/01(月) 20:54:48

30年か……まだまだっ！

**名無しさん＠お腹いっぱい。** · 2008/01/19(土) 20:22:47

2038年問題発生まで残り30年記念age

**名無しさん＠お腹いっぱい。** · 2008/01/19(土) 20:32:41

>>190
どうせなら、それを今日の12時14分07秒にカキコしてほしかった。

**名無しさん＠お腹いっぱい。** · 2008/01/21(月) 10:02:07

俺曾孫と遊んでるか土の中に入ってる。

**名無しさん＠お腹いっぱい。** · 2008/01/21(月) 13:29:08

>>192
土葬はないだろうから
死体遺棄か？

**名無しさん＠お腹いっぱい。** · 2008/01/21(月) 19:46:24

どうもこのまま行くと2038年頃には革の鎧を着たモヒカン男が
一般市民を襲ってる時代が来そうなのであまり心配する必要はないと思えてきた。

**名無しさん＠お腹いっぱい。** · 2008/01/21(月) 21:28:42

>>194
だが、コマンドラインのUnixなマシンは尚も稼働していたのだった。
新世紀Unix伝説　ラヲウさまはUnixによる覇道完遂　ケンシロウは…

最終決戦で、ラヲウさまは天にボードを突き上げ咆哮「我がうにくす人生に一片の悔い無し」

**名無しさん＠お腹いっぱい。** · 2008/01/26(土) 12:50:18

今日になって、あと 30 年ないことに気がついた・・。

**名無しさん＠お腹いっぱい。** · 2008/01/26(土) 14:30:12

まだ、30年もある訳だ。

**名無しさん＠お腹いっぱい。** · 2008/01/26(土) 14:54:32

そんなの関係ない、そんなの関係ない、そんなの関係ない・・・

おれ多分現役じゃありませんから。

**名無しさん＠お腹いっぱい。** · 2008/01/26(土) 17:40:31

>>197
いや、だから、 30 年もないです。

あと、 29 年 11 カ月とちょっとです。

**名無しさん＠お腹いっぱい。** · 2008/01/26(土) 20:50:45

今のうちに高台へ非難する

**名無しさん＠お腹いっぱい。** · 2008/01/28(月) 20:05:31

預言者ジュセリーノは2042年に人類は滅亡すると言っている。
2038年と4年しか違わない

2038年が人類のタイムリミットに思えてくる。
預言は本当かもしれない、と思うのはやっぱ歳をとったからか

**名無しさん＠お腹いっぱい。** · 2008/01/29(火) 22:47:22

恐怖の大王は2000年問題だってじっちゃんが...

**名無しさん＠お腹いっぱい。** · 2008/01/30(水) 02:33:06

後付けはいいよ、もっとダイナミックな物を考えてくれｗ

**名無しさん＠お腹いっぱい。** · 2008/01/30(水) 04:16:53

2000年問題の後に2038年問題が起こる
一度起きた事をもう一度繰り返す。
それってただの馬鹿じゃん。
問題を先延ばしにしてもそれは解決した事にはならない
根本的な問題を解決できなければそこでUNIXは終わりだな

**名無しさん＠お腹いっぱい。** · 2008/01/30(水) 05:21:43

>二度繰り返す
いや、Y2K需要が記憶から消えた辺りで38を仕掛ければ
大概の企業の担当は世代が入れ替わっているので
ほくほく、同じ手でボッたくれるのです。

**名無しさん＠お腹いっぱい。** · 2008/02/03(日) 10:11:37

特に>>204のようなのが役職に就いている会社から搾れるだけ
搾り取るとよいでしょう。

**名無しさん＠お腹いっぱい。** · 2008/02/03(日) 13:14:42

>>203
動的というなら

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

2GB以上一度に確保するとやばいことになる予感

**名無しさん＠お腹いっぱい。** · 2008/02/11(月) 19:59:53

ext2, ext3, ext4も2038年問題抱えてるみたいだな。つい最近出たext4でも直さないなんて大丈夫か？

**名無しさん＠お腹いっぱい。** · 2008/02/11(月) 21:31:42

そういうのは気にならない人たちが使うものだから

**名無しさん＠お腹いっぱい。** · 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バグでえらい苦労した)、あまり自分ではやりたくないなあ。

誰か手をあげてくれないかなあ。

**名無しさん＠お腹いっぱい。** · 2008/02/20(水) 11:58:06

UNIX誕生から約40年、これから約30年あることを考えれば、
そのうちなんとかなるべよ、って気もする

**名無しさん＠お腹いっぱい。** · 2008/02/22(金) 02:58:32

>>207
別に確保に失敗すればNULLを返すだけでしょ。
今も何も変わらない。

**名無しさん＠お腹いっぱい。** · 2008/02/22(金) 09:11:08

>>79あたりが折り返し地点だったみたいですね。

64bit time_tもsignedにしてくれると過去への応用が広がるね。

**名無しさん＠お腹いっぱい。** · 2008/02/22(金) 09:12:01

>>210
この実装は洒落でしょ?
rubyで実装してどうすんだよ。

**名無しさん＠お腹いっぱい。** · 2008/02/23(土) 11:36:03

>>135
今更だがおまえだけ生き残っている理由が知りたい

**名無しさん＠お腹いっぱい。** · 2008/02/27(水) 02:09:58

せっかくの特需を自分たちの手で摘み取ってしまうこともあるまい

**名無しさん＠お腹いっぱい。** · 2008/03/11(火) 22:23:56

あと３０年

**名無しさん＠お腹いっぱい。** · 2008/03/28(金) 12:02:41

>>79
これって、予言されていたんだよね・・・。

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

**名無しさん＠お腹いっぱい。** · 2008/03/31(月) 16:23:44

死んでたらむなしいな～

**名無しさん＠お腹いっぱい。** · 2008/05/05(月) 10:19:03

日付関係の問題

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

おせーよｗ

**名無しさん＠お腹いっぱい。** · 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日

**名無しさん＠お腹いっぱい。** · 2008/09/20(土) 18:08:03

2038年問題じゃないが、2036年問題まで残り9999日。

**名無しさん＠お腹いっぱい。** · 2008/09/25(木) 00:36:15

昨日は12億2222万2222秒があった

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

**名無しさん＠お腹いっぱい。** · 2008/10/02(木) 12:45:08

2038年～新しいウィルスが開始した

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

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

2041年～世界全滅

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

**名無しさん＠お腹いっぱい。** · 2008/12/10(水) 18:06:09

>>208-209
extだけじゃなくてxfsやjfsも32bitなのを見ると
38年問題を意図的にばら撒いてないか？ｗ
地雷仕込んで30年後に一儲けですかｗｗ

**名無しさん＠お腹いっぱい。** · 2008/12/10(水) 18:19:47

とりあえずbtrfs町という状況がよく分かったわ

**名無しさん＠お腹いっぱい。** · 2008/12/11(木) 17:00:23

ファイルシステムは簡単に乗り換えがきくからではないだろうか。

**名無しさん＠お腹いっぱい。** · 2008/12/12(金) 01:54:25

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

**名無しさん＠お腹いっぱい。** · 2008/12/12(金) 17:40:14

coreutilsを64bitOSで動かせばいいんじゃないの？
ファイルシステムが32bitだから64bitOS使っても38年問題が残るという話なんだけど

**名無しさん＠お腹いっぱい。** · 2008/12/12(金) 18:16:54

いや、嘘言ってしまった
Linux立ち上げて確認したら38年以降の日付に出来た。スマソ

**名無しさん＠お腹いっぱい。** · 2008/12/12(金) 22:15:23

64bitOS(ILP64)では、sizeof(size_t)は必然的に8になってるだろうが、
sizeof(time_t)を必ず8にする必要はない。
逆にIP32でもtime_tは64bitにした方が良い。IP16でさえ。

**名無しさん＠お腹いっぱい。** · 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%消滅してるはずなので、
これが一番現実的かも。

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2008/12/25(木) 09:45:21

>>233
> あと、参考までにこの間x86-64で試した結果

OS書かないと意味ねえ。

**名無しさん＠お腹いっぱい。** · 2008/12/27(土) 13:48:06

>>234
Linux (Fedora 9), gccは4.0だったか4.1だと思う。サイズって同一アーキテクチャ用でも*BSDとLinuxじゃ違うのか？

**名無しさん＠お腹いっぱい。** · 2009/01/11(日) 14:20:45

19 日であと 29 年かぁ。

**名無しさん＠お腹いっぱい。** · 2009/01/11(日) 15:00:51

そういうわれるととても先の話に思えるな

**名無しさん＠お腹いっぱい。** · 2009/01/12(月) 15:44:37

来年で2000問題から10年

**名無しさん＠お腹いっぱい。** · 2009/01/20(火) 23:58:22

1日オーバーしたけど、残り29年切ったね

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2009/02/14(土) 08:37:30

http://takeshima.2ch.net/test/read.cgi/news4vip/1234567890/
http://changi.2ch.net/test/read.cgi/entrance/1234567890/

**名無しさん＠お腹いっぱい。** · 2009/05/22(金) 03:21:55

保守

**名無しさん＠お腹いっぱい。** · 2009/07/13(月) 20:14:10

2038年問題まであと9億秒。

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2009/09/16(水) 14:12:30

永眠するから関係ないよ

**名無しさん＠お腹いっぱい。** · 2010/01/10(日) 14:06:28

19 日であと 28 年かぁ。

**名無しさん＠お腹いっぱい。** · 2010/01/19(火) 18:58:56

2038年1月19日は今日と同じ火曜日でうるう年の2年後。
月日曜日だけが問題になるシステムなら2010年か1982年に戻せばいいかもしれないがそんなシステム少ないですよね。

**名無しさん＠お腹いっぱい。** · 2010/01/19(火) 23:36:01

残り28年。まだまだ先だけど、着実にその時は近づく…

**名無しさん＠お腹いっぱい。** · 2010/01/20(水) 00:02:46

2038年に備えて脱it化を目指そう

**名無しさん＠お腹いっぱい。** · 2010/01/20(水) 00:05:17

ゆとり世代涙目wwwww

**名無しさん＠お腹いっぱい。** · 2010/01/20(水) 12:19:54

あと28年たったら見られてまずいデータは全部自動的に処分されると考えればOK

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 16:45:04

2036年2月6日 6時28分15秒 (UTC)

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

**名無しさん＠お腹いっぱい。** · 2010/02/07(日) 17:27:11

おめ

**名無しさん＠お腹いっぱい。** · 2010/09/04(土) 07:53:04

残り10000日を切った。

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

**名無しさん＠お腹いっぱい。** · 2010/09/04(土) 11:04:52

おめ

**名無しさん＠お腹いっぱい。** · 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

**名無しさん＠お腹いっぱい。** · 2010/09/16(木) 18:44:47

http://www.timeanddate.com/counters/customcounter.html?day=19&month=1&year=2038&hour=3&min=14&sec=8&p0=0

**名無しさん＠お腹いっぱい。** · 2010/12/02(木) 01:05:39

OSレベルでは結構対応進んでるから大丈夫って感じ

**名無しさん＠お腹いっぱい。** · 2010/12/02(木) 13:34:14

現役引退してますw

**名無しさん＠お腹いっぱい。** · 2011/01/21(金) 21:48:30

残り27年age

**名無しさん＠お腹いっぱい。** · 2011/01/21(金) 22:39:06

生きてるかな

**名無しさん＠お腹いっぱい。** · 2011/01/24(月) 08:11:36

そこまで生きてる自信がイマイチでス

**名無しさん＠お腹いっぱい。** · 2011/03/17(木) 17:06:14.64

高専生の俺がなんとかする
大人は黙って待っとけ

**名無しさん＠お腹いっぱい。** · 2011/04/08(金) 10:34:23.92

がんばれ

**名無しさん＠お腹いっぱい。** · 2011/04/22(金) 23:55:09.29

アプリケーションが完全に対応するのに10年以上はかかるだろうから
OSは今から10年以内に対応を終える必要がある

**名無しさん＠お腹いっぱい。** · 2011/05/09(月) 13:02:44.72

仕事で使ってるんではなければ時計をを10年戻せばいいだけだろ

**名無しさん＠お腹いっぱい。** · 2011/05/10(火) 21:52:05.69

OSは既に割と対応してる感じ

**名無しさん＠お腹いっぱい。** · 2012/01/21(土) 18:53:05.70

残り26年age
そして、もうすぐスレ立って10年だな

**名無しさん＠お腹いっぱい。** · 2012/05/13(日) 17:02:25.07

スレ10周年・・・・って昨日だったかw

2038年問題って大分解決したんだろうか。最近知った話だと、B-CASも2038年問題があるらしい
（契約終了日を表す変数の最大値が0xffff=2038年4月22日なのでそれ以降使えない）

**名無しさん＠お腹いっぱい。** · 2012/05/19(土) 16:55:02.77

どうでもいいけどコンピュータの世界って
>>19
のまさかそこまでは使わないだろうでハマるパターンが結構あるよね

**名無しさん＠お腹いっぱい。** · 2012/06/15(金) 20:56:33.88

デジタル放送は20年以内に再び移行させられる（krmmk3） - BLOGOS（ブロゴス）
http://blogos.com/article/41076/

**名無しさん＠お腹いっぱい。** · 2012/09/16(日) 19:38:20.64

2038年問題まであと8億秒
http://slashdot.jp/story/12/09/12/1139258/2038%E5%B9%B4%E5%95%8F%E9%A1%8C%E3%81%BE%E3%81%A7%E3%81%82%E3%81%A88%E5%84%84%E7%A7%92

**名無しさん＠お腹いっぱい。** · 2012/09/20(木) 09:29:46.02

2038には全く異なるアーキテクチャが出現している筈だった。
なのにおまいらときたら、古いしきたりをいつまでも引き摺りおって

**名無しさん＠お腹いっぱい。** · 2012/09/20(木) 20:05:43.24

なんかipv6と話が似てるな

**名無しさん＠お腹いっぱい。** · 2013/01/24(木) 00:04:00.02

あと25年

**名無しさん＠お腹いっぱい。** · 2013/04/26(金) 23:34:15.17

退職してる

**名無しさん＠お腹いっぱい。** · 2013/06/01(土) 00:07:08.49

残り9000日を切った。あと8998日

**名無しさん＠お腹いっぱい。** · 2013/06/27(木) 01:25:38.34

あと25年か

**名無しさん＠お腹いっぱい。** · 2013/08/08(木) NY:AN:NY.AN

最近の気象は異常だと思うよ。人間として生活できる環境が既に崩れつつある。
人としての子作りは、幸福という名の自己満足。今どきの少子は、老後の保険。
お金に余裕があって、水と食料がなければ、適応できなければ自然淘汰される。

**名無しさん＠お腹いっぱい。** · 2013/11/21(木) 19:50:46.01

市販のウイルス対策ソフトが、Nationalスパイウェアに化ける時代だよ、みんなどうする？

**名無しさん＠お腹いっぱい。** · 2013/11/25(月) 00:18:57.33

特需がくるわ

**名無しさん＠お腹いっぱい。** · 2013/11/26(火) 19:05:19.29

米国からの要請で急いでいる特定秘密保護法案

**名無しさん＠お腹いっぱい。** · 2013/11/26(火) 20:52:04.77

TPP参加条件

**名無しさん＠お腹いっぱい。** · 2014/02/09(日) 13:44:15.87

残り24年・・・十二支があと2回りしたら2038年問題か

**名無しさん＠お腹いっぱい。** · 2014/03/13(木) 18:53:56.08

早いなぁ…
結構先のことだと思ってたけど

**名無しさん＠お腹いっぱい。** · 2015/01/31(土) 19:47:34.65

あと23年。今年の11月14日には7億秒を切る