【韓国】年度変わりで携帯電話の不具合が続発…サムスン、LG、パンテック製など「2010年」のメールなどに不具合 [01/04]
どういうプログラミングしたら不具合出るんだ?
time関数使ってたら、2010年1月1日0時0分0秒は1230768000秒だから、32bitあふれとかそんなんじゃないし、
やっぱり
>>6の通り、下一桁取って演算してるんじゃないかな?
多分、こんな式があるはず。
year_str = sprintf("200%d",(int)substr(year,-1));
>>42 いや、それは多分、文字列を16進数化して計算してるんだろ。
10進数で10は10出しかないが、16進数で10は16にあたる。
>>61 でもな、十数年先まで使われないからそれ以上は考慮する必要は無いとも言われるんだぜw
現実にはかなり長い年月使われるけど orz
67 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/04(月) 20:06:22 ID:Ecv3Mkbi
日付やカウンターは自分が100まで生きていることを想定して設計している
自分が通ります(後は知らん)
68 :
369:2010/01/04(月) 20:08:26 ID:DueIu7OK
隊長、金がないです。しかしこの問題は世界の問題です。
69 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/04(月) 20:10:45 ID:7C8AJ/VE
日本もこの問題は発生している
70 :
( ̄^ ̄*ゞ ZZR400(酉変更) ◆8MustanGi6 :2010/01/04(月) 20:13:54 ID:TTCVuBph
>>40 (1.)です、当時(友人達)システムエンジニア達やサポート要員はビクビクしながら年末年始に会社で徹夜待機させられてました。
曰く「絶対に新年の電話をかけてくるな(怒)」
>>42 つぎつぎ新しいハードとソフトを投入していってるのは主要各国の余裕のあるところばっかりです。
メインフレームなどハードを新しくしても末端端末との兼ね合いで資金に余裕の無い他国では、
UNIX ベースでソフト互換ならソフトはそのままだったり・・・
>>69 携帯では発生してない様子だぞ。
これは3キャリア+αのホームページ上を確認したが、不具合情報は載ってない。
一体、何がこの不具合起こしたんだ?
72 :
369:2010/01/04(月) 20:14:59 ID:DueIu7OK
3人のユダヤ王に忠誠を誓います。
>>66 でも、RFCではすでに10000年問題が論議されてるw
しかし、直近の問題は2038年問題だな。
対応するにはリコンパイルが最低でも必要だから、今のうちに何とかしないと結構大変なことになるかもしれない。
今さっき「2038年以降の値は想定しない」って書かれた新ライブラリ仕様案が回ってきて吹いた
>>74 それはCかなんか?
PHP、PerlとかJava、C#なら後から対応可能だから別にそんなことを書かなくてもいい気がするが。
>>56 2000年のときは容量の問題もあったから
しょうがないかもとは思ったな。
>>63 うわー賢いー!!
そういえば内部を和暦で持ってるプログラムがあって、
平成対応はX以上を平成ってやってるのがあったな。
昭和100年になる前に廃棄されてるんだろーかー(棒
>> 68
サムスンやLGの携帯が世界中で売れてるそうだから、韓国は莫大な賠償求められそうだね。w
>>74 その時確実に自分が関わらないで済む自信があれば、それもいいだろう。
>>78 「無料で新製品に交換します!」じゃね?
80 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/04(月) 21:25:32 ID:m3qJu3C1
>>77 数値が64までが昭和だから、100-64で、平成34年までカウントできるのか?
…あと12年…現役で使われていそう
>>80 今度の陛下は既にご高齢だから、と不敬罪な議論が。
ぶわはああ
83 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/04(月) 22:15:14 ID:hFzlf2vG
オモニアwww
まあ、今回は見逃すとして、
次は2016年か17年にやらかすってことか?
たぶんこれから毎年起きると予想。
うるう年の2/29にもなると予想。
86 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/04(月) 22:38:16 ID:m3qJu3C1
>>84 内部16進数で表示10進数なら(上のレスであったがBCD表記)、そうはならないと思う。
どっちかってーと2020年になった時、2032年と表示されるバグが再発?するかもしれない。
>>86 おお、ありがとー
どちらにしろ、そんな長期に使われるとは考えてないんすね♪
バカチョンカメラじゃなくてバカチョンケータイだな
>>1 で、配布のパッチがマトモに機能するのかが激しく疑問なのだがw
90 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/04(月) 23:11:54 ID:Pa2fnBMd
2000年問題や2001年問題だけじゃなく、2010年でも問題起こすか韓国w
いっそ、2011年問題や2012年問題と、毎年問題出してくれよw
>>91 掃除のおばちゃんがコンセントに足引っ掛けました
昔、2000年問題とその対策を啓蒙しているサイトの掲示板で、
2000年になったら投稿日付の年が19100年になって大笑いしたのを思い出した。
仕様ニダー
2000年問題から10年経つのか。
10年前はHP-UXのお守りしてたっけな。
VUEとかSAMとか懐かしい。
どのくらい売れてるの
97 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/05(火) 00:05:35 ID:0jaSTpD6
いまごろ2000年問題かw
さすがIt大国wwww
そういや21世紀は顧客先で迎えたっけ。
今日、親に使いやすい携帯を買ったんだが
京セラに比べてパンテックとか言う携帯が安かったので
一旦これに決めた
が機種変作業中にチョンに一銭でも払いたくないし
少しでも日本経済のためだと思い京セラに変えて貰った
+20000円もよけいに払ったが帰りはすがすがしい気分だった
ネットでこの機種の価格調査をするまではorz
>>74のは組み込みとかの話じゃないかな
昔のUNIX系の日付時刻管理は32ビットでやってて2038年だかに上限値に達するという奴
そおいや昔の会社で「日時処理すると、たまに前日日付になるんですぅ」というのがあった
調べてみると日付処理が世界標準時
そりゃ午前9時以前に実行すりゃ前日日付になるわさ
書き換え面倒なんで「9時以降に実行するよう文書化してください」にしたw
マ板の出張スレはここでつか?
どこかに○○年問題のまとめがあった希ガス。
そういえばMS-Accessもそういうもんだい抱えてたな。
101 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/05(火) 13:40:17 ID:jKmXxtaz
2000年問題であれだけ騒いでたのに
10年先のことも想定してないとは
さすがとしか言いようがないなw
バカチョンケータイ
年号一桁で処理か。
設計の段階で気がつけよ
個人的には年号は全部四桁で処理させてくれといつも言うんだがなぁ
確かに携帯の買い替えサイクルって短いけどさ
コレはないだろ・・・
105 :
<丶`∀´>(´・ω・`)(`ハ´ )さん:2010/01/05(火) 15:03:51 ID:MB9y3eAB
2000年問題って懐かしいがかなり真剣に取り組んでいた記憶がある
現在の韓国のトップメーカーが基本的な年の部分に配慮し忘れたのか
まぁ携帯のOS開発が2000年以降だからといって一桁処理はないだろう・・・
2000年問題というのが何だったのか、韓国の技術者が全く理解してない証拠だよな
つか、あの時韓国人って、サーバには触れなかったの?
2000年問題でも世界で最大の問題が起きたのは韓国だったな……w
そもそもヒトケタだけ見る理由がわからん
なるほど10年後がいつまでたっても来ないわけだ
10年ごとに危機到来
なるほどIT強国
うちでもおきたぞー
2桁の年情報に30を足して、結果をそのまんま16進として
アスキーコードと解釈したものを、ラベルプリンターに送ってた糞仕様。
去年 09→30を加えて39→なぜか16進でのアスキーコードとして9を出力
今年 10→30を加えて40→上同様に16進で40なので@を出力。
2006年に作ったのに、このざま。なんで3年しか使えないんだよwww
>113
いや、なぜかそこだけ別外注だったから。
なんか出力が8桁までの古いラベルプリンターで
年月日を全部入れるとシリアル番号が2桁しか使えなくなるからって理由で
一番上の年の桁を一つだけにしたらしい。
月表示を1~9ABCにすれば良かったのに。