閏年の処理バグで、旧型のPS3が起動しないとか、データが壊れるとか大変だったようです。
2010年って、4でも割り切れない年になんで閏年の処理に失敗してるんだか…。
閏年は、西暦で、4で割り切れる年。(でも、100で割り切れる年は閏年じゃないけど、400で割り切れる年は閏年)。2000年は、この400で割り切れる年だったんでちょっと注目してた。むしろ、2100年の方がしょっぱいプログラムの影響でミスが出るんじゃ無かろうか。俺、もう生きてないけど。
まぁ、PS3なんて週に1回起動するかしないかの私には、まったく影響がありませんでした。
なんかついこの前mixiで書いたような気がするけど、現在の閏年の定義ちゃんとわかってる人いるんだろうか？2000年はレア年なんだよね。
20年くらい前ホスト系やってた頃、COBOLでちゃんと書いてたなぁどれだけ意味あるんだろうと疑問に思いながらですが、そういう部分が後々響くのよね。
2100年あたりだとノイマン型でなかったりするのかなぁ？
▼ちょろさん
4で割る、100で割る、400で割るを覚えておけば、数万年に1日の誤差なんで、簡単には調整日入らないはず。
2000年は、言うとおり特異日なんですが、結果4で割り切れてるからOK的な面で救われたシステムは多いはず…。
あと90年後のPCがどうなっているか。
でも、こういう根っこは案外一緒だったりしてね。ケアレスミスで大混乱(笑)
うるう年の設定にしたって、このタイミングで発生する意味が不明。仮に暦の数値設定が「09/02/28」ではくて「9/2/28」だとすると、下手すると「0/2/28」でループする…無理があるなあ。（笑）
特に意識しないで、後で修正パッチを配信すればいいか、なんて安易に考えていたんですかね？
もし、知っていて蔑ろにしていたとしたら、究極の「ソニータイマー」なんて思ったり。（爆）
▼million_cottonさん
1980年からのシリアル値で計算してて、どっかでリセット失敗とかだとともいます。
(ハードウェアか基礎ライブラリのバグ。ソニーもビックリ。ばびょーん！だと思います)
今回は、ネットワークにログイン出来ないので、パッチが当てられないというジレンマに陥った可能性が高いですね。
▼omoteさん
ああ、そう言うのありましたね〜。あまり生活に役に立った覚えがありませんが(笑)
間違えててもネットワークに繋がるようにしておいて、後はNTPで。
ってのはダメ？
▼ちゃがまさん
PS3の場合、スタンドアロンも多いでしょうし、時計巻き戻しによる不正を行わないようにする意味で、ユーザーの触れない時計が存在するのもしょうがない気がしますねぇ
NTPに依存しすぎると、またパンデミックが…
＞million_cottonさん
それってなんてハルヒ的エンドレス28？
unixなのはググったら2038年だったか・・・
なんかライブラリで変なキャストしたとか、むしろ古いので起こるならCELLのエラッタだったりして・・・
▼ちょろさん
いや、携帯プレイヤーでも同様の事象が報告されているので、もっと部品単位のエラーだと思いますよ。
RTCまわりなんて、通常書き換え可能なファームウエアよりも下の層でしょうからねぇ。
部品交換とか、専用の機材を使わなければならない書き換え(メーカー返送)は行わず、RTCの値が酷かったらRTCよりもNTPを優先(もしくはユーザー時計)するというようなファームでの対処になると思いますが…。
閏年チェック。ユリウス暦のものは少し違うみたいですね。
「4で割り切れる。100で割り切れる年はダメ。しかし、900で割った余りが200か600になる年」
ま、どっちにしても後ろの条件は、我々が生きてる間は来ませんな。