[特設]サマータイム対応相談室
■ このスレッドは過去ログ倉庫に格納されています
なるほど知恵遅れのシステムでは
システムのスケジュールもハードコーディングされてんのか
なるほどな
知恵遅れらしい作りといっていい
むしろ知恵遅れでないと作れない それを当然のようにいうからな
おそろしい
知恵遅れはまともな人間の思考を超える愚かな事を
平気でするからな で、単にタイムゾーンをGMT+11に変更しただけな貴方の素晴らしいPCでは
前日はGMT+9、当日はGMT+11な複合表示に対応してくれるわけ? そもそもそんな要件が
必要かどうかというかという問題だからな
オマエの願望を叶えたいなら
オマエがその見返りはらえばいい
できないことはない
できることとやるということは
全然意味が違うからな
低学歴知恵遅れにはその違いがわからない
こういう低学歴知恵遅れは2ちゃんねるによく生息してる ところで具体性なく罵ることしかできないのは放っておいて関係ない話だが
このスレに書いておいたほうがいいと思うので書いとく
毎年同じサマータイムが繰り返されることを仮定せず特定の年でどうだったかを調べるには
WindowsではSystemTimeToTzSpecificLocalTimeEx(Ex付きの方)を使う
これはWin7からのAPIなので、Vista以前に作られたものは当然全滅 すみません、場違いかもしれませんが貼らせて下さい。
電波時計の標準電波の予備ビットや、時計メーカー側の対策状況など紹介されていたので。
サマータイム導入で「電波時計が狂う」? メーカーに聞いた - ITmedia NEWS
http://www.itmedia.co.jp/news/articles/1808/09/news094.html 訂正。GetTimeZoneInformationForYearというのがVistaからあった
参考まで UNIXだと struct tm の tm_isdst でサマータイム中かどうかは分かるね >>240
絶望的だね。要するに別途対応が必要で、
買い替えの必要性もあるってことだ 半角みたいなやつってどういう人間なんだろうな
画面の前で顔真っ赤にして延々と的外れなレスしてるの想像したら悲しくなるわ >>217
TCPのキープアライブ。
AD無限ループスクリプトとか、よくあるようの >>241
たまに夏時間パッチがくるのは、このせいか。
Unhxだと指定の日付から夏時間であったかを検査するようなアプリケーション機能を持った関数はないと思う。 > > 1時半(サマータイム切り替え前)の
> > 1時間後(サマータイム切り替わり後)は何時になるんだろうね
> 普通に3時半(サマータイム)になるだけ
それは大きな問題だね。
1時半の1時間後が3時半だとする。
通常の日付計算をすると、3時半から1時半の差は2時間だけど、
だけど実際には1時間しかない。
日付型にタイムゾーンの情報が含まれてないと
適切な日付計算が行えないっていうことか タイマーをセットする処理でも問題になりそう
現在1時半で1時間後にタイマーをセットするなんてことをすると
2時半にタイマーをセットすることになるが、途中で1時間飛ぶから
2時半は永遠に訪れない。
1時半から30分たった3時に、2時半を超えたという理由で
アラームがなるかもしれないね迷惑だw
こういう自体を防ぐには、実際の時間ではなく
経過時間を使用しなければいけないが、必ずしもそうとは言えないだろう。
つまりは、現在1時半として、1時間後と2時半では意味が違うというわけだ
その違いをシステムは適切に考えて実装しなきゃいけないし
命令を出す人間もその違いを適切に考えて設定しなければいけない
既存システムは全部見直しが必要だろうね アメリカの小学校とかでは、
今は○月○日(サマータイム切り替え直前の)の1時半です。
1時間後は何時になるでしょう?みたいな問題がでたりするのかな?w >>242
一時間なのか二時間なのかはわからないじゃん
>>248
なんでタイマーの処理なのにローカルタイムの引き算をするんだ?
お前みたいな人間がうるう年のバグを作りこむんだろうなあ > なんでタイマーの処理なのにローカルタイムの引き算をするんだ?
引き算じゃないよ? 足し算。
現在1時半で、1時間後にアラームをならすとして、
2時半にタイマー割り込みを設定したらダメという話 そう考えると、なんでdateコマンドとかには
1 hours agoみたいな日付の取得の仕方があるのかわかるね
タイムゾーン付き日付型じゃない限り、
取得した日時(タイムゾーンなし)を+1時間しても
正しい日時にはなるとは限らないんだよ 時間の入力チェックもまずいのか
エンドユーザーがUTCで入力してくれるわけもないし
サマータイムで抜け落ちる時間は、無効な時間になるんだよな 夜中のバックアップ設定とかも危険だよな
いつもよりも夜中が、1時間もしくは2時間短くなるわけだから
いつもよりも処理を早く開始しなければいけないが、
いつもよりも処理を早く開始したらまだ業務中かもしれない こんなときこそ企業が一致団結してサマータイムガン無視しろ
プレミアムフライデーもガン無視できたんだからいけるだろ >>253
入力チェックもまずいし、日付時刻を選択するセレクトボックスの生成もやばいな。
Webでもアプリでも、クライアントサイドでDate型を使って日付のバリデーションするような実装だとユーザーがOSアップデートしてくれない限りどうにもならない。
そもそもサマータイム終了日のAM03:00が1回目の3時なのか2回目の3時なのかを判別する方法もない。
これ全部直すとか、死ねるわw そもそも日本で売ってるAndroidスマホってほぼOSアップデート提供されないだろ
どうすんだよこれ アホが知恵遅れな作りにしてるからそうなるワケ
やっぱりアホは死んでも治らないわ
javascriptですら
Date.getTimezoneOffset()があるからな
コレがなんのためにあるかすら分かってない
ユーザーのクラアント計算機のUTCが分かるのあたりまえとして
ユーザーのクラアント計算機がどの程度の時差があるタイムゾーンが設定されてて
クライアント計算機にどんな時刻が表示されてるかも分かるからな
そもそもローカル時刻をネットワーク経由で送信してること自体が大きな間違いだからな
コレがザ知恵遅れが即座におもいつく知恵遅れ設計 >>242 >>250 ← でなコイツラみたいな知恵遅れはきっとコレがなんのソースでなんのデータが入ってるか分からない
ftp%3A//ftp.iana.org/tz/tzdb-2018e/
>>241 ← コイツみたいな相当頭悪い知恵遅れが
意味不明なドヤ顔してるワケ
マジでこのスレには相当レベルの低学歴知恵遅れしかいない
ほかの知恵遅れの疑問はすべて回答済
繰り返しは省略
理解力に相当な問題あある相当レベルの知恵遅れが同じこと念仏のように唱えてるだけだからな まともに設計されたシステムならシステムでは一切問題おきない
まともな教育を受けてない低学歴知恵遅れのぼくが設計したシステムだと
アタリマエのように問題が多発する
知恵遅れのなんちゃってシステム屋か
パチョコンの大先生がテキトーなこといってるだけだからな
全世界では、普通にシステムで夏時間が運用されてるワケだからな
https://www.time-j.net/
https://www.time-j.net/WorldTime/Area/NorthAmerica
かりにこんな知恵遅れなヤツラがコードいじってるかと思うと
ホントなぞっとするわ 知恵おくれ↓
2 名前:デフォルトの名無しさん[] 投稿日:2018/08/14(火) 21:34:18.46 ID:FLQzRhNo [1/2]
オレのvistaですら
すでに日本の夏時間対応済になってんのに
なにいってんのコイツ
3 名前:デフォルトの名無しさん[] 投稿日:2018/08/14(火) 21:40:58.04 ID:FLQzRhNo [2/2]
(GMT+11) サハリン
(GMT+11) ソロモン諸島、ニューカレドニア
(GMT+11) チョクルダフ
(GMT+11) ノ-フォーク島
(GMT+11) ブーゲンビル島
(GMT+11) マガダン
この中から好きなの選べばいい
コレで日本のサマータイム対応だからな
システムに一切問題なんかおきない
正しく動作する サマータイムを想定した設計になってればサマータイムになっても問題ない、なんていう小学生でもわかることを延々繰り返して100レスくらいしてるよなこいつw ×サマータイム想定したシステム
○普通に国際化対応されたシステム
あのなシステムというのはクソニートが
ママに動いてるとこみせるもんじゃないわけ オマエもママもずっと日本にしかいないからな
アメリカにいってアメリカのタイムゾーン設定して
計算機の動作がおかしいおかしいとひたすらいってるのが
このスレのクソニート知恵遅れだからな >>266
ところで先生はどういう仕事してるの?開発職? キャー今日も先生がいらしてますよー!
みんなもてなしてあげて♡ このスレでクソニートを更生させる仕事してる
クソニートがどんだけクズでゴミな存在なのか自覚させる仕事してる >>269
それは崇高な仕事だね。
でもお金にならないでしょう。 >>253
ローカル時刻を入力するUIてのは、ありそうで無さそうなんだよな。
× 先物で、時刻指定で下限なしで約定
× 15時に自動決済
× 時刻指定で配送
× 時刻表の表示変更(相対時刻表示で運用できる。出力を夏時間に合わせたところで、結果は同じ)
対応するなら、夏時間の対応せずに
「この時刻は夏時間ではありません」
と表示して夏時間ガン無視が最も合理的でリスクがない。 >>259 >>260
半角先生も、GMT+11な他の土地のタイムゾーンを流用しては
解決にならないことを悟られたようで何よりです
getTimezoneOffsetも、Dateオブジェクトの値によって
その時点のオフセットを調べてくれますもんね >>271
うちのサービスだと有りそうで実際にあるわ。
作業記録の開始日時と終了日時を入力する画面がある。
どうすっぺかなー また知恵遅れ意味不明なこといってるわ
普通でもgetTimezoneOffsetすら使わないからな
もともとすべて時刻はUTCで保存だからな
あとIANAのソースとデータののリンクはってやってるのに
それすら読まない
いや読むことができる程度の知能がない
知能に相当な問題がある
知能に軽度の障害があると推認できる いやだなー
これまでUTCとOSの機能を使えと主張しておられた半角先生が
まさか今更データーベースを抱えて自前で処理しろなんてことをおっしゃられるとは 知恵遅れがボクの考えた設計とかどうでもいいわけ
いかんせんオマエは知能に重篤な障害がある
それを自覚したほうがいい >>264
サマータイムが二時間のシステムなんかどこにもないって話はずっと無視されてんだよなー。
なんか森とか遠藤の手下なんじゃないの?自民党の工作員は時々質が著しく低いんだよ。 なるほど
暴れてるのはパヨチョンか
だったら知恵遅れなのはしょうがない
知恵遅れでないとネトウヨやパヨチョンにはなれない おーまた来てる
おんもしれえなこのキチゲェが!
ぜひなんJに来てレスバしてほしい >>269
自分から更生しろよ
間違い指摘されているのに毎日同じようなこと連投するキチガイとか何のために生きてんの 間違い?
ホンキでそんなことをいってるのが恐ろしいわ。。。
アマゾンがクライアント計算機のローカル時刻を保存してるとホンキで思ってるワケか
クライアント計算機からローカル時刻の入力がある場合でもな
クライアント計算機が設定してるタイムゾーンがなんだろうが
アマゾンのサーバーは知ったこちゃないワケ
アマゾンはクライアント計算機で設定されてるタイムゾーンに従って
処理するだけだからな まず、低学歴知恵遅れは時刻というもんが
なんにも理解できてない
まともな教育を受けてないとこうなる 変換の根拠は、クライアント計算機に設定されてるタイムゾーン
日本に住んでるくせにアメリカのタイムゾーンに設定したら、
当然アメリカの時差の基準で処理される
それ以外なにもない まともなシステムなら
ローカル時刻の入力があっても
クライアント側でUTCの時刻に変換してからサーバー側に送るからな それつまりクライアント側がAsia/Tokyoのサマータイムに対応してなくてオフセット9時間で計算しちゃったら詰むじゃん クライアント側のローカル時刻がUTC+09:00なら
時計でもUTC+09:00で表示されてる
なにも間違ってない
設定どおりに表示されてる
頭悪いの? Asia/Tokyoの文字列でサマータイムに対応してないボロイ計算機は
>>262 ←この設定でいける
なんの支障もない
問題なんか起きようがない
回避手段まである 相変わらず話の前提を無視した上に自分では勝手に非現実的な前提をつけててワロタ で、アホはいまだに概ねの計算機で時刻をどう扱ってるか分かってないようだからな
なにがどうなってるか分かるようにjavascriptでアホ教育用のサンプルコードを書いてやったわ
https://ideone.com/Yl3GjP
一部抜粋する
コレで分からないなら人間やめたほうがいい
ホモサピエンスに分類できる知能がない
var ahoDate = new Date();
var ahoTime = parseInt(ahoDate.getTime() / 1000); // 保存する時刻(普通は秒単位で十分)
var ahoTimezoneOffset = ahoDate.getTimezoneOffset(); // ローカル時刻の入力がある場合以外、普通は使わない
var ahoTimezone = -ahoTimezoneOffset * 60; // ローカル時刻の入力がある場合、この秒数分だけ引く(JSTなら9*60*60の値になってる)
print("POSIX Time : " + ahoTime + " sec");
print("TimezoneOffset : " + ahoTimezoneOffset + " min");
print("Timezone : " + ahoTimezone + " sec");
// ↓アホ教育用 コレでアホでもなにがどうなってるか分かるハズ
var ahoTimeAho = ahoTime + ahoTimezone;
var ahoDateUTC = new Date(ahoTime);
var ahoDateJST = new Date(ahoTimeAho);
ahoDateUTC.setTime(ahoTime * 1000);
ahoDateJST.setTime(ahoTimeAho * 1000);
print(ahoDateUTC.toUTCString());
print(ahoDateJST.toUTCString()); クライアントの現在時刻じゃなくてUIから手動で任意の日時を入力して送る時の話だってんだよアホ アホはDateコンストラクタの引数入力値に
任意の値が設定できることもしらないワケか
まずリファレンスを読む能力がない var ahoDate = new Date(2018, 8, 15, 22, 27, 00);
こんな感じでフォームオブジェクトから値とって設定するだけだからな
サルでも分かりそうなことが理解できない
やばいわ。。。 それがなんの解決にもなってないことがわからない辺りがさすがマジキチ var ahoDate = new Date(2018, 8, 15, 22, 27, 00);
var ahoTime = parseInt(ahoDate.getTime() / 1000); // 保存する時刻(普通は秒単位で十分)
はっきりいってな2行で済む
ahoTimeをサーバーに送るだけでおしまい >>297
もしそれで本当に解決できてると思ってるなら頼むからお前が書いたコードを世に出すのはやめてくれよ オマエみたいな知恵遅れが知恵遅れな作りにしたんだからしょうがない
知恵遅れが開き直ってるしな ホントな知恵遅れは知恵遅れ設計の問題点がわかってない
だからいつまでたっても人間になれないわけ POSIXタイム用のインターフェースなんか
いまどきどんなシステムでももってるからな そもそもサマータイムで問題は起きないから対応なんて必要ないって主張だったはずなのにコードの修正例を載せようとしちゃってる矛盾に気がついてないあたりとても好きだよ。 まともなシステムなら問題がおきるわけがないからな
当然の設計ができてないワケだからな
まともな人間が設計すればおきないことがおきると
自信満々にいってるワケだからな
知恵遅れが知恵遅れな設計で知恵遅れシステム作ってますといってる以上
こうしか書きようがない
まともな人間ならありえないことを平気でやるわけだからな 知恵遅れが自分が知恵遅れであると
自白してるのがこのスレだからな
その自覚がない
ゴミでクズのくせにそういった自覚がないのは
クソニートや低学歴底辺に多い
コレは定説 タイムゾーン大先生はスルーして
>>271
うちの納品したシステムでも普通にあるわ。
メディアプレイヤーの大げさなもので、ユーザー(博物館とかの運営者)が時刻を指定して
特定のコンテンツを特定の時間に再生するようなもの。
サイネージ系だと結構普通にあるんじゃないかな。
もっとも、JDTのローカルタイムに読み替えで問題があるケースは、太陽の位置に依存したコンテンツとかに限られるだろうけど。 >>259
> アホが知恵遅れな作りにしてるからそうなるワケ
知恵遅れじゃないよ。必要になってないのに
サマータイム導入でしかも2時間に対応するなんことはしないの
むしろしたらダメなんだよ。2時間は世界のどこでも使われてないんだから
それを言ったら3時間はどうする? 年に複数回あったらどうする?とかまでなっちゃう
この話が勃発する前に客が求めてもないのに、日本がサマータイム導入されたときの
仕様はどうしましょうか?なんて、質問したらダメなの。無駄なコスト。
質問したところで考慮しなくていいって言われるだろうし 確かに、自分から日本滅亡のスイッチを押す必要は無いな。 ホントな低学歴知恵遅れは頭悪すぎて
涙がでてるくるわ。。。
こんだけ懇切丁寧に説明してやってるのに
いまだになにも理解できてないからな
むしろローカル時刻で保存するほうが
余計な対応をしてる
普通にひたすらUTCで交換すれば
システムでは問題なんかおきようがない
しかもそっちのほうが自然な作りになるしシンプルで簡単になるからな
普通につくればタイムゾーン変更すればそのとおりに動く
2時間だろうが3時間だろうが関係ない
かりにパリのタイムゾーン設定したり、ニューヨークのタイムゾーン設定しても
普通にそのタイムゾーンとおりに動くのと同じだからな
低学歴知恵遅れがいちいち余計なことしてコレもできなくしてるだけだからな
そもそもサマータイム対応以前の問題
低学歴知恵遅れはやらなくていい余計なことをして
いちいち問題おこしてるワケ
わかる? まず低学歴知恵遅れは
システムのTZやLOCALEやNLSみたいな環境変数がなんのためにあるかすらも
なんにも理解してないのがよくわかったわ
低学歴知恵遅れが作る程度のシステムでは
特殊な要件がないかぎり、余計な独自の実装とかもともと不要だからな
使用してるシステムのもともとある基本機能にまかせるのが一番簡単なのはアタリマエ
それやらないでいちいち余計なことして問題おこしてるワケ
※ すべてまともな教育を受けてない白痴に由来する
低学歴知恵遅れにシステム設計させると
日本のタイムゾーンがかわると太陽の軌道計算までずれるような作りに間違いなくすることが
↓このレスから予見できる
>>305
日本のタイムゾーンがかわっても 太 陽 の 移 動 が か わ る ワ ケ が な い からな
※ ちなみにユリウス日はPOSIXタイムと考え方的には同じ
つまり、低学歴知恵遅れがシステムを設計すると普通にこんなことがおきる
それが普通だと自信満々でいってるワケだからな
おそろしい。。。 >>310
えとさぁ、だからみんな言ってるじゃん?
サマータイムのことなんか考慮してないで
作ってるから大問題になるって。
サマータイムのことなんか考慮してないっていうのは
そのTZやLOCALEやNLSみたいな環境変数のことなんか
全然見てないってことだよ?
だから大問題になるって言ってるのに > サマータイムは全体をずらすものなのだから
> サマータイムの始まる前の時間もずれるべきだろ?
> 違うの?
違う。決められた時間(世界的には夜2時が多いらしい)に
1時間時計を進める。言い換えるとその日が23時間になる。
また終わるときは1日が25時間になる。
夜間が短くなるということは、夜間バッチを開始して
処理完了までの猶予時間が1時間減るということ。
もちろん2時間ずらすなら、2時間ずれる
夜中の2時に初めて朝6時までに完了、すなわち4時間の間に
終わらせればよかった処理が、半分のたった2時間になるということ サマータイムで問題になるのは "今日" のデータを集計する時
当たり前だが日本で今日といったら、JSTの時間で
今日にあたるデータを集計しなければいけない
ではサマータイムに突入する日、この日は23時間しかない
では23時間分のデータを集めるので良いのか?
といったら要件による
今日一日のネットワークトラフィックであれば24時間の方が適切だろう。
だけど今日一日の来場者数であれば、23時間分で良いだろう
すなわち何が適切かを全て見直さなければいけない
それが一番大変 サマータイムがあったからって、UTCで扱えば
問題ないかのように言ってるやつがいるがそれは大間違いだ
なぜなら、UTCは変わらずとも人間の行動が変わるからだ
日本時間朝10時(=UTC 1時)に業務開始だったものが
UTC 0時に業務開始に変わる。
その他すべての日本人の行動が、UTCで見て1時間早くなる オレのエレガントなサンプルコードをみればわかるとおり
クライアント側ではタイムゾーンなんか一切気にせずに
タイムゾーンを含めて時刻を処理できることがわかる
しかも超簡単
↓エレガントなサンプルコード
https://ideone.com/pOGvRt
ほとんどエクセルでマクロ作ってコピって作ったわ
こんなもん人間が作るもんじゃない。。。
@日本時間 https://i.imgur.com/m4EO0sL.png
Aニューヨーク時間(現在サマータイム中) https://i.imgur.com/k6IFr2b.png
Bパリ時間(現在サマータイム中) https://i.imgur.com/2vOsBYd.png
C日本時間(サマータイム) https://i.imgur.com/iNfxjHn.png
サーバーからPOSIXタイムを取得できたら
超簡単なsetSelectLocalTime()を呼びだすだけで
プルダウンの時刻が復元できることがコードから分かる
クライアントは超簡単なgetSelectLocalTime()を呼びだして取得できた値(POSIXタイム)を
サーバーに送信するだけで適切な時刻が送信できることがコードから分かる
サーバー側でもクライアント側の時差なんか一切気にする必要ない
特殊な要件でもないかぎり、そもそもサーバー側で時刻を保存するためにタイムゾーンの情報すら取得不要
クライアント側は、クライアント側で設定されてるタイムゾーンにあわせて表示する(超簡単なsetSelectLocalTime()を呼ぶだけ)だけだからな
※ つまりまともに設計されてるなら作るとき時差すら意識する必要すらない
※ コードの修正すら不要 システムの設定を更新する作業だけの話だからな そして簡単な試験しておしまい
※ こんなに簡単にできるのは、もともとシステムが国際化の基本機能を実現してるからだからな
※ そして、それはクライアント側でもサーバ側でも実現されてる もしかして低学歴知恵遅れは
アマゾンがいちいち夏時間を設定してないクライアント計算機の時差まで
考慮してくれるとか思ってんの?
もしかして低学歴知恵遅れは
クライアント計算機に夏時間の対応がなかったら、
クライアント計算機からアマゾンで買い物できなくなるとか思ってんの?
もしかして低学歴知恵遅れは
日本が夏時間になったら
日本からアマゾンで買い物できなくなるとか思ってんの?
もしかして低学歴知恵遅れは
日本が夏時間になったら
アマゾンが大混乱するとか思ってんの?
マジでそんな頭悪いこと思ってんの? データをUTCで記録していたとしよう。
そうすると人間の行動が1時間早くなることで
例えば何かしらのデータのピーク時間が
UTC 5時からUTC 4時にかわってしまうことになる。
日本的には特に何も変わってないわけだが、
データ上は大きな変化が発生したことになってしまう。
だからデータの種類によっては、サマータイムを考慮しなければならない
データをUTCで記録していたって、システムの仕様変更が発生する例だ 時系列の時間発展のデータでなにをアホなこといってんのコイツ
著しく知能が低いヤツがいうことはホントな意味不明なことをいう
システムの問題じゃないからな >>316
> 日本が夏時間になったら
> アマゾンが大混乱するとか思ってんの?
大混乱は発生しないかもしれないが、多少の混乱は発生するだろうな。
なぜなら商品の売れる時間帯が1時間ずれることになる
時間帯によって売れやすい商品を検索の上位にしていたりすると
売上にも影響は出てくるだろう >>320
計算システムは問題なくても
大混乱が起きるって話をしている。 あのなサマータイムのこと考慮してないで作ってないレベルじゃないワケ
常識的な設計ができてないという話だからな
いちいち日本だけで動けばイイように作る必要がそもそもないからな
手間なんかかわらないのに >>322
> サマータイムは全体をずらすものなのだから
> サマータイムの始まる前の時間もずれるべきだろ?
> 違うの?
違う。決められた時間(世界的には夜2時が多いらしい)に
1時間時計を進める。言い換えるとその日が23時間になる。
また終わるときは1日が25時間になる。
夜間が短くなるということは、夜間バッチを開始して
処理完了までの猶予時間が1時間減るということ。
もちろん2時間ずらすなら、2時間ずれる
夜中の2時に初めて朝6時までに完了、すなわち4時間の間に
終わらせればよかった処理が、半分のたった2時間になるということ やっぱりな低学歴知恵遅れは
問題の本質がなんにも理解できてない >>322
サマータイムで問題になるのは "今日" のデータを集計する時
当たり前だが日本で今日といったら、JSTの時間で
今日にあたるデータを集計しなければいけない
ではサマータイムに突入する日、この日は23時間しかない
では23時間分のデータを集めるので良いのか?
といったら要件による
今日一日のネットワークトラフィックであれば24時間の方が適切だろう。
だけど今日一日の来場者数であれば、23時間分で良いだろう
すなわち何が適切かを全て見直さなければいけない
それが一番大変 >>324
問題の本質は、サマータイム導入で
システム改修のために長い検証期間と
大きなコストかかるってこと。
お前は計算システム "だけ" 動いてるから
それで満足していればいいじゃないですかw そんなもん決めの問題だからな
一回決めたらおしまい
低学歴知恵遅れはどうでもいいしょうもない心配しかしないからな
しかもこのスレにいるような低学歴知恵遅れには無関係な話 要件通りに適切に動いてるのに
かえろというならおカネもらうだけだからな >>327
ほら、言い返せなくなっちゃったw
夜間バッチの時間が1時間短くなっても
計算システムは動いてますからねーw
ただ朝の営業時間に間に合わなくなるだけですよねーw 低学歴知恵遅れのは
開発したほうに間違いなく瑕疵がある >>328
だから一日が23時間になることで、また世界的に見ると
日本人の行動がUTC時間で1時間早くなることで、
もともとの要件を満たせなくなってないかの検証に
莫大な時間とコストがかかるっていうのが本質的な問題 また同じこと繰り返すのか
>>90>>92>>112>>125>>126
>>127>>128>>130
>>131
もう散々きっちり回答済だからな
もう相手はしない 半角の人、繰返してるって自覚はあるんだ
ずっと同じこと言ってるよね ■ このスレッドは過去ログ倉庫に格納されています