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年と言うとまだまだ先のように思えるが、思わぬところで顕在化したこの問題、みなさんの所では大丈夫?"
2038年と言っても (スコア:3, 興味深い)
意外に近いかもしれませんねぇ(^_^;)>2038年問題
# それくらいは対策打ってるか(;^-^)
Re:2038年と言っても (スコア:1, おもしろおかしい)
オーバーフローして金利がマイナスにならないかとひそかに期待しております。
でも、2038年を超えたところでリセットされて元にもどってしまったらやだな…。
ほかにも… (スコア:3, 興味深い)
#今後いろいろ出てきそう…
Re:ほかにも… (スコア:1)
2038 年問題? (スコア:2, すばらしい洞察)
こういうのを 2038 年問題の 1 つと言ってしまって良いのでしょうか? これは time_t 型の仕様限界による問題ではなくて、単に開発者が time_t 型の仕様を理解していなかっただけの話ですよね?
むらちより/あい/をこめて。
Re:2038 年問題? (スコア:1)
Re:2038 年問題? (スコア:1)
3倍するプログラムはとっくの昔にエラーを起こしたはずです。
それらを「2038年問題」と言ってしまうと、任意の時刻にそれを起こせることになってしまいます。
それって何かおかしいような。
Re:2038 年問題? (スコア:1)
Re:2038 年問題? (スコア:1, 興味深い)
っていう話題じゃないの・・・
多分・・・
Re:2038 年問題? (スコア:1, 興味深い)
好意的に推測しすぎ。time_t なんて使ってやしないでしょ。おそらく。
int だと思っているから「2倍する」なんて操作をしているの。なんで2倍するのか知らないけど、時刻でなく何か別の用途に使う数値の元ネタにしているのかもね。それでも正の値でないとまずいとかさ。
時刻を内部でどう扱っていても固定サイズで扱っていればいつかはあふれる。それが現実に運用期間中に来ることを考慮しなくて(想像すらできなくて)問題を発生させれば、それはバグ。
西暦年を2桁で表せば2000年問題だし、 エポックからの秒数を9桁の文字列で表せば10億秒問題だし、 1970年1月1日のエポックからの秒数を32ビット符号つき整数で取り扱えば2038年問題。
根は同じだけど、皆して同じバグを作っているからそれぞれ発症時期の名前がついている。
だから、今回のは2004年1月問題かもしれないけど、2038年問題では断じてない。
Re:2038 年問題? (スコア:1)
Re:2038 年問題? (スコア:1)
Re:2038 年問題? (スコア:1)
ずっと大きな問題だと思う。
予測不可能だからだ。
2000年問題というのは
そういう問題だったのではないのか。
Re:2038 年問題? (スコア:1)
1文字だけキーボードから文字を得るものがあったとして、
バッファを1byte分しか用意していないのに全角文字を入力されたら
「2byte問題」と呼べるような気もします。
「uchar問題」も、ucharで桁あふれすることはまずありえないとの確信があり、
ucharを使うことに何か意味があるなら、問題と呼んでもいいのでは?
1を聞いて0を知れ!
2038年問題の前に (スコア:2, 興味深い)
問題星人あらわるあらわる (スコア:4, 興味深い)
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年問題!ヤバイ!スグスグ何とかしなきゃ!!」っていう思考停止→対症療法コンボじゃなくってさ、
ちゃんと地に足をつけて考えようぜ?・・・な、頼むぜ社長?
Re:問題星人あらわるあらわる (スコア:2, おもしろおかしい)
Re:問題星人あらわるあらわる (スコア:1)
>○2005年問題:都内で超高層、大型マンションが大量に完成。価格下落が起こる問題。(問題なのか?)
しかし、こういうのはノってもいいのでは?
というよりは、自分に得するようなもの以外は特に気にしないでしょう。
#2005年にマンション買う予定なのでID
Re:問題星人あらわるあらわる (スコア:1)
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:問題星人あらわるあらわる (スコア:1)
最近のは、規模が小さいと言うか、そそらないですね。
えっ、あれとは違う?
Re:問題星人あらわるあらわる (スコア:1, おもしろおかしい)
Re:問題星人あらわるあらわる (スコア:1)
Re:2038年問題の前に (スコア:1)
システム内部の仕掛けの伝承という問題も大きいけど、どうしてそういうシステムの設計になっているのかという考え方を決めた側(普通はユーザー側)の偉い人もいなくなっちゃうわけです。
あ~面倒くさいから全部作り変えよう!って展開になれば、それはそれで楽しい地獄が待っているかも。 過去のしがらみも教訓も反省もない世界。
---- 末は社長か懲戒免職 なかむらまさよし
で、 (スコア:1, 余計なもの)
Re:で、 (スコア:2, 興味深い)
#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;
}
Re:で、 (スコア:1)
stdio.h と time.h です。
#include
#include
by tyuu.
Re:で、 (スコア:1)
前にタグを書こうとしたとき、仕方なく全角で書いたけど、本家の人たちはどうしてるのかな?
1を聞いて0を知れ!
Re:で、 (スコア:1)
うげっ!失敗した。今度こそ[コード]形式を選んでポチッとな…
プレビューを見る限り確実にアングルブラケットが温存されている。
これでもダメならスラドのバグか仕様かな。
# 30分の投稿制限に引っ掛かったのでID
time_tをsigned __int64に変更するとしたら (スコア:1)
#ILP64な環境だとtime_tはどう定義されてるか興味津々
Re:time_tをsigned __int64に変更するとしたら (スコア:2, すばらしい洞察)
time_tそのものは32bitだと決まってるわけではないので
変更の必要性はありません。
ちゃんと作ってればソースへの変更は不要。
もっとちゃんと作ってればリコンパイルも不要。
数十年や数百年先、
さらには同じような扱いで数十年前や数百年前の時刻を
秒単位で管理するソフト作る場合は
始めからtime_tを利用せず代替ライブラリーを自分で用意するし。
結局のところ表現したい時刻の範囲と
それぞれの型によって表現可能な時刻の範囲の問題に関して
ちゃんと考えたことがあるのか、それともないのか
という点につきますよ
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
「何も考えてなかった」とか言い出す連中は
設計の段階で何も検証してません。
「最後のテストがちゃんと通ったんだからそれでいいじゃん」というような
テスト至上主義がつくったソフトは
環境の変化や想定外の状況に遭遇したとき
「そうなって当り前だろ?」と笑われるようなものを平気で作ります。
そういうおかしな物作りをするような職人のプライドもヘッタクレも
無いようなところを無くすことができない以上、
そんなところに発注するクライアントの責任が一番重大。
クライアントは発注先とは独立してコンサル雇って
設計段階で発注先の物の考え方を探っておきなさいってこった。
今のIT業なんて外からみたらみんな同じに見えても
中を開けるとプロ野球と少年野球くらいの違いがあるんだから
その違いを無視して安いところを探してたらダメ。
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
glibc 2.3.2 には long int と書いてありました。
# generic に書いてあるのに誰も override してないっぽい
行員矢の如し (スコア:1)
以降、time_tの説明には とでも書いておけば宜しい。
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
これはちょっと違うのでは?
仕様として決まっている事は全部テストでチェックすればいいだけだし。
仕様定義やテストの漏れこそが致命的であって、その部分のチェック
の方が重要だと思う。
ソースレベルのチェックなんてコーディング規約ぐらいのもんだろうから
その辺はプログラマレベルで解決して欲しい。
間違っても上位設計者にそんなことやらせちゃ駄目です。
建築士が柱を運ぶようなもんで、職掌(や単価)が違うんだから。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:time_tをsigned __int64に変更するとしたら (スコア:2, すばらしい洞察)
世の中にはたまたま動いてるだけっていうソフトがいっぱいあるわけだが、
そんなソフトのtime_tを64bitsにしたら、アラインがずれて...
# 煙り出すのにちょうどいい?
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
おっと旦那、int == signed __int64にしたらtime_t以外のところで不具合が山ほど出て被害が拡大しますぜ。
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
# 僕わかんないや。
## 64bitsにすると仮定しているのはtime_tだし。
てゆうか (スコア:1)
いいと思うんですが、なぜしないんでしょうか?
Re:てゆうか (スコア:1)
#ただのあげあしとりだけどID
Re:てゆうか (スコア:1)
> いいと思うんですが、なぜしないんでしょうか?
つか、C言語の仕様ではintは処理系依存(≒何ビットでもいい)はず。
プログラム作ったやつがタコなだけ、って話だと思う。
#って、そういう意味じゃない?
Re:てゆうか (スコア:1)
一応、int は -32767~+32767 の範囲を表現できなければならない (実質的に最低 16bit 用意しろと言ってるのと同じ事) という制限があるにはあります。 しかし、C を使う立場としては、これだけでは何も決まっていないに等しい状態です。 これでは int は何バイト (or 何ビット) あると言う仮定を勝手にやらかす手抜きプログラマを一概に責めるわけにもいきますまい...ってことで C99 で stdint.h が導入されたのではないかと勝手に想像しているのですが、実は autoconf を使った方がよっぽど汎用になるので stdint.h 使ってません。
stdint.h 便利に使ってるよって人います?
まとめてお返事 (スコア:1)
>軒並動かなくなって、さらにひどい事になると。
いやintをいじるんじゃなくて、time_tを使わなくてもよいような
C言語の標準関数を追加するってことです。
昔かかれたのは、仕方ないとして今から書くコードはそっちを使おうって事で。
>既になされているんですが、あっちこっちで独自拡張
>なんで、対応する方も大変なんですよん。
>ソースが#ifdefの嵐。
そういう意味でも、C言語の標準関数でそれぐらいやったほうがいいのではないかと
>C言語のAPIを追加 って表現に激しく違和感を覚えるんです
>が・・・。
すいません、C言語は授業や研修でしか使ってないもんで、
ついJavaのくせが。C言語の標準関数でいいんでしたっけ?
>つか、C言語の仕様ではintは処理系依存(≒何ビットでもいい)はず。
>プログラム作ったやつがタコなだけ、って話だと思う。
C言語の標準関数使ってるかぎり、time_t使わないと現在時刻取得できないので、
プログラム作ったやつがタコなだけではないと思うんですが。
ここ [nifty.ne.jp]にも
ってかいてありますし。
時刻を二倍 (スコア:0)
2倍にする処理って? (スコア:0)
Re:2倍にする処理って? (スコア:2, おもしろおかしい)
Re:2倍にする処理って? (スコア:2, おもしろおかしい)
Re:2倍にする処理って? (スコア:1)
マイクロソフト サポート技術情報 - 402160 [NT]NTFSからFATへのファイルのコピー時に日時が変わる [microsoft.com]
FDやDOS/Win3.1以下の端末、あるいはVisual C++あたりが絡んできたときに使うのでしょうが、ビットを落とすのではなくて足して2で割ちゃったのね。ありがち。Re:2倍にする処理って? (スコア:2, 参考になる)
Windowsの時間型であるFILETIMEは符号付64bit値ですが。
ちなみにDOS形式の日付形式への変換にはFileTimeToDosDateTimeというAPIがありますし、DOS形式の日付形式はEPOC値ではありませんが。
ついでに、
らしいですが。
↑009が (スコア:0)
↓009が (スコア:1)
#新しいコメント順に表示するようにしているのでID
−・・ ・ ・ −・−・ ・・・・ −−−
手垢で汚れた少年漫画とソースの香りがいい感じ
Re:↑009が (スコア:1)
奥歯をかみしめても何にもならないですよ. あれは奥歯の横のスイッチを舌で押しているんですから.