アカウント名:
パスワード:
日本時間3月2日9:00以降は無事PSNに接続に成功できるようになりました。ただ、日付表示が昨日は2000/1/1だったのが2010/3/1に変わってるんですよね。(3/2ではなく)
実際の日時 PS3内部の日付2010/2/28 2010/2/282010/3/ 1 2000/1/ 12010/3/ 2 2010/3/ 1(実際はどれも GMT+9なので午前九時以降の話ですが)
なにかパッチがDLされた気配もないし、本当に内部の時計のバグだけだったのでは?という疑いがより濃くなりました。ちなみにトロフィーデータやセーブデータは無事でした。(ただ、昨日オフラインでトロフィー実績を解除しちゃった人は齟齬が起きてるのかも?)
違うでしょ。こういう状態。俺のPS3もこんなだった。起動するだけで時計はいじってない状態。(時差めんどくさいのでGMTと思ってちょうだい)
現実 RTC 表示2010/02/28 2010/02/28 2010/02/282010/03/01 2010/02/29 2000/01/01 ←RTCがあり得ない日付を返してくるのでフォールバック2010/03/02 2010/03/01 2010/03/01 ←RTCが1日ずれてるのでそのまま
こういうシステムを触ったことがない人間なのですが、どうして閏年を「計算」するんですかね。100年分くらいのカレンダー持たせて、その日付があるかどうかだけ確認すれば済むと思うんですけど。何か理由があるのでしょうか?
> 100年分くらいのカレンダー持たせて、その日付があるかどうかだけ確認すれば済む
2099年までの動作保証でよければ、「4で割り切れる」だけでOKですよ。テーブル持つより簡単
#まさか2100年にまでコードが使われ続けることはないだろうとタカをくくってるのでAC。
> テーブル持つより簡単
バグったら意味ないじゃん。
ACじゃないしね
テーブルのデータ間違ってたらどうする?
2009年までの動作保証でよければ、「2で割り切れる」だけでOKですよ。テーブル持つより簡単
#まさか2010年にまでコードが使われ続けることはないだろうとタカをくくってるのでAC。
などと初期型開発者が考えていたのではないか?
どのみち計算式が間違っていたら、そのテーブルも間違ったテーブルになってしまっているのでは?
ビットで数えると年がばれるよ。
計算を間違える人がいればカレンダーを作り間違える人もいるわけで、リスク回避にはなりません。カレンダーではありませんが表の作成ミスでCPUが計算を間違える [wikipedia.org]なんて事件もありました。
100年分固定値のカレンダー作ったら、(2月かどうか関係なく)100年分を1日単位で確認するテストが発生するよ。
だって、そのカレンダーってどうやって作ったの?と聞かれたらどうします?
時刻関連の一次ソースは、一次元のタイムスタンプです。1970年1月1日からの経過秒数(精度はナノ秒)という感じで取れます。これをカレンダーに対応させるテーブルで持てってことは、 0.0e+0 → 1970-01-01 00:00:00.000000000 1.0e-9 → 1970-01-01 00:00:00.000000001という感じで持つということですかね。ちょっとありえないでしょう。
>100年分くらいのカレンダー持たせて、その日付があるかどうかだけ確認すれば済むと思うんですけど。その"その日付"ってのはどうやって持ってくるんですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
もう直ってるって (スコア:0)
ちなみに障害期間はUTCの3/1 0:00 - 3/2 0:00っていう、いかにもな閏年バグですね。
#2006年11月11日の発売以来最初の発現なので、2年に1度閏年が来る仕様なんじゃないかな。次回は4年後か。
Re:もう直ってるって (スコア:3, 興味深い)
日本時間3月2日9:00以降は無事PSNに接続に成功できるようになりました。
ただ、日付表示が昨日は2000/1/1だったのが2010/3/1に変わってるんですよね。(3/2ではなく)
実際の日時 PS3内部の日付
2010/2/28 2010/2/28
2010/3/ 1 2000/1/ 1
2010/3/ 2 2010/3/ 1
(実際はどれも GMT+9なので午前九時以降の話ですが)
なにかパッチがDLされた気配もないし、本当に内部の時計のバグだけだったのでは?
という疑いがより濃くなりました。
ちなみにトロフィーデータやセーブデータは無事でした。
(ただ、昨日オフラインでトロフィー実績を解除しちゃった人は齟齬が起きてるのかも?)
Re:もう直ってるって (スコア:3, 参考になる)
違うでしょ。こういう状態。俺のPS3もこんなだった。起動するだけで時計はいじってない状態。(時差めんどくさいのでGMTと思ってちょうだい)
現実 RTC 表示
2010/02/28 2010/02/28 2010/02/28
2010/03/01 2010/02/29 2000/01/01 ←RTCがあり得ない日付を返してくるのでフォールバック
2010/03/02 2010/03/01 2010/03/01 ←RTCが1日ずれてるのでそのまま
Re: (スコア:0)
こういうシステムを触ったことがない人間なのですが、どうして閏年を「計算」するんですかね。
100年分くらいのカレンダー持たせて、その日付があるかどうかだけ確認すれば済むと思うんですけど。
何か理由があるのでしょうか?
Re:もう直ってるって (スコア:1)
> 100年分くらいのカレンダー持たせて、その日付があるかどうかだけ確認すれば済む
2099年までの動作保証でよければ、「4で割り切れる」だけでOKですよ。
テーブル持つより簡単
#まさか2100年にまでコードが使われ続けることはないだろうとタカをくくってるのでAC。
Re: (スコア:0)
> テーブル持つより簡単
バグったら意味ないじゃん。
Re: (スコア:0)
ACじゃないしね
Re: (スコア:0)
テーブルのデータ間違ってたらどうする?
Re: (スコア:0)
PS3は2006年11月発売 (スコア:0)
2009年までの動作保証でよければ、「2で割り切れる」だけでOKですよ。
テーブル持つより簡単
#まさか2010年にまでコードが使われ続けることはないだろうとタカをくくってるのでAC。
などと初期型開発者が考えていたのではないか?
Re:もう直ってるって (スコア:1)
どのみち計算式が間違っていたら、そのテーブルも間違ったテーブルになってしまっているのでは?
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
ビットで数えると年がばれるよ。
Re: (スコア:0)
計算を間違える人がいればカレンダーを作り間違える人もいるわけで、リスク回避にはなりません。
カレンダーではありませんが表の作成ミスでCPUが計算を間違える [wikipedia.org]なんて事件もありました。
Re: (スコア:0)
100年分固定値のカレンダー作ったら、(2月かどうか関係なく)
100年分を1日単位で確認するテストが発生するよ。
だって、そのカレンダーってどうやって作ったの?と聞かれたらどうします?
Re: (スコア:0)
時刻関連の一次ソースは、一次元のタイムスタンプです。
1970年1月1日からの経過秒数(精度はナノ秒)という感じで取れます。
これをカレンダーに対応させるテーブルで持てってことは、
0.0e+0 → 1970-01-01 00:00:00.000000000
1.0e-9 → 1970-01-01 00:00:00.000000001
という感じで持つということですかね。
ちょっとありえないでしょう。
Re: (スコア:0)
>100年分くらいのカレンダー持たせて、その日付があるかどうかだけ確認すれば済むと思うんですけど。
その"その日付"ってのはどうやって持ってくるんですか?