アカウント名:
パスワード:
『サマータイムにより2時間ないし、何時間と時間がずれても、そのまま処理するだけで影響は軽微です。目覚まし時計の時間がずれたら直すように「サマータイム」となったとき、コンピュータの時計を合わせ直せば良いだけのことです』(あるITジャーナリスト)
(まとめ [togetter.com])
ファイルシステムとか今どきだとクラウドとかデータベースが当たり前のように動いてる世の中で時間ずれが問題にならないとかすげぇことを言うなぁ。「ITって何の略だったっけ?って言うジャーナリスト」の略でITジャーナリストとか言ったりしないかなぁ。しないかぁ…
つか、時間ずれに関しちゃ、オフラインですら問題が起きるわけで。(時計をサマータイムに合わせればだが。)
単純に「何時間経過したか」を計算するプログラム(勤務表など)を考えてみればよい。
切り替わりの日、サマータイム開始日に 6時間しか働いてないのに2時間進めるせいで八時間として計算されたり、終了日に、一度目の5時と時計を戻した5時の区別がつかない為、6時間経過と8時間経過の区別がつかないとか。(勤務表で例を出しているが、経過時間を図るプログラムは全て同じこと)
本当にこの人、プログラム組んだ事あるんだろうか。
そんな事は普通の時間合わせですら起きるというのに最近はみんなNTP使ってる前提で普通にクライアントの時計を信用するんかね。というかクライアントのローカルタイムを信用すんなよ。海外で利用すれば変わるだろ。そもそも時間比較する時になぜ日本時間を勝手にサマータイムはありえないと仮定して使うのか…。
というかクライアントのローカルタイムを信用すんなよ。海外で利用すれば変わるだろ。そもそも時間比較する時になぜ日本時間を勝手にサマータイムはありえないと仮定して使うのか…。
そりゃ複数の国にまたがって使用するプログラムならUTCを使うだろうけど、日本ローカルでしか使わないプログラムでUTCを使うメリットってあるか?グローバルの時代だとか言ってどんなプログラムもグローバルタイムに対応させてもオーバースペックになって工数とバグが増えるだけだ。一部で必要とはいっても、それを全体に適用するのは愚の骨頂。
それに、今の日本では法律でサマータイムが規定されていない。決まっていないことに対応させることって必要か?対応コストが必要なのに?「将来的に○○があるかもしれないので対応させます。100万円予算を増やして。」と言って誰が納得する?
いや、むしろ100万円で時間計算ライブラリが作れるとは思わないが。。。100万円「も」ってお前はたかが100万で将来的に発生しうる何かを想定して計算できるんだな?日本だけ1日を24時間1分にします!とかなっても対応した状態で納品出来るんだよな?予算の追加もなくね
OSが対応してくれることを前提としているがお前が米をつけた相手はOSの対応可否に関わらず将来的に起こるかもしれない何かのために100万予算付けられるか?って言ってんのに自作云々選定できない云々ってお前の頭がバグってる案件でお前の頭が本当にあった怖いITだよ
例えばまさか電話番号を11桁固定長で持ってたりしないよな1桁増えるたびに改修費用請求するつもりなの?
当然請求するでしょう? 設計時点で11桁とする仕様で合意していたのであれば。(いちいち仕様合意するというよりは、ITU勧告に従う、みたいな決め事にしているケースが多いかもしれませんが)
電文のプロトコルで固定長決め打ちみたいなケースもあるのに、WebアプリとJSON(あるいはRDBのvarchar)だけで済む世界がすべてとか思ってないですよね?
そうかそうか、変わるぐらい想定すべきなんだな?お前の会社教えてくれよ?仕事依頼するから。今後法制度対応で改修が必要になっても全て対応済みなんだよな?勿論要求も何もしないで全て完璧に動くし追加費用も必要ないんだよな?
お前システム設計した事あんの?システム化の範囲の定義とか分かってる?要件に無いものを勝手に実装することの方が余程問題なんだけどわかってない?夏時間も世界では基本的に1時間で2時間はサポートしてないと思うんだけど何が対応してんの?システム化の要件にサマータイムに対応していることがないのであれば「考慮する必要はない」要件定義の段階で
無茶苦茶言うなぁ。じゃあ、あなたの会社ではカジノで使えるシステムをすでに販売しているんだよね。カジノは諸外国には普通にあるし、その法制度が変わりうることくらい設計時点で予測しているんだよね。POSシステムは当然、来年10月以降も改修なしで軽減税率を正確に適用できるんだよね。こっちは10%へ増税+軽減税率導入が決まっているから、できていないとは言わないよね。
よく半可通がこういうこと言いますけど、実際は全く逆です。
今現在、日本国外で使われる可能性の低いシステムを開発する場合、サマータイム対応などしてはいけません。
日本にもサマータイムが導入されるかもしれない、東日本と西日本で別のタイムゾーンが採用されるかもしれない、消費税のインボイス方式が導入されるかもしれない、道州制が採用されて都道府県がなくなるかもしれない……こういう「起こり得ること」に対応していくと、際限なくシステムは肥大化します。そして、「サマータイムの導入に備えて夜間バッチの実行スケジュールに1時間余裕を持たせいます」なんて言っていても、サマータイムが2時間早めることになったりして、裏切られたりします。そうなると、肥大化したシステムを改修するために、余計にコストがかかることになります。
おいおい。そういった「あとで対応しなければいけないけど、客が気付かず検収印を押してくれる」って項目は検収印押させるまでは黙っておいて、後で吹っ掛けて追加工数と保守費用を取るのが営業の腕ってものだろう。客が金を出してくれるせっかくの案件を、自分でつぶしてどうするよ?
夏時間もタイムゾーンの概念もないExcelの設計者に、頭のいいお前から何か指導してやってくれるか?
軽減税率への対応まで組み込み済みなの?#個人的には軽減税率って制度自体を実施するんじゃねぇ、と強く強く思ってるけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
さいきんみたいちばんこわいの (スコア:5, すばらしい洞察)
『サマータイムにより2時間ないし、何時間と時間がずれても、そのまま処理するだけで影響は軽微です。目覚まし時計の時間がずれたら直すように「サマータイム」となったとき、コンピュータの時計を合わせ直せば良いだけのことです』(あるITジャーナリスト)
(まとめ [togetter.com])
Re: (スコア:1)
ファイルシステムとか今どきだとクラウドとかデータベースが当たり前のように動いてる世の中で時間ずれが問題にならないとかすげぇことを言うなぁ。
「ITって何の略だったっけ?って言うジャーナリスト」の略でITジャーナリストとか言ったりしないかなぁ。
しないかぁ…
Re: (スコア:0)
つか、時間ずれに関しちゃ、オフラインですら問題が起きるわけで。(時計をサマータイムに合わせればだが。)
単純に「何時間経過したか」を計算するプログラム(勤務表など)を考えてみればよい。
切り替わりの日、サマータイム開始日に 6時間しか働いてないのに2時間進めるせいで八時間として計算されたり、
終了日に、一度目の5時と時計を戻した5時の区別がつかない為、6時間経過と8時間経過の区別がつかないとか。
(勤務表で例を出しているが、経過時間を図るプログラムは全て同じこと)
本当にこの人、プログラム組んだ事あるんだろうか。
Re: (スコア:0)
そんな事は普通の時間合わせですら起きるというのに最近はみんなNTP使ってる前提で普通にクライアントの時計を信用するんかね。
というかクライアントのローカルタイムを信用すんなよ。海外で利用すれば変わるだろ。
そもそも時間比較する時になぜ日本時間を勝手にサマータイムはありえないと仮定して使うのか…。
Re: (スコア:1)
というかクライアントのローカルタイムを信用すんなよ。海外で利用すれば変わるだろ。
そもそも時間比較する時になぜ日本時間を勝手にサマータイムはありえないと仮定して使うのか…。
そりゃ複数の国にまたがって使用するプログラムならUTCを使うだろうけど、日本ローカルでしか使わないプログラムでUTCを使うメリットってあるか?
グローバルの時代だとか言ってどんなプログラムもグローバルタイムに対応させてもオーバースペックになって工数とバグが増えるだけだ。
一部で必要とはいっても、それを全体に適用するのは愚の骨頂。
それに、今の日本では法律でサマータイムが規定されていない。決まっていないことに対応させることって必要か?対応コストが必要なのに?
「将来的に○○があるかもしれないので対応させます。100万円予算を増やして。」と言って誰が納得する?
Re: (スコア:0)
そんなの最初から標準APIのTimeオブジェクトに投げて計算させるだけだろ(OSが夏時間対応してればね)
そんな技術ない(まともな開発言語を選定できない)プログラマーからはむしろ100万円返してほしいね
Re:さいきんみたいちばんこわいの (スコア:1)
いや、むしろ100万円で時間計算ライブラリが作れるとは思わないが。。。
100万円「も」ってお前はたかが100万で将来的に発生しうる何かを想定して計算できるんだな?
日本だけ1日を24時間1分にします!とかなっても対応した状態で納品出来るんだよな?予算の追加もなくね
OSが対応してくれることを前提としているがお前が米をつけた相手は
OSの対応可否に関わらず将来的に起こるかもしれない何かのために100万予算付けられるか?って言ってんのに
自作云々選定できない云々ってお前の頭がバグってる案件でお前の頭が本当にあった怖いITだよ
Re: (スコア:0)
夏時間なんて諸外国では普通にある制度だしOSもサポートしてるんだから
それすらできない奴は設計費用返せってだけ
時間に限らないよ
例えばまさか電話番号を11桁固定長で持ってたりしないよな
1桁増えるたびに改修費用請求するつもりなの?
Re:さいきんみたいちばんこわいの (スコア:2)
当然請求するでしょう? 設計時点で11桁とする仕様で合意していたのであれば。
(いちいち仕様合意するというよりは、ITU勧告に従う、みたいな決め事にしているケースが多いかもしれませんが)
電文のプロトコルで固定長決め打ちみたいなケースもあるのに、WebアプリとJSON(あるいはRDBのvarchar)だけで済む世界がすべてとか思ってないですよね?
Re: (スコア:0)
そうかそうか、変わるぐらい想定すべきなんだな?
お前の会社教えてくれよ?仕事依頼するから。
今後法制度対応で改修が必要になっても全て対応済みなんだよな?
勿論要求も何もしないで全て完璧に動くし追加費用も必要ないんだよな?
お前システム設計した事あんの?システム化の範囲の定義とか分かってる?
要件に無いものを勝手に実装することの方が余程問題なんだけどわかってない?
夏時間も世界では基本的に1時間で2時間はサポートしてないと思うんだけど何が対応してんの?
システム化の要件にサマータイムに対応していることがないのであれば「考慮する必要はない」
要件定義の段階で
Re: (スコア:0)
無茶苦茶言うなぁ。
じゃあ、あなたの会社ではカジノで使えるシステムをすでに販売しているんだよね。
カジノは諸外国には普通にあるし、その法制度が変わりうることくらい設計時点で予測しているんだよね。
POSシステムは当然、来年10月以降も改修なしで軽減税率を正確に適用できるんだよね。
こっちは10%へ増税+軽減税率導入が決まっているから、できていないとは言わないよね。
Re:さいきんみたいちばんこわいの (スコア:1)
よく半可通がこういうこと言いますけど、実際は全く逆です。
今現在、日本国外で使われる可能性の低いシステムを開発する場合、サマータイム対応などしてはいけません。
日本にもサマータイムが導入されるかもしれない、東日本と西日本で別のタイムゾーンが採用されるかもしれない、消費税のインボイス方式が導入されるかもしれない、道州制が採用されて都道府県がなくなるかもしれない……
こういう「起こり得ること」に対応していくと、際限なくシステムは肥大化します。
そして、「サマータイムの導入に備えて夜間バッチの実行スケジュールに1時間余裕を持たせいます」なんて言っていても、サマータイムが2時間早めることになったりして、裏切られたりします。そうなると、肥大化したシステムを改修するために、余計にコストがかかることになります。
Re: (スコア:0)
おいおい。そういった「あとで対応しなければいけないけど、客が気付かず検収印を押してくれる」って項目は検収印押させるまでは黙っておいて、後で吹っ掛けて追加工数と保守費用を取るのが営業の腕ってものだろう。客が金を出してくれるせっかくの案件を、自分でつぶしてどうするよ?
Re: (スコア:0)
夏時間もタイムゾーンの概念もないExcelの設計者に、頭のいいお前から何か指導してやってくれるか?
Re: (スコア:0)
前回の増税時にはどうしたんだよ・・・
Re:さいきんみたいちばんこわいの (スコア:2)
軽減税率への対応まで組み込み済みなの?
#個人的には軽減税率って制度自体を実施するんじゃねぇ、と強く強く思ってるけど。