アカウント名:
パスワード:
サマータイムってのはそれなりに導入の蓋然性が高く既に諸外国に導入され経験が蓄積されてる。それでも想定外でサポートしていないのが当然だってのがシステム屋の意見らしい。ならどこまで想定しないのが許されるの? 参考までに聞きたい。
諸外国に蓄積された経験を日本のシステム屋が持ち合わせていると思っているのかい?日本は国内でのタイムゾーンが統一されていることもあり、時刻データの記録とその出力にタイムゾーンの情報を持つ必要がなかった場合が多く、ローカルタイムの記録にタイムゾーンの情報を持ち合わせていないシステムも数多い。同国内に複数のタイムゾーンが混在する米国の開発事情と同じには語れない。許されようが許されなかろうが、障害は起こる。切り替えのタイミングで深夜バッチが二重に実行されたり、あるいは実行されなかったりで、日本中パニックになるのが目に見えている。時刻に依存するロジックをほとんど全て見直しテストする必要があり、かつての2000年問題どころの騒ぎではない。
JST/JDT の切り替えに対応するからその分開発費上乗せしますって言って、使いもしない機能に首を縦に振る客がいると思うか?なんならあんたが顧客のところへ行って説明して OK 出してもらえ。話はそれからだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
どこまで想定しなくても許されるの? (スコア:0)
サマータイムってのはそれなりに導入の蓋然性が高く既に諸外国に導入され経験が蓄積されてる。
それでも想定外でサポートしていないのが当然だってのがシステム屋の意見らしい。
ならどこまで想定しないのが許されるの? 参考までに聞きたい。
Re:どこまで想定しなくても許されるの? (スコア:1)
諸外国に蓄積された経験を日本のシステム屋が持ち合わせていると思っているのかい?
日本は国内でのタイムゾーンが統一されていることもあり、時刻データの記録とその出力にタイムゾーンの情報を持つ必要がなかった場合が多く、ローカルタイムの記録にタイムゾーンの情報を持ち合わせていないシステムも数多い。
同国内に複数のタイムゾーンが混在する米国の開発事情と同じには語れない。
許されようが許されなかろうが、障害は起こる。
切り替えのタイミングで深夜バッチが二重に実行されたり、あるいは実行されなかったりで、日本中パニックになるのが目に見えている。
時刻に依存するロジックをほとんど全て見直しテストする必要があり、かつての2000年問題どころの騒ぎではない。
Re: (スコア:0)
JST/JDT の切り替えに対応するからその分開発費上乗せします
って言って、使いもしない機能に首を縦に振る客がいると思うか?
なんならあんたが顧客のところへ行って説明して OK 出してもらえ。話はそれからだ。