パスワードを忘れた? アカウント作成
7426 story

2038年問題、早くも顕在化 104

ストーリー by GetSet
ヤバいと思った人、挙手 部門より

Fortune曰く、"ITProの記事によると、去る1月11日に23行の銀行ATMを襲ったトラブルの原因が2038年問題だったそうだ。今回の場合、ソフト内部に時刻を2倍に足し合わせる処理があり、EPOC-TIMEから2038年1月19日3時14分8秒までの2分の1を超えた2004年1月11日の朝から、この問題が顕在化し正常動作しなくなったようだ。2038年と言うとまだまだ先のように思えるが、思わぬところで顕在化したこの問題、みなさんの所では大丈夫?"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by nu-u (12312) on 2004年02月03日 12時15分 (#487069) 日記
    住宅ローンだったら30年ってのもあるでしょうし(^_^;)
    意外に近いかもしれませんねぇ(^_^;)>2038年問題

    # それくらいは対策打ってるか(;^-^)
    • Re:2038年と言っても (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2004年02月03日 15時05分 (#487225)
      35年ローンなので、
      オーバーフローして金利がマイナスにならないかとひそかに期待しております。

      でも、2038年を超えたところでリセットされて元にもどってしまったらやだな…。
      親コメント
  • ほかにも… (スコア:3, 興味深い)

    by takechi (10022) on 2004年02月03日 13時14分 (#487136) ホームページ
    これ [fujixerox.co.jp]も根っこは同じ?

    #今後いろいろ出てきそう…
  • こういうのを 2038 年問題の 1 つと言ってしまって良いのでしょうか? これは time_t 型の仕様限界による問題ではなくて、単に開発者が time_t 型の仕様を理解していなかっただけの話ですよね?

    --
    むらちより/あい/をこめて。
    • 開発者の理解不理解に関わらず、time_t型の範囲を超えた値を扱った事で生じた問題なら2038年問題としていいのでは?
      --
      ぽぇんぷしゅう。
      親コメント
      • by tada (5086) on 2004年02月03日 17時41分 (#487360)
        今回たまたま時間を2倍するプログラムがエラーを起こしただけで、
        3倍するプログラムはとっくの昔にエラーを起こしたはずです。
        それらを「2038年問題」と言ってしまうと、任意の時刻にそれを起こせることになってしまいます。
        それって何かおかしいような。
        親コメント
    • そうそう、単なるバグだよね。
      親コメント
      • by Anonymous Coward on 2004年02月03日 12時37分 (#487093)
        2038年問題を言い訳にしてバグではないとごまかした・・・
        っていう話題じゃないの・・・
        多分・・・
        親コメント
    • by Anonymous Coward on 2004年02月03日 13時12分 (#487134)
      単に開発者が time_t 型の仕様を理解していなかった

      好意的に推測しすぎ。time_t なんて使ってやしないでしょ。おそらく。
      int だと思っているから「2倍する」なんて操作をしているの。なんで2倍するのか知らないけど、時刻でなく何か別の用途に使う数値の元ネタにしているのかもね。それでも正の値でないとまずいとかさ。

      時刻を内部でどう扱っていても固定サイズで扱っていればいつかはあふれる。それが現実に運用期間中に来ることを考慮しなくて(想像すらできなくて)問題を発生させれば、それはバグ。
      西暦年を2桁で表せば2000年問題だし、 エポックからの秒数を9桁の文字列で表せば10億秒問題だし、 1970年1月1日のエポックからの秒数を32ビット符号つき整数で取り扱えば2038年問題。
      根は同じだけど、皆して同じバグを作っているからそれぞれ発症時期の名前がついている。
      だから、今回のは2004年1月問題かもしれないけど、2038年問題では断じてない。

      親コメント
    • by deleted user (18918) on 2004年02月03日 16時01分 (#487268) 日記
      問題が起きたATMってCで動いていたんですか?
      親コメント
    • by nofuture (17983) on 2004年02月04日 0時10分 (#487683)
      仕様が理解されていない方が
      ずっと大きな問題だと思う。
      予測不可能だからだ。
      2000年問題というのは
      そういう問題だったのではないのか。
      親コメント
  • by ncube2 (2864) on 2004年02月03日 13時11分 (#487133)
    2007年問題 [it-planning.jp]がもうスグだのう。
    • by simon (1336) on 2004年02月03日 16時52分 (#487309)
      ・・・・・・おまいら「200X年問題」って言いたいだけちゃうんかと。

      200X年問題(挙げたものは一例に過ぎません)

      ○2003年問題:東京で2003年に大量に完成するオフィスビルによる供給過剰問題。

      ○2004年問題:流通・外食産業で「消費税総額表示の義務化」「外形標準課税の導入」「パート労働者への厚生年金の適用拡大」
      による経営難問題。

      ○2004年問題:2000年問題で入れ替えたPOSシステムのリース期間の終了する2004年から一斉に入替を始める問題。

      ○2005年問題:都内で超高層、大型マンションが大量に完成。価格下落が起こる問題。(問題なのか?)

      ○2005年問題:EUが国際会計基準異移行するため、日本の会計基準が国際的に通用しなくなる問題

      ○2005年問題:日本の総人口がピーク(1億2,745万人)を迎える。前後して65歳以上の高齢者の全体に占める割合が
      世界一になる問題。

      ○2006年問題:新学習指導要領世代(円周率が3.14ではなくなった世代)が大学進学を迎え、大学生の学力低下が
      心配される問題。

      ○2006年問題:中国や中東のエチレンプラントが稼動し、日本企業は苦戦することになる問題。

      ○2006年問題:日本の人口がピークに。以後減少に転じることによるGDP減少問題。

      ○2007年問題:1947年前後に生まれた団塊の世代が一斉に定年退職を始め、労働人口の変化によるオフィスビル需要の
      減少問題、ノウハウの伝承問題、退職金問題などの様々な問題。

      ○2007年問題:名古屋駅前の豊田毎日ビル再開発、牛島再開発の完成年度の2007年に名古屋のオーバービルディング
      (供給過剰)が生ずる問題。

      ○2007年問題:東京の都心部でこれから2007年にかけ、新しい大型ホテルが相次いで開業する。全体の客室数が
      大幅に増えるため、ホテルが過当競争に陥る問題。

      ○2008年問題:国債大量償還問題。

      ○2009年問題:少子化で大学志願者数と受入者数が並び大学全入学時代を迎える問題。

      ○2010年問題:団塊世代の大量退職によってオフィス需要の激減が見込まれる問題。

      ○2011年問題:地上波アナログ放送の中止問題。
      (相互に矛盾してるのがあるのは僕のせいじゃないです。問題を提唱している人たちの間で調整が取れてないだけです)

      もうね、バカかと。アホかと。問題問題問題って、おまいは問題星人かっつーの。
      マンションが安くなるとかホテルの割引合戦なんて、200X年問題どころか没問題じゃねーか。バカ。

      「200X年問題」とか言ってる香具師はてきとーにラベルを貼れば自分が問題にしたい何かを問題に出来るとか
      思ってるバカですが、何か? 2000年問題が大々的に報道されたせいで「危機ブランドイメージ」がついたから、
      それに相乗りしてるだけだっつーのに、おまいら乗せられすぎです。

      香具師らは「何年後かに大々的な問題が迫ってる!」って言って危機感を煽る(そして自分たちが何がしかの利益を得る)
      けど、それを言うなら今までの人類史の中で「n年後に大々的な問題が迫っていなかった」時は無い、
      ってことを忘れてないか?

      香具師らの煽りに乗せられて「小手先の、集中的にお金が動く、**業者の望みどおりの、全然抜本的でない解決法」
      に飛びつく気ですか?
      「200X年問題」て言われてる問題はそもそも、普段の継続的で地味で地道な努力によってでしか解決できないんだからさ、
      「200X年問題!ヤバイ!スグスグ何とかしなきゃ!!」っていう思考停止→対症療法コンボじゃなくってさ、
      ちゃんと地に足をつけて考えようぜ?・・・な、頼むぜ社長?
      親コメント
    • 別に情報システムに限らず、多くの人が引退していってしまうわけですよね。なので情報システムだけ取上げて2007年問題と騒ぐ必要もないと思うのであります。 

      システム内部の仕掛けの伝承という問題も大きいけど、どうしてそういうシステムの設計になっているのかという考え方を決めた側(普通はユーザー側)の偉い人もいなくなっちゃうわけです。

      あ~面倒くさいから全部作り変えよう!って展開になれば、それはそれで楽しい地獄が待っているかも。 過去のしがらみも教訓も反省もない世界。
      --
      ---- 末は社長か懲戒免職 なかむらまさよし
      親コメント
  • で、 (スコア:1, 余計なもの)

    by Anonymous Coward on 2004年02月03日 12時17分 (#487072)
    何で2038年におかしなことになるの? 教えてエロい人。
    • Re:で、 (スコア:2, 興味深い)

      by tyuu (9154) on 2004年02月03日 13時10分 (#487132) ホームページ 日記
      #include
      #include

      /*
      動作確認。

      0x80000000 から、過去に飛ぶのがわかります。
      time_t が unsigned でない int だからです。
      # time.h を見ればわかるでしょう。

      unsigned が分からない場合 (unsigned) を
      削除して printf してみると良いでしょう。
      */

      int main(){
      time_t t=0; /* epoch */
      printf("0x%08x: %s", (unsigned)t, ctime(&t));
      t=0x40000000; /* 2^30 秒 */
      printf("0x%08x: %s", (unsigned)t, ctime(&t));
      t=time(NULL); /* today */
      printf("0x%08x: %s", (unsigned)t, ctime(&t));
      t=0x7fffffff; /* 32bit UNIX 最後の日 */
      printf("0x%08x: %s", (unsigned)t, ctime(&t));
      t=0x80000000; /* 1901-12-14(Sat) 05:45:52 */
      printf("0x%08x: %s", (unsigned)t, ctime(&t));
      t=0xffffffff; /* 1970-1-1(Thu) 08:59:59 */
      printf("0x%08x: %s", (unsigned)t, ctime(&t));

      return 0;
      }
      親コメント
  • 世界全体で合計どのくらいコストがかかるのかな。

    #ILP64な環境だとtime_tはどう定義されてるか興味津々
    • by Anonymous Coward on 2004年02月03日 13時16分 (#487140)
      > time_tをsigned __int64に変更するとしたら

      time_tそのものは32bitだと決まってるわけではないので
      変更の必要性はありません。

      ちゃんと作ってればソースへの変更は不要。
      もっとちゃんと作ってればリコンパイルも不要。
      数十年や数百年先、
      さらには同じような扱いで数十年前や数百年前の時刻を
      秒単位で管理するソフト作る場合は
      始めからtime_tを利用せず代替ライブラリーを自分で用意するし。

      結局のところ表現したい時刻の範囲と
      それぞれの型によって表現可能な時刻の範囲の問題に関して
      ちゃんと考えたことがあるのか、それともないのか
      という点につきますよ

      どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
      「何も考えてなかった」とか言い出す連中は
      設計の段階で何も検証してません。
      「最後のテストがちゃんと通ったんだからそれでいいじゃん」というような
      テスト至上主義がつくったソフトは
      環境の変化や想定外の状況に遭遇したとき
      「そうなって当り前だろ?」と笑われるようなものを平気で作ります。

      そういうおかしな物作りをするような職人のプライドもヘッタクレも
      無いようなところを無くすことができない以上、
      そんなところに発注するクライアントの責任が一番重大。
      クライアントは発注先とは独立してコンサル雇って
      設計段階で発注先の物の考え方を探っておきなさいってこった。
      今のIT業なんて外からみたらみんな同じに見えても
      中を開けるとプロ野球と少年野球くらいの違いがあるんだから
      その違いを無視して安いところを探してたらダメ。
      親コメント
    • その変更だけではだめだぜぇ~

      世の中にはたまたま動いてるだけっていうソフトがいっぱいあるわけだが、
      そんなソフトのtime_tを64bitsにしたら、アラインがずれて...
      # 煙り出すのにちょうどいい?
      親コメント
  • by poo (10689) on 2004年02月03日 20時51分 (#487531)
    intが何ビットでもいいように、C言語のAPIを追加したほうが
    いいと思うんですが、なぜしないんでしょうか?
    • C言語のAPIを追加
      って表現に激しく違和感を覚えるんですが・・・。
      #ただのあげあしとりだけどID
      --
      にゃにゃ(=-_-=)
      親コメント
    • by Joga (8113) on 2004年02月04日 0時08分 (#487679)
      > intが何ビットでもいいように、C言語のAPIを追加したほうが
      > いいと思うんですが、なぜしないんでしょうか?

      つか、C言語の仕様ではintは処理系依存(≒何ビットでもいい)はず。
      プログラム作ったやつがタコなだけ、って話だと思う。

      #って、そういう意味じゃない?
      親コメント
      • by oku (4610) on 2004年02月04日 1時47分 (#487748) 日記
        つか、C言語の仕様ではintは処理系依存(≒何ビットでもいい)はず。
        もちろん Joga 氏は知った上で書いていると思いますが、蛇足ながら念のため。

        一応、int は -32767~+32767 の範囲を表現できなければならない (実質的に最低 16bit 用意しろと言ってるのと同じ事) という制限があるにはあります。 しかし、C を使う立場としては、これだけでは何も決まっていないに等しい状態です。 これでは int は何バイト (or 何ビット) あると言う仮定を勝手にやらかす手抜きプログラマを一概に責めるわけにもいきますまい...ってことで C99 で stdint.h が導入されたのではないかと勝手に想像しているのですが、実は autoconf を使った方がよっぽど汎用になるので stdint.h 使ってません。

        stdint.h 便利に使ってるよって人います?

        親コメント
  • by Anonymous Coward on 2004年02月03日 12時03分 (#487057)
    する処理って想像できないんですけど、教えて!エロイ人!
  • by Anonymous Coward on 2004年02月03日 12時03分 (#487058)
    なんのための処理なのか気になる・・・
  • by Anonymous Coward on 2004年02月03日 12時08分 (#487060)
    奥歯をかみしめた。
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...