[特設]サマータイム対応相談室
■ このスレッドは過去ログ倉庫に格納されています
まともなシステムなら
ローカル時刻の入力があっても
クライアント側で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
もう散々きっちり回答済だからな
もう相手はしない 半角の人、繰返してるって自覚はあるんだ
ずっと同じこと言ってるよね オレはピンポントで回答はできるだけユニークにしてる
SQLでdsitinctつけたような美しい回答だからな
情報価値も高い このスレは現実にサマータイムに対応が必要なシステムを扱う人間のためのものなので
対応が必要ないと思う人は専用のスレでも立ててそっちで啓蒙してくれないかな 要件に合わせたDateTimePickerみたいなのを自作しちゃってるところは大変だよな
特に終了日の重複時刻を入力された時にそれがUTC換算でどちらを意図した入力なのか判断しようがない
ネットオークションの終了日時の設定とかどうすんだろ 自由に時刻が入力出来るところはもうそれがUTC+9なのかUTC+11なのかをユーザーに明示してもらうか、どちらか決めうちであることを明記して換算してもらうかしかやりようがない気がするな。
結局システム屋だけじゃなくて一般ユーザーも何かしらの対応が必要になる。やっぱ影響でかすぎる。 頭が弱い人は、サマータイムが起きてもUTCで扱っていれば
コンピュータは止まらないから問題ないとか言ってるが
論点はそこじゃないんだよね。
論点はサマータイムが起きた時、それをどのように扱いたいのかという仕様の話
一日が23時間 または 25時間の日ができるが、その時間で処理して良いのか
24時間に数値を補正するのか、UTCでみた24時間として
(つまりサマータイムがなかったものとして)処理するのか
世界的に見ると日本人が1時間早く行動するようになるが、
それに世界は合わせてくれるのか。
コンピュータさえ動いていればOKとか言ってるから
現実には大きな問題が発生することに気づけない アホ「サマータイム導入するかもしれないので、今から対策を考えましょう
2時間になるかもしれません。それを考慮しようと思います。
でもいきなり2時間ずれるとか体内時計がついていかないと思うんですよ。
きっと政府は、1時間ずつ二回に分けてずらすとか言うと思うんですよね。
だからスプリングタイム、サマータイム、そして秋にサマータイムの終わり、
冬にスプリングタイムの終わりってやると思うんですよね?
今からそれに備えて対応したいんで金ください
YAGNIなんて敵ですよ。予めいろんな事態に備えないと。金ください」 >>333
いや、タイムゾーンとサマータイムが区別ができていなかったのが、
一応ぐぐって調べた痕跡はある。 サマータイム開始日と終了日が明確なら対応は簡単じゃないの?
始業時間をちょっと変えてバンって感じで
勤怠プログラム作ったこと無いから平気で言えるけど >>342
まんまブラック顧客が言いそうな暴論でワロタ >>342
まず大抵の国内向け勤怠管理はJST決めうちで作ってあるはずだから、ここを何かしらの方法で直さなくちゃいけない。
でもってそれを直すことで副作用がないかどうかテストをしなくちゃいけない。
これでシステムの内部的には勤務時間を正確に計算できるようになったとして、
次にこれを画面に表示したり印刷したりする場合にどう表現するか考えて、それを実装しなくちゃいけない。
サマータイム期間内と期間外をまたぐ勤務時間があった時に、ただ09/15 03:00とだけ書いてあったらそれが1度目の3時なのか2度目の3時なのかわからない、など対処すべきことは沢山ある。 >>342
プログラムを直すのなんて簡単なんだよ
問題は、例えば夜勤の人がタイムゾーンをまたぐとき
その日は勤務時間が短くていいのか、短いとしたら給料も減らしていいのか等を決めないといけないだろ?
そういうことを考えてない上から改修しろと言われてしまうと
意見伺いや仲裁も全部SEの責任になって大変面倒なことになる
当然勝手に決めたら怒られる まだ低学歴知恵遅れそんなこといってんのか
システムではサマータイムもタイムゾーンも扱い方も管理のしかた同じなのに 低学歴底辺の負けず嫌いは異常だからな
ホントなすぐに分かる なんどもいうようだが
まずな低学歴底辺の知恵遅れは
自分がいかにゴミでクズな存在なのか自覚する必要がある
ホントなゴミクズのチンカスだからな
わかってんの? >>346
システムの動作に依存するパラメータが法令にある時刻で(労基法の深夜割増は22時からとか)、
そのパラメータがサマータイム例外規定とかで一部の工場は24時からとかになったらどうするのって話なわけで
UTCで管理してれば2時間のズレは表示上の問題でしかない、という話以上の問題がそこにはあるだろう
法令の時刻をDST実施中にUTC+9で読めばいいのかUTC+11で読めばいいのか現時点ではわからないのだから
例えば深夜割増の開始判定時刻は現状では365日JSTの場合しかないからUTCの13時と決まっているけれど、
今後の行政の動き次第では開始判定時刻がUTCの11時になったり、UTCの13時になったりとケースバイケースなわけで、
そんなの事前にシステム設計側で把握しておくことは不可能だっただろうって話だ。
そもそもJSTのローカルタイムのままシステムを動かすのか、JSTで表現されたローカルタイムをJDTとして再解釈して
システムを動かすのかもケースバイケースなわけで、スタンドアロンなシステムなら単なる決めの問題だが、
連携して動いているシステムでこの方針を統一できない場合もあってその場合はテストを相当にやりなおさなくちゃいけないだろう
ただそれを説明してお客さんが納得してくれるとも限らないからタイムゾーンを変えるなんてことを本当にやるのか?と皆思ってるわけで 簡単にまとめると、サマータイムが一時間だとして
1. サマータイム開始時・・・一日が23時間になる
2. サマータイム終了時・・・一日が25時間になる
3. サマータイム中・・・世界基準で考えると日本が一時間早く動き出す
4. サマータイム導入前に記録されたデータは上記に当てはまらない
5. サマータイム導入後に撤回されたら未来の予定に調整が必要
ってところかな。5は撤回されなければ対応する必要はないけど
なんか導入してダメだったらやめればいいだけって考えてそうだから、
やめるのにもコストが掛かりますよってことで書いた 通信手段を持たない組込機器とか、誰がアップデートするの? >>351
そう。試験導入とか、2年で一旦やめるとか、アホの極み。 半角くんってエンジニアじゃないよな。
仮にシステムに関わる人間だとしても、渡された詳細設計書通りにコードを書くことしか出来なさそう。
見えてる視野がそのレベルの広さしかないんだもん。 web屋とかなら半角くんも間違っちゃいないけどな
工場のシステムとか他社システムが絡むもんの入れ替えとか考えたくもないわ >>356
Web屋から見ても何から何まで間違っとるわw
静的なhtmlのサイトでちょっとjQueryでアニメーションつけてるくらいなら間違ってないだろうけどw >>350
やるなら法定時刻はUTCで定めてくれると、逆にありがたいけどね。
ただ海外、大陸をみると、現地時刻は幾つもある。
西海岸時間、中央時間、東海岸時間、あとはあるかはしらんが、ハワイのローカルタイム。
イギリスでもあんま知られていないようだが、太平洋に領地を持っていたりした。
数十年前なら香港なんかがある。
さて、そういう幾つものローカルタイムを文化として持った国は、法定時刻をどのように扱っているのか?
法的文書は、UTCで記録するのが、合理と思うが、タイムスタンプには、必ず「その時点の時差」を記録させる運用でないかと思う。
で、夏時間対応は、この時差記録機能の追加が柱になるんでないかと、個人的には考えている。
まあ、決めるのはじみんとー >>344
時差、タイムゾーンは、相対的な時刻の表示を替えること。
生活習慣上の時間軸で定められた時刻であれば、内規、おれルールを替える必要はない。
明日から9時が2時間早まるといって、わざわざルールを夏時間無適用の時刻で定め直す余計な手間になるから、そういう影響は少ないかと。 何にしろ誰得?みたいな話。
政治ねたを引用すれば、ある新聞社は、夏時間導入に大賛成したけど、明るい内に呑みに行けないからと記者が厭がって廃止に世論を誘導して廃止させたとか、
そーすは不祥事のあと落ち着いたのに、やめもしないアイツ オレがこのスレにこなくてさみしいの?
はっきりいってなもうこのスレはもう諦めた
計算機システムと無関係な話しかしてないからな
バカは問題のきりわけができないからな
あまりに頭悪いのしかいないからな エクセルがサマータイムに対応してないから
大変なことになるって騒がれてるな >>364
あれ速攻で否定されてたろ
そもそもExcelってアメリカ産だぞ な低学歴知恵遅れは願望のデマばっかり流す
エクセル単体ではおもいっきり対応してる
UTC+0900からUTC+1100になれば、普通に表示される内容もかわるからな
Excelも普通に通秒のシリアル値もってる
http://span.jp/office2013_manual/excel2013/format/date-user.html
(注2) 「種類」の中の「*2012/3/14」と「2012/3/14」つまり先頭に「*」(アスタリスク)がついているかどうかの違いは以下の通りです。
*2012/3/14: Windowsの地域設定の影響を受ける。
2012/3/14: Windowsの地域設定を変更しても影響を受けない。
これは、「*」がついていると、同じ日付でもWindowsの地域設定により表示形式が変化することを表しています。
例えば、海外のユーザーとデータを共有する場合にこの形式を用いると、それぞれの地域で使われている日付形式に自動的に変更されます。
低学歴底辺知恵遅れは道具の使い方も分かってない
自分が使い方をしらないもしくは使えなければ対応できてないということになるからな >>364
二時間ずらす森タイムに対応してんの?
古いVBAのマクロは改修しなくてもいいのね? 時計2時間早めたときに、海外に習うなら02:00から04:00に飛ばすんだろうが、
その間に行う処理ができなくなるとか、
また戻すときには重複して行ってしまうとか(こっちのが怖いか?)
あらゆるとこでいろんな事故が起こるんだろうな 海外に習うなら1時から3時だとおもうが
0時から飛ばすと影響があるから次の時刻から飛ばす
戻す場合もしかり 半角くんって嫌儲並の低レベルだな
ここに来るのはまだ早いんじゃないか? 嫌儲レベルですらない
あいつらは一応話できるし
こいつはエアプもいいとこのガイジ コボラーなら金融系とか経験あるだろうから、あんなことは間違っても言わないだろ
単体の計算機の時間を合わせることしか頭にないんだもん というか時間なんて自動設定だろ。
だから何もしなくていいということではなく
時間が変わることにソフトウェアが対応できてないのに
強制的に変えられてしまうことで不具合が発生する可能性がある ファイルやエクセルなどに日本時間で記録されてると
サマータイムの対応が必要になるだろうね。
ファイルやエクセルにUTCで書くやつなんていないしw 半角くんが言うところの低学歴知恵遅れが
プログラムを作ってるせいでヤバい機器が多数あるのが問題 >>382
でもなじゃあ高学歴なら対応できるのかと言うと、
サマータイムの話が出てない時に、
「バイトの夜勤時の勤務時間計算なんですが、サマータイムの開始と終了の日は
深夜0時から朝10時までの10時間で計算しますか?
それとも実際に働いた9時間または11時間で計算しますか?」と聞いても
「日本はサマータイム無いじゃねーか」って言われるのが落ちだと思う
高学歴ならそんなわかりきったこと聞かずにシステム作るよね
日本はサマータイムはないという前提でシステムが組まれてる システム云々じゃなく生活時間をずらせばええだけやん? 工作員説は信憑性あったんだが
文字コードスレで同じようなことやってるせいで否定されたのは
良いことなのかどうなのか 銀行の営業時間とか、法律で決め打ちされてるみたいよ。 ■ このスレッドは過去ログ倉庫に格納されています