2038年、みんなどうする?
俺の保守担当している製品、ためしに2038年にしたら 見事にあぼーん。 time_tどうなんのよ。 ちなみに俺の定年まであと35年・・。 微妙。
今年生まれる子が、2038年には36歳。 心配しなくてもこいつらがなんとかしてくれる。 >>4 確かにうたがう余地無しだな。こんちくしょう >>3 その通り。年金問題も国債債務問題も靖国問題も環境問題も 官僚問題も同和問題も憲法第9条も特殊法人問題も構造改革も全て先送り。 私達の子孫が何とかしてくれる。 >>6 そして子孫達は問う。 なぜ私達の祖先は何もしなかったのかと。 >>3 「もうUNIXがわかる技術者は君達しかいない」と再召集される罠 time_tを64bitにすれば解決、とかいう話ではない? もちろんファイルシステムとかバイナリデータの互換性は失われるけど。 年号を4桁にすれば解決、とかいう話ではない? もちろんデータベースとかバイナリデータの互換性は失われるけど。 >>8 なぜ、そーゆうコンテクストでは、「金属」バットなんだろ? 木製の方がイケテルとおもうんだけどなぁ。 >>13-14 誰かが勝手にちめを1970に決めてしまったのだから また誰かが2010くらいに起点を決めて うすらとぼければいいのではという話ではない? ところでSunとその上にのるメジャーな商用ソフトは 38年問題は解決済みなのかな?もちろんレガシー の話は抜きにして。 >>17 2038にサポートしてない現在のOSやハードに商用ソフトが (サポート終了しているといえばいいか) あえて解決策をとったりソレを公にアピールする必要は無いと思われ。 64bit化の過程で偶然解決された(される)ことはあるだろうが 2000年問題の事例をみればわかるだろうが 30年経ったらまた書き込むとベスト つーかこのご時世、そこまでつかいつづけんでしょ。 2038年が来る前に、旧いマシンの部品供給がでけんよーになってあぼーんヨ。 アホな会社が、1990年代のソースを2038年まで使いつづけてたら知らんけど。 >>9 ありえない話じゃないような気が。 老人になった俺らがBSDを再起動させるのさ。 おまたのボタンお押して再起動させてみるテスト 俺が定年になってるころには出てるはずだ〜!!!!!!!! だれか作ってくれ〜!!!! Registrant: 2038 (2038-N-DOM) planterarv 19 120 48 enskede gard stockholm, se 120 48 SE Domain Name: 2038.COM Administrative Contact, Technical Contact: J.E, Namnet (EB3084)domain-registry@MRFRIDAY.COM erik bar Administrator Sdra Hamnvgen 48 115 41 STOCKHOLM STOCKHOLM SWEDEN 115 41 SE +46-8-641 95 9 +46-8-641 95 9 Record expires on 22-May-2003. Record created on 22-May-1998. Database last updated on 5-Apr-2003 22:26:03 EST. Domain servers in listed order: NS1.SKARPODATA.COM 193.45.208.2 NS2.SKARPODATA.COM 193.45.208.3 32bitなんて、30年後には今の8bitマシン以下の用途になってるだろう。 Windowsもビルゲイツが死んだら終り。 ま〜 time_t を unsigned にしちゃえば22世紀頃まで持つんで、 ファイルシステムとかDBとかのバイナリデータはあんま問題ないと思うけど。 問題はsignedで大小比較してるプログラムのほうだな。 ほんとだ。time_tってsignedだったんだ。知らなかった。 unsigned intにしたら2106年までもつのね…死んでるからそれでいいや。 てことは、逆に考えると前世紀はまるまる今のtime_t で表せるってこと? /* LP64 の環境なら解決済みじゃない? */ #ifndef _TIME_T #define _TIME_T typedef long time_t; /* time of day in seconds */ #endif /* _TIME_T */ 2038年にUNIXって存在するのか? CUI自体ほとんどつかわれていないんじゃないか? そうでもないかな・・・ >>37 おまえが使ってないだけではと小一時間...(ry >>37 正直、低能力なハードウェア性能のせいで ■無闇やたらに視覚に依存しすぎ、かつ重厚長大で能力の低い出力デバイス ■思った通りに操作するために高い習熟が必要で、かつ体に余計な負荷がかかる 入力デバイス にべったりと依存せざるを得ない、今の形式の「GUI」というシロモノも、 35年先には骨董品としてしか生き残っていないような気がするけどなぁ まあ>>37 は世間しらずのヒキー ドザかマカ。 2038年には、ソラリスもAIXもHP-UXもないだろうな。 残るのは、Win BSD Linux . ただし、このどれも現状とは全く違う環境だろうけど。 もしくは、まったく違うOSが出て MSが、そこ潰しにかかって買収して生き残って 技術的な事は公開せず、乗り遅れたBSDやらlinuxは死ぬか。 もしくは、linuxやBSDコミュニティから新しい物が出てくるか。 記念パピコ 漏れの誕生日が1021 妹1212 因縁を感じますた。 >>1 今のうちに全てのシステムを64bitに移行で解決。いじょ UNIXってCのタイプシステムにべったりじゃん。 しかもCの言語的ないい加減さで実装依存だったりするし。 もちろん、それを言い出したらWindowsやMacだってそうなんだけど。 最終的な答えだとは勿論思わないけど、.NETの目指すCommonTypeSystemってのは この辺りのやっかいな問題も含めて考えられているから好きだ。Javaには こういう視点はなかった。以後2038年問題を、time_tをunsigned intにするとか、 時間の起点を2010年にするなどといった珍案で、小手先の回避をするのではなくて 38年までには根本的な解決がなされている方がいいなあ。ある意味、UNIXを 部分的に否定することを意味するけど。 1970年1月1日からの秒数だからな ライブラリがダメっぽ perl のtimeとか・・・ GPSもあれだっけ? MSのlibcが2036年で溢れたような気がするので、 その対策を真似すればいいだろう。 その頃には現行システムは無いだろうなぁ・・・ 若者達に期待w つーか、虫歯無くしたら歯医者が潰れる、ってのと一緒なんでw まぁ2038年特需だ罠。その前にIPv6特需もありそうだが。 つーか、unsigned longかハードとOSが64bit対応して解決しそうなんだけど、、、 時計を巻き戻して使うのがデフォルトのOSが出るとか。 来年まで生きているか分からないので、どうでもいいや… >>76 そういう人に限って、2037年に引っ張り出されていろいろ苦労するだろう、 と想像してみる。 この前、ATM止まったでしょ。あれプチ2038年問題と言えなくもない。 time_tが0x3FFFFFFFから0x40000000になった途端、バッファが溢れてあぼーん。 ま、そういうコード書いた香具師が悪いんだけど。 >>79 いまさらそんなこと誇らしげに書かれても。 38年特需が今から待ち遠しいです。 そのために問題解決をよりこんなんな方向に仕向ける 何かが必要です。マシンをリプレースして万事OKなんて お手軽なやつじゃダメなんです。 128bitUNIXと2038年問題はどっちが先にやってくるでしょうか? time_tってそもそも32ビットのうち1ビットは正負の符号に使ってるの? 俺はそのころ47歳か・・・。 もうそんな歳になっちまったら、正直世の中どうなってても何ともおもわんよ。 >>99 signed longですから。しょうがない。 2000念問題が何事もなかったんだから何も起こらない。 就労 2038年問題を安心して見届けてぽっくり死ぬ奴がこのスレにいるだろうな。 それよりも30828年問題が気になります。 (WindowsのFILETIMEがオーバーフロー) 2038年、2ちゃんが動かなくなっちゃうぞ!あとc言語のプログラムも。。。 たいへんだぁ。2000ねん問題よりも深刻らしいぞ。 タダ単にプログラムを書き換えればいい問題じゃないぞ。 で、何もしないまま>>1 から1413日経過したわけだが 2038年問題勃発まであと11622日と20時間50分 http://sunpillar2004.hp.infoseek.co.jp/javascript/2038.shtml#TIMER 今年中には残り時間10億秒を切っちゃうよ。 BTAMの時刻オーバーフローが懐かしい。 歴史は何度も繰り返すだろう。 本日10時27分28秒、Xデーまで残り10億秒を切りました。 1234567890 2009/02/14 08:31:30 2000000000 2033/05/18 12:33:20 2047483648 2034/11/19 02:27:28(残り1億秒) 焦ってるのはお前ら小物だけで、 ゲイツやジョブスやリナズはもう策を見出しているよ。 2038年に年金の支給年齢に達してれば良いけどな。 少しづつ遠ざかっているような気がするな。 そういや2ちゃんねるのスレのURLって 1970/1/1 0:00:00 GMT からの秒数を使ってるよな… てことはやっぱ time() 使ってるということで、2038年には2ちゃんねるが終わるということだな。 64ビットマシンがいくつかあるみたいだからどうなんでしょ? おーい、2038年の奴、見てる? 今は2006年の世界だよ >>124 見てるよ。 2030年に、タイムスタンプの1970-1999年の30年間の分を、 60年加算して2030-2059年までの意味を表すものとして 再利用する方法が採択されました。 以降、30年毎にこの方式でタイムスタンプをエンドレスに使い回します。 これにより、タイムスタンプは過去最低30年間分しか表現できなくなりますが、 オーバーフローすることはなくなります。 あと32年後に、今のマシンが動いてるかどうか。 OSがあっても動いているマシンがない。 アプリケーションなんかもお蔵入り。 よって心配する必要はない。 >>123 それだと584942417318年ぐらいで終わりだよね。 2037年まで放置して やばくなったら大騒ぎして対応する。 山奥に非難する人とかいっぱい出るだろう よくわからないが長生きしてしまい、のんびり暮らしていたら2038年になり、 金のない後進国の古いシステムが暴走してミサイルが発射され、最初の弾が >>132 に当たって死亡。2発目の弾は山奥に飛んで行き>>133 に当たって死亡。 核が搭載されていたので時間を掛けて>>1-131 ,>>134 が死亡。 寝てる、2038年 寝たきりで電脳化して択捉島あたりで… UNIXも68歳。俺も同い年。 嫌だねえ、自分の糞もふけなくなる前に自殺するか。 あと30年位だろ 保険とか年金のシステムだともう対応済のはずだよな 保険とか年金のシステムだと そもそも破綻してそうだな。 perl -e 'print "UNIX滅亡まであと",0x80000000-time,"秒\n";' >>141 おぃおぃ、それくらいperl使わずにシェルでやれよ。 echo 'UNIX滅亡まであと'`expr 2147483648 - \`date -u +%s\``'秒' 2038年 相変わらず魔法使いは健在なのであった。 $ crontab -l 14 12 19 1 * if [ `date +%Y` -eq 2038 ]; then echo 'UNIX滅亡まであと7秒' ; fi $ ■ >>144 よく考えたら間に % があるから駄目かな… 14 12 19 1 * if [ `date +%%Y` -eq 2038 ]; then echo 'UNIX滅亡まであと7秒' ; fi こうじゃね? 14 12 19 1 * if [ `date +\%Y` -eq 2038 ]; then echo 'UNIX滅亡まであと7秒' ; fi こうだったorz 1億1600万秒オーバー保守 1億1700万秒は2007年1月29日午前1時丁度。 桁間違えたorz 11億6000万秒 と11億7000万秒だな 【近未来】西暦2035年直径約1kmの小惑星が地球に衝突の可能性"ロシア科学アカデミーの研究者グループが発表"★2 http://news19.2ch.net/test/read.cgi/newsplus/1161477475/l50 解決だな。 とりあえず暇つぶしに俺のHPw http://afox.s206.xrea.com/ uuussatm@gmail.com 年40レス…20年で800レス。2038年までは持たないが、2027年まではこの調子なら持ちそうだな? >>147 相手鯖のBOXまで逝くのに7秒以上かかったり、中継路の鯖の時計が少し進んでたら・・・ たとえば > 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 > とか あるいは > 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 > など 俺はすでに引退し死でるか老人ホームだろうから知らんがそのころは今のOSの概念はないだろう。 すべて脳内にあったりしてな、そして頸椎あたりの首筋にプラグ挿入口が 2001年には木星か土星に有人飛行できるだろうと予想されていたのが 見事に外れている現実を見ても、2038年になっても 今のOSと状況はほとんど変わっていないだろう。 JavaのSystem.currentTimeMillisって対策されてる? 型はint64かも知れんけど、内部でtime_t使ってたらアウトだよね Javaは走らせるマシンしだいだろ?常識的に考えて。 一度多少なりとも流行った言語はそう簡単に消滅しないだろ ジャバって聞くと、風呂の湯沸し器の穴掃除する奴思い出す >>159 コンピュータ関係は進歩速いと思うけどな。8bit CPU が流行っていたのが 約30年前、20年前は16bit、10年前は32ビット、で、この頃は64bitが流行り 始めた。てことは128bitは10年後で、256bitが20年後。2038年は多分512bit。w だが、どうやって開発の為の小銭を稼ぐかだな。 32bit以上では、一般に対する更新喚起は望めないぞ。 未来なんてどっちに転ぶかなんてわからんよ。 秋葉原でメイド喫茶がこれほど乱立する未来を誰が予測できただろうか。 >>171 あそこのヤッチャバで江戸弁の職人が マイドと言わず メードって言ってたころ予見していたよ 一般家庭は兎も角、事務系のぼろいパソコンはいまだDOSだったり、なんだかよく分からないOSだったりするぞ 某理髪店なんて、レジの管理システムPC-9821とDOS+DOSアプリケーションだぞ。 俺らも業務内容を散髪に転換すれば、OSなんかDOSで良くなるわけだよ。 2038年に備えて、とりあえずcut(1)を丹念に読んどけばいいのか? 2038年 ... どうでもいいや。引退しているぉ。 寝てる、頸椎にはプラグ挿入 そしてネットの海へダイブ。 CPUもOSも64bitにしちゃえというのは解決しているようで、 現実的には何も解決してないよな そのシステムはかつて私がかかわった事もあるものだ。 根幹部分のロジックもわかっている。私が退いたあと の変更点の情報はないが、これまでの改修を追って来た 限りでは大規模な変更は行われていない。 私は静かにその時を待った。OS,ミドルウェアのアップ デートが適切が行われているならシステムが致命的な 挙動を示し停止するということは起きないだろう。 だが、その上で動作している内製のアプリケーション はどうか。私の知る限りでは小さな問題が内在されて いた。その問題自体はアプリケーションに即座に致命 的な問題を引き起こすわけではない。 しかし、ある特殊なシークェンスの入力を受け付けた場 合にそれとわかるイレギュラーな挙動を示すのである。 私がただ待っているのは今のシステムを担当しているエ ンジニアたちがその問題に気づいたか、適切な対応をお こなったかを知りたいからである。 そして私はこのために注意深く作り上げたスクリプトを 実行する時を待っていた。 こうして、なんら解決を見出せぬまま>>1 から五年の年月が経ったのであった 特車二科の面々も分散していた。 南雲しのぶ=>海保派失脚のため一躍キャリアに、警視庁最大の粛正人事が行われる。=>現在警視総監 後藤喜一=>しかし海保案はそのまま継承され(美味しいし)、 成立した特車大隊隊長に就任 しかし昼行灯は変わらず=>いつも所在を掴むのが困難。 他の面々 適当にw UNIX TIMEも11億9千万を超え、来年には12億突破だな(Fri Jan 11 2008 06:20:00 GMT+0900)。 突破して一週間後には、2038年問題の日まで残り30年を切るわけだ。 >>190 どうせなら、それを今日の12時14分07秒にカキコしてほしかった。 どうもこのまま行くと2038年頃には革の鎧を着たモヒカン男が 一般市民を襲ってる時代が来そうなのであまり心配する必要はないと思えてきた。 >>194 だが、コマンドラインのUnixなマシンは尚も稼働していたのだった。 新世紀Unix伝説 ラヲウさまはUnixによる覇道完遂 ケンシロウは… 最終決戦で、ラヲウさまは天にボードを突き上げ咆哮「我がうにくす人生に一片の悔い無し」 今日になって、あと 30 年ないことに気がついた・・。 そんなの関係ない、そんなの関係ない、そんなの関係ない・・・ おれ多分現役じゃありませんから。 >>197 いや、だから、 30 年もないです。 あと、 29 年 11 カ月とちょっとです。 預言者ジュセリーノは2042年に人類は滅亡すると言っている。 2038年と4年しか違わない 2038年が人類のタイムリミットに思えてくる。 預言は本当かもしれない、と思うのはやっぱ歳をとったからか 恐怖の大王は2000年問題だってじっちゃんが... 後付けはいいよ、もっとダイナミックな物を考えてくれw 2000年問題の後に2038年問題が起こる 一度起きた事をもう一度繰り返す。 それってただの馬鹿じゃん。 問題を先延ばしにしてもそれは解決した事にはならない 根本的な問題を解決できなければそこでUNIXは終わりだな >二度繰り返す いや、Y2K需要が記憶から消えた辺りで38を仕掛ければ 大概の企業の担当は世代が入れ替わっているので ほくほく、同じ手でボッたくれるのです。 特に>>204 のようなのが役職に就いている会社から搾れるだけ 搾り取るとよいでしょう。 >>203 動的というなら メモリがでかくなりすぎて、そろそろmallocの引数が悲鳴を上げるんじゃね? 特に32bit版でコンパイルして、64bit版で使った場合。互換性あるようコンパイルしとけば、そのまま使えるでしょ。たしか 2GB以上一度に確保するとやばいことになる予感 ext2, ext3, ext4も2038年問題抱えてるみたいだな。つい最近出たext4でも直さないなんて大丈夫か? 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バグでえらい苦労した)、あまり自分ではやりたくないなあ。 誰か手をあげてくれないかなあ。 UNIX誕生から約40年、これから約30年あることを考えれば、 そのうちなんとかなるべよ、って気もする >>207 別に確保に失敗すればNULLを返すだけでしょ。 今も何も変わらない。 >>79 あたりが折り返し地点だったみたいですね。 64bit time_tもsignedにしてくれると過去への応用が広がるね。 >>210 この実装は洒落でしょ? rubyで実装してどうすんだよ。 >>135 今更だがおまえだけ生き残っている理由が知りたい せっかくの特需を自分たちの手で摘み取ってしまうこともあるまい >>79 これって、予言されていたんだよね・・・。 [linux-users:70300] y2k+4 problem. http://search.luky.org/linux-users.7/msg00300.html 2038年問題他のカウントダウンRSS作ってみた http://sunpillar.jf.land.to/cgi-bin/RSS/rss.cgi?rss=countdown 2038年問題が発動するまでサイトが持つかどうかわからないし、 今後RSSなんて廃れた技術になっちゃうかもしれないがw あと日で計算してるから、秒計算のカウントダウンタイマーとは1日ずれる時間帯がある -- 2038年問題発生まであと10822日 2038年問題じゃないが、2036年問題まで残り9999日。 2038年〜新しいウィルスが開始した 2040年前半〜限界のウィルスが壊れた 2040年後半〜ウィルスでゾンビ達になった。アメリカから 2041年〜世界全滅 2056年〜世界で20人は生き残っています >>208-209 extだけじゃなくてxfsやjfsも32bitなのを見ると 38年問題を意図的にばら撒いてないか?w 地雷仕込んで30年後に一儲けですかww ファイルシステムは簡単に乗り換えがきくからではないだろうか。 システムコールはそうでないから、/* e.g.stat(2) */ ファイルシステムだけ64bitにしても、 結局は既存のls(1)等が利用できるように32bitにして渡してやらないといけない。 つまりユーザ側からは64bitになったことは見えない。 というわけで、急いで64bitにする必然性がない。 fpos_tが64bitになった時のように、 システムコールを二枚立てにするんじゃないかな。 coreutilsを64bitOSで動かせばいいんじゃないの? ファイルシステムが32bitだから64bitOS使っても38年問題が残るという話なんだけど いや、嘘言ってしまった Linux立ち上げて確認したら38年以降の日付に出来た。スマソ 64bitOS(ILP64)では、sizeof(size_t)は必然的に8になってるだろうが、 sizeof(time_t)を必ず8にする必要はない。 逆にIP32でもtime_tは64bitにした方が良い。IP16でさえ。 ext2のmtime unsigned int struct inodeのmtime long なので 64bitOSなら19700101を起点として2106まで使えるということみたいですね。 struct inodeの中の日付データはlongなのでキャッシュされてる時点では、 unsigned intの範囲外のデータも扱えるということですか。64bitOSにて、 2106以降の日付を誤って入力した場合、保存されるデータはすべて2106に直されるけど、 1970以前の値の場合はどんな値になるか、入力されたデータ次第ということですね。 30年後は分からないけど、100年後にはLinuxなんて100%消滅してるはずなので、 これが一番現実的かも。 >>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 >>233 > あと、参考までにこの間x86-64で試した結果 OS書かないと意味ねえ。 >>234 Linux (Fedora 9), gccは4.0だったか4.1だと思う。サイズって同一アーキテクチャ用でも*BSDとLinuxじゃ違うのか? 2009年2月14日 08:31:30(JST)にUNIX TIMEが1234567890になる。 UNIX time が「1234567890」になる http://slashdot.jp/articles/09/02/09/012251.shtml >>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 2038年1月19日は今日と同じ火曜日でうるう年の2年後。 月日曜日だけが問題になるシステムなら2010年か1982年に戻せばいいかもしれないがそんなシステム少ないですよね。 残り28年。まだまだ先だけど、着実にその時は近づく… あと28年たったら見られてまずいデータは全部自動的に処分されると考えればOK 2036年2月6日 6時28分15秒 (UTC) 2036 年問題までも、あと 26 年をきったか。 残り10000日を切った。 残り9999日と4時間20分ぐらい 残り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 アプリケーションが完全に対応するのに10年以上はかかるだろうから OSは今から10年以内に対応を終える必要がある 仕事で使ってるんではなければ時計をを10年戻せばいいだけだろ 残り26年age そして、もうすぐスレ立って10年だな スレ10周年・・・・って昨日だったかw 2038年問題って大分解決したんだろうか。最近知った話だと、B-CASも2038年問題があるらしい (契約終了日を表す変数の最大値が0xffff=2038年4月22日なのでそれ以降使えない) どうでもいいけどコンピュータの世界って >>19 のまさかそこまでは使わないだろうでハマるパターンが結構あるよね デジタル放送は20年以内に再び移行させられる(krmmk3) - BLOGOS(ブロゴス) http://blogos.com/article/41076/ 2038には全く異なるアーキテクチャが出現している筈だった。 なのにおまいらときたら、古いしきたりをいつまでも引き摺りおって 最近の気象は異常だと思うよ。人間として生活できる環境が既に崩れつつある。 人としての子作りは、幸福という名の自己満足。今どきの少子は、老後の保険。 お金に余裕があって、水と食料がなければ、適応できなければ自然淘汰される。 市販のウイルス対策ソフトが、Nationalスパイウェアに化ける時代だよ、みんなどうする? 残り24年・・・十二支があと2回りしたら2038年問題か ハゲ侍 サブコミュ イケメン スカイプ マリリンマンソン 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 西暦じゃなくて皇紀表記にしてしまえばよくないか? 今でも役所のシステムは裏で、昭和91年1月24日21時53分18秒って表記されてるんだろ? >>291 昭和でも2025年、皇紀でも2040年、平成でも2089年しか持たないんだよな (2桁表示の場合) 残り21年切ったな スレ始まってもうすぐ15年だが折り返しにはあと3年あるか 1970-2038 の折り返しはすでに過ぎていますね。 誰でも簡単にパソコン1台で稼げる方法など 参考までに、 ⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。 グーグル検索⇒『宮本のゴウリエセレレ』 MO5LP1YKVV >>190 から10年。あと20年を切った 10年で100レス強なら500前後で2038年問題がやってくるかな? 今日で7304日だから今年の暮れには残り7000日を切るな 知り合いから教えてもらったパソコン一台でお金持ちになれるやり方 時間がある方はみてもいいかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 3D4H9 xp x64 版で2038年問題を試してみた。 WinMediaPlayer10が開けないという事態になった...orz MS技術者ならtime_t使ってないはずなんだけどなぁ。どこからコードパクったんだろう。 ツイッターで#テクノロジー犯罪と検索して、まじでやばいことを四代目澄田会の幹部がやってる 被害者に対して暴力団以外にタゲそらしをしてるがやってるのは暴力団で普段外に出ることが少ないため遊びで公共の電波と同じような電波を使って殺人をしてる 統失はほとんどが作られた病気で実際は電波によって音声送信や思考盗聴ができることが最近明らかになりつつある 警察や病院では病気としてマニュアル化されてしまっているのが現状で被害者は泣き寝入りしてる 被害者がリアルタイムで多い現状を知って、被害者間でしか本当の事だと認知できていない 実際にできると思われていない事だから、ただの幻聴ではない実際に頭の中で会話ができる できないことだと思われているからこそ真面目に被害を訴えてる 海外でも周知されつつあることを知ってほしい。 このままだとどんどん被害が広がる一方 #テクノロジー犯罪 #四代目澄田会 そもそもの話、西暦やEPOCHタイムのような一つのタイムラインを延々と使い続けること自体に無理があるんだよ。 UNIXタイムのように2038年を64ビットにして西暦100億年先まで大丈夫と謂われても、結局西洋式の時間的概念だと一見合理的だが、必ず終焉への特異点は避けて通れないようになっている。 結局、UNIX上の西暦表記もEPOCHタイムを置き換えてるだけで、たまたま政治的な優位性で西暦をデフォルトで表示してるようなもの。 電算機を扱う上では、一つのタイムラインで続けるんじゃなく、元号のように一つの時代が終わると一度リセットし、新しい元号を使うことで時間的な特異点を迎えることなく、常若の精神のもと延々と繁栄し続けることが可能になる。 EPOCHタイムや西暦のような一つのタイムラインで管理するカレンダーはダメだってことは、前の文明アトランティス文明、ムー文明、レムリア文明で証明されてんじゃん。 やっぱ、電算機の時間も式年遷宮方式が一番いいと思うぞ。 ・signed 32bit time_t rollover 2038年1月19日3時14分7秒 ・unsigned 16bit MJD rollover ←B-CASとか 2038年4月22日 ・GPS week rollover (3回目) ←去年2回目 2038年11月21日 その前に昭和100年問題はどうすんだよ。 2038年問題なんて、64bitにして解決。 あと15年か >>1 から20年経ったけどそろそろ2038年問題は解決出来そうかな? read.cgi ver 08.0u [upliftProject] - 2023/07/09 Walang Kapalit ★ | uplift ★ 5ちゃんねる