アカウント名:
パスワード:
今回はサマータイムは想定外という言い訳は通ったが次回は通らん。そもそもコンピューターや電子システムというのは手作業より効率的だから用いられている筈なのに、手作業で普通にできる事ができないってのはどういう事なんだか。
だっておめえ、サマータイムに対応したシステムと対応してないシステムなら後者のほうが安くなるのは道理だろ。余計な機能作る手間もテストする手間も省けるんだから。
なのに「将来的にあるかもしれないサマータイムに対応した機能をつけました。値段はついてないシステムよりちょっと高いです」ってのを選ぶ顧客はいねえよ。
「やらなくていいことをやって価格を上げる」くらいならそのカネはもっとデザインに凝るとか高速化を進めるとかそっちのほうに注力したほうがみんな幸せになるんじゃないの？不毛だからもうサマータイムはやめよう。むしろサマータイム禁止法を作るか、日本の標準時を明石に固定する憲法改正をしようぜ。
システム＝単一のアプリケーションを想定していますか？それならたいして問題ないですよ。
問題は企業で使用されている、夜間バッチなどが存在するシステムです。時間が、2時間分が消えたり2時間分が重複したりするんです。２２：００～０２：００に動くように指定されたプログラムが起動されなかったり2回起動される可能性があります。
確実なのはサマータイムが開始される人終了される日の経済活動を停止することかな。（銀行振り込み、ATMの引き出しも含む）
道理じゃない
OSの時間管理システムはサマータイムをサポートしたタイムゾーン機能を提供しているのだから、それをそのまま使って実装してテストしたシステムの方が、サマータイムのない独自の時間管理機能を実装してテストするより安くなる
「あえてサマータイムをサポートしない」という決定こそが「やらなくていいことをやって価格を上げる」行為の第一歩だよ
でも実際サマータイム対応するとチェック項目は増えるよね？しなくていいことをして作業量増やすのは不毛だよ
JSTだけを想定する場合、タイムゾーンが切り替わるケースのテストはしなくていい。
そのソフトウェアを(サマータイムを導入している)諸外国で使うことを想定すると、どのみちサマータイムのテストは必要だと思われます。
国内でしか使わないシステムの場合は無駄だな
時間管理システムはOSそのままだし、もし日本がサマータイム対応することになってもシステム自体は対応できるんだよ。問題は、読み取った表示データを他のことに利用する人間およびサマータイムに対応していない日時で登録する人間の方。入力した日時がサマータイム適用後に見かけ上違う日時になっていたりとか。
世の中にはOSすら載っていない機器だってごまんとあることをご理解ください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
次は言い訳は許されない (スコア:-1)
今回はサマータイムは想定外という言い訳は通ったが次回は通らん。
そもそもコンピューターや電子システムというのは手作業より効率的だから用いられている筈なのに、手作業で普通にできる事ができないってのはどういう事なんだか。
Re:次は言い訳は許されない (スコア:4, 参考になる)
今回はサマータイムは想定外という言い訳は通ったが次回は通らん。
そもそもコンピューターや電子システムというのは手作業より効率的だから用いられている筈なのに、手作業で普通にできる事ができないってのはどういう事なんだか。
だっておめえ、サマータイムに対応したシステムと対応してないシステムなら後者のほうが安くなるのは道理だろ。余計な機能作る手間もテストする手間も省けるんだから。
なのに「将来的にあるかもしれないサマータイムに対応した機能をつけました。値段はついてないシステムよりちょっと高いです」ってのを選ぶ顧客はいねえよ。
「やらなくていいことをやって価格を上げる」くらいならそのカネはもっとデザインに凝るとか高速化を進めるとかそっちのほうに注力したほうがみんな幸せになるんじゃないの？不毛だからもうサマータイムはやめよう。むしろサマータイム禁止法を作るか、日本の標準時を明石に固定する憲法改正をしようぜ。
Re: (スコア:0)
OSの時間管理システムはサマータイムをサポートしたタイムゾーン機能を提供しているのだから、それをそのまま使って実装してテストしたシステムの方が、サマータイムのない独自の時間管理機能を実装してテストするより安くなる
「あえてサマータイムをサポートしない」という決定こそが「やらなくていいことをやって価格を上げる」行為の第一歩だよ
Re:次は言い訳は許されない (スコア:1)
システム＝単一のアプリケーションを想定していますか？
それならたいして問題ないですよ。
問題は企業で使用されている、夜間バッチなどが存在するシステムです。
時間が、2時間分が消えたり2時間分が重複したりするんです。
２２：００～０２：００に動くように指定されたプログラムが起動されなかったり2回起動される可能性があります。
確実なのはサマータイムが開始される人終了される日の経済活動を停止することかな。
（銀行振り込み、ATMの引き出しも含む）
Re: (スコア:0)
道理じゃない
OSの時間管理システムはサマータイムをサポートしたタイムゾーン機能を提供しているのだから、それをそのまま使って実装してテストしたシステムの方が、サマータイムのない独自の時間管理機能を実装してテストするより安くなる
「あえてサマータイムをサポートしない」という決定こそが「やらなくていいことをやって価格を上げる」行為の第一歩だよ
でも実際サマータイム対応するとチェック項目は増えるよね？
しなくていいことをして作業量増やすのは不毛だよ
Re: (スコア:0)
Re: (スコア:0)
JSTだけを想定する場合、タイムゾーンが切り替わるケースのテストはしなくていい。
Re: (スコア:0)
そのソフトウェアを(サマータイムを導入している)諸外国で使うことを想定すると、
どのみちサマータイムのテストは必要だと思われます。
Re:次は言い訳は許されない (スコア:1)
国内でしか使わないシステムの場合は無駄だな
Re: (スコア:0)
時間管理システムはOSそのままだし、もし日本がサマータイム対応することになってもシステム自体は対応できるんだよ。
問題は、読み取った表示データを他のことに利用する人間およびサマータイムに対応していない日時で登録する人間の方。
入力した日時がサマータイム適用後に見かけ上違う日時になっていたりとか。
Re: (スコア:0)
世の中にはOSすら載っていない機器だってごまんとあることをご理解ください。