[特設]サマータイム対応相談室

**デフォルトの名無しさん** · 2018/08/11(土) 09:39:28.62

はいどうぞ

**デフォルトの名無しさん** · 2018/08/15(水) 19:47:20.50

>>253
ローカル時刻を入力するUIてのは、ありそうで無さそうなんだよな。
× 先物で、時刻指定で下限なしで約定
× 15時に自動決済
× 時刻指定で配送
× 時刻表の表示変更(相対時刻表示で運用できる。出力を夏時間に合わせたところで、結果は同じ)

対応するなら、夏時間の対応せずに
「この時刻は夏時間ではありません」
と表示して夏時間ガン無視が最も合理的でリスクがない。

**デフォルトの名無しさん** · 2018/08/15(水) 20:07:27.30

>>259 >>260
半角先生も、GMT+11な他の土地のタイムゾーンを流用しては
解決にならないことを悟られたようで何よりです
getTimezoneOffsetも、Dateオブジェクトの値によって
その時点のオフセットを調べてくれますもんね

**デフォルトの名無しさん** · 2018/08/15(水) 20:10:41.09

>>271
うちのサービスだと有りそうで実際にあるわ。
作業記録の開始日時と終了日時を入力する画面がある。

どうすっぺかなー

**デフォルトの名無しさん** · 2018/08/15(水) 20:11:43.67

また知恵遅れ意味不明なこといってるわ
普通でもgetTimezoneOffsetすら使わないからな
もともとすべて時刻はUTCで保存だからな

あとIANAのｿｰｽとﾃﾞｰﾀののﾘﾝｸはってやってるのに
それすら読まない
いや読むことができる程度の知能がない

知能に相当な問題がある
知能に軽度の障害があると推認できる

**デフォルトの名無しさん** · 2018/08/15(水) 20:15:57.97

いやだなー
これまでUTCとOSの機能を使えと主張しておられた半角先生が
まさか今更データーベースを抱えて自前で処理しろなんてことをおっしゃられるとは

**デフォルトの名無しさん** · 2018/08/15(水) 20:16:53.10

知恵遅れがﾎﾞｸの考えた設計とかどうでもいいわけ
いかんせんｵﾏｴは知能に重篤な障害がある
それを自覚したほうがいい

**デフォルトの名無しさん** · 2018/08/15(水) 20:19:18.65

>>264
サマータイムが二時間のシステムなんかどこにもないって話はずっと無視されてんだよなー。
なんか森とか遠藤の手下なんじゃないの？自民党の工作員は時々質が著しく低いんだよ。

**デフォルトの名無しさん** · 2018/08/15(水) 20:20:56.74

世界ネット工作国四天王
中国ロシアアメリカ日本

**デフォルトの名無しさん** · 2018/08/15(水) 20:21:06.18

なるほど
暴れてるのはﾊﾟﾖﾁｮﾝか
だったら知恵遅れなのはしょうがない

知恵遅れでないとﾈﾄｳﾖやﾊﾟﾖﾁｮﾝにはなれない

**デフォルトの名無しさん** · 2018/08/15(水) 20:24:22.95

おーまた来てる
おんもしれえなこのキチゲェが！
ぜひなんJに来てレスバしてほしい

**デフォルトの名無しさん** · 2018/08/15(水) 20:42:15.87

>>278
VANKの韓国は入らないの？

**デフォルトの名無しさん** · 2018/08/15(水) 20:57:02.21

>>269
自分から更生しろよ
間違い指摘されているのに毎日同じようなこと連投するキチガイとか何のために生きてんの

**デフォルトの名無しさん** · 2018/08/15(水) 21:16:31.10

間違い？
ﾎﾝｷでそんなことをいってるのが恐ろしいわ。。。

ｱﾏｿﾞﾝがｸﾗｲｱﾝﾄ計算機のﾛｰｶﾙ時刻を保存してるとﾎﾝｷで思ってるﾜｹか

ｸﾗｲｱﾝﾄ計算機からﾛｰｶﾙ時刻の入力がある場合でもな
ｸﾗｲｱﾝﾄ計算機が設定してるﾀｲﾑｿﾞｰﾝがなんだろうが
ｱﾏｿﾞﾝのｻｰﾊﾞｰは知ったこちゃないﾜｹ

ｱﾏｿﾞﾝはｸﾗｲｱﾝﾄ計算機で設定されてるﾀｲﾑｿﾞｰﾝに従って
処理するだけだからな

**デフォルトの名無しさん** · 2018/08/15(水) 21:22:06.63

>>283
アマゾンで働いてるんですか？

**デフォルトの名無しさん** · 2018/08/15(水) 21:23:43.41

まず、低学歴知恵遅れは時刻というもんが
なんにも理解できてない

まともな教育を受けてないとこうなる

**デフォルトの名無しさん** · 2018/08/15(水) 21:25:43.37

変換の根拠は、ｸﾗｲｱﾝﾄ計算機に設定されてるﾀｲﾑｿﾞｰﾝ

日本に住んでるくせにｱﾒﾘｶのﾀｲﾑｿﾞｰﾝに設定したら、
当然ｱﾒﾘｶの時差の基準で処理される

それ以外なにもない

**デフォルトの名無しさん** · 2018/08/15(水) 21:28:14.80

まともなｼｽﾃﾑなら
ﾛｰｶﾙ時刻の入力があっても
ｸﾗｲｱﾝﾄ側でUTCの時刻に変換してからｻｰﾊﾞｰ側に送るからな

**デフォルトの名無しさん** · 2018/08/15(水) 21:58:29.79

それつまりクライアント側がAsia/Tokyoのサマータイムに対応してなくてオフセット9時間で計算しちゃったら詰むじゃん

**デフォルトの名無しさん** · 2018/08/15(水) 22:14:33.37

ｸﾗｲｱﾝﾄ側のﾛｰｶﾙ時刻がUTC+09:00なら
時計でもUTC+09:00で表示されてる

なにも間違ってない
設定どおりに表示されてる

頭悪いの？

**デフォルトの名無しさん** · 2018/08/15(水) 22:18:59.41

Asia/Tokyoの文字列でｻﾏｰﾀｲﾑに対応してないﾎﾞﾛｲ計算機は
>>262 ←この設定でいける
なんの支障もない

問題なんか起きようがない
回避手段まである

**デフォルトの名無しさん** · 2018/08/15(水) 22:27:11.76

相変わらず話の前提を無視した上に自分では勝手に非現実的な前提をつけててワロタ

**デフォルトの名無しさん** · 2018/08/15(水) 22:28:33.23

で、ｱﾎはいまだに概ねの計算機で時刻をどう扱ってるか分かってないようだからな
なにがどうなってるか分かるように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());

**デフォルトの名無しさん** · 2018/08/15(水) 22:29:49.74

クライアントの現在時刻じゃなくてUIから手動で任意の日時を入力して送る時の話だってんだよアホ

**デフォルトの名無しさん** · 2018/08/15(水) 22:31:24.45

ｱﾎはDateｺﾝｽﾄﾗｸﾀの引数入力値に
任意の値が設定できることもしらないﾜｹか

まずﾘﾌｧﾚﾝｽを読む能力がない

**デフォルトの名無しさん** · 2018/08/15(水) 22:33:16.66

var ahoDate = new Date(2018, 8, 15, 22, 27, 00);
こんな感じでﾌｫｰﾑｵﾌﾞｼﾞｪｸﾄから値とって設定するだけだからな
ｻﾙでも分かりそうなことが理解できない

やばいわ。。。

**デフォルトの名無しさん** · 2018/08/15(水) 22:37:20.18

それがなんの解決にもなってないことがわからない辺りがさすがマジキチ

**デフォルトの名無しさん** · 2018/08/15(水) 22:37:23.34

var ahoDate = new Date(2018, 8, 15, 22, 27, 00);
var ahoTime = parseInt(ahoDate.getTime() / 1000); // 保存する時刻（普通は秒単位で十分）

はっきりいってな2行で済む
ahoTimeをｻｰﾊﾞｰに送るだけでおしまい

**デフォルトの名無しさん** · 2018/08/15(水) 22:39:55.81

>>297
もしそれで本当に解決できてると思ってるなら頼むからお前が書いたコードを世に出すのはやめてくれよ

**デフォルトの名無しさん** · 2018/08/15(水) 22:40:00.48

ｵﾏｴみたいな知恵遅れが知恵遅れな作りにしたんだからしょうがない
知恵遅れが開き直ってるしな

**デフォルトの名無しさん** · 2018/08/15(水) 22:41:17.48

ﾎﾝﾄな知恵遅れは知恵遅れ設計の問題点がわかってない
だからいつまでたっても人間になれないわけ

**デフォルトの名無しさん** · 2018/08/15(水) 22:42:25.29

POSIXﾀｲﾑ用のｲﾝﾀｰﾌｪｰｽなんか
いまどきどんなｼｽﾃﾑでももってるからな

**デフォルトの名無しさん** · 2018/08/15(水) 22:42:32.98

そもそもサマータイムで問題は起きないから対応なんて必要ないって主張だったはずなのにコードの修正例を載せようとしちゃってる矛盾に気がついてないあたりとても好きだよ。

**デフォルトの名無しさん** · 2018/08/15(水) 22:45:11.16

まともなｼｽﾃﾑなら問題がおきるわけがないからな
当然の設計ができてないﾜｹだからな
まともな人間が設計すればおきないことがおきると
自信満々にいってるﾜｹだからな

知恵遅れが知恵遅れな設計で知恵遅れｼｽﾃﾑ作ってますといってる以上
こうしか書きようがない

まともな人間ならありえないことを平気でやるわけだからな

**デフォルトの名無しさん** · 2018/08/15(水) 22:46:45.58

知恵遅れが自分が知恵遅れであると
自白してるのがこのｽﾚだからな

その自覚がない

ｺﾞﾐでｸｽﾞのくせにそういった自覚がないのは
ｸｿﾆｰﾄや低学歴底辺に多い

ｺﾚは定説

**デフォルトの名無しさん** · 2018/08/16(木) 00:08:48.79

タイムゾーン大先生はスルーして
>>271
うちの納品したシステムでも普通にあるわ。
メディアプレイヤーの大げさなもので、ユーザー(博物館とかの運営者)が時刻を指定して
特定のコンテンツを特定の時間に再生するようなもの。
サイネージ系だと結構普通にあるんじゃないかな。
もっとも、JDTのローカルタイムに読み替えで問題があるケースは、太陽の位置に依存したコンテンツとかに限られるだろうけど。

**デフォルトの名無しさん** · 2018/08/16(木) 02:16:41.93

>>259
> ｱﾎが知恵遅れな作りにしてるからそうなるﾜｹ

知恵遅れじゃないよ。必要になってないのに
サマータイム導入でしかも2時間に対応するなんことはしないの
むしろしたらダメなんだよ。2時間は世界のどこでも使われてないんだから
それを言ったら3時間はどうする？年に複数回あったらどうする？とかまでなっちゃう

この話が勃発する前に客が求めてもないのに、日本がサマータイム導入されたときの
仕様はどうしましょうか？なんて、質問したらダメなの。無駄なコスト。
質問したところで考慮しなくていいって言われるだろうし

**デフォルトの名無しさん** · 2018/08/16(木) 13:10:21.74

確かに、自分から日本滅亡のスイッチを押す必要は無いな。

**デフォルトの名無しさん** · 2018/08/16(木) 18:20:43.34

得意の運用でカバーでええやん（ﾊﾅﾎｼﾞ

**デフォルトの名無しさん** · 2018/08/16(木) 19:54:25.56

ﾎﾝﾄな低学歴知恵遅れは頭悪すぎて
涙がでてるくるわ。。。

こんだけ懇切丁寧に説明してやってるのに
いまだになにも理解できてないからな

むしろﾛｰｶﾙ時刻で保存するほうが
余計な対応をしてる

普通にひたすらUTCで交換すれば
ｼｽﾃﾑでは問題なんかおきようがない
しかもそっちのほうが自然な作りになるしｼﾝﾌﾟﾙで簡単になるからな

普通につくればﾀｲﾑｿﾞｰﾝ変更すればそのとおりに動く
2時間だろうが3時間だろうが関係ない

かりにﾊﾟﾘのﾀｲﾑｿﾞｰﾝ設定したり、ﾆｭｰﾖｰｸのﾀｲﾑｿﾞｰﾝ設定しても
普通にそのﾀｲﾑｿﾞｰﾝとおりに動くのと同じだからな
低学歴知恵遅れがいちいち余計なことしてｺﾚもできなくしてるだけだからな
そもそもｻﾏｰﾀｲﾑ対応以前の問題

低学歴知恵遅れはやらなくていい余計なことをして
いちいち問題おこしてるﾜｹ

わかる？

**デフォルトの名無しさん** · 2018/08/16(木) 19:59:31.18

まず低学歴知恵遅れは
ｼｽﾃﾑのTZやLOCALEやNLSみたいな環境変数がなんのためにあるかすらも
なんにも理解してないのがよくわかったわ

低学歴知恵遅れが作る程度のｼｽﾃﾑでは
特殊な要件がないかぎり、余計な独自の実装とかもともと不要だからな
使用してるｼｽﾃﾑのもともとある基本機能にまかせるのが一番簡単なのはｱﾀﾘﾏｴ

それやらないでいちいち余計なことして問題おこしてるﾜｹ
※　すべてまともな教育を受けてない白痴に由来する

低学歴知恵遅れにｼｽﾃﾑ設計させると
日本のﾀｲﾑｿﾞｰﾝがかわると太陽の軌道計算までずれるような作りに間違いなくすることが
↓このﾚｽから予見できる
　>>305
日本のﾀｲﾑｿﾞｰﾝがかわっても　太　陽　の　移　動　が　か　わ　る　ﾜ　ｹ　が　な　い　からな
※ ちなみにﾕﾘｳｽ日はPOSIXﾀｲﾑと考え方的には同じ

つまり、低学歴知恵遅れがｼｽﾃﾑを設計すると普通にこんなことがおきる
それが普通だと自信満々でいってるﾜｹだからな
おそろしい。。。

**デフォルトの名無しさん** · 2018/08/16(木) 20:09:31.12

>>310
えとさぁ、だからみんな言ってるじゃん？

サマータイムのことなんか考慮してないで
作ってるから大問題になるって。

サマータイムのことなんか考慮してないっていうのは
そのTZやLOCALEやNLSみたいな環境変数のことなんか
全然見てないってことだよ？

だから大問題になるって言ってるのに

**デフォルトの名無しさん** · 2018/08/16(木) 20:10:28.23

> サマータイムは全体をずらすものなのだから
> サマータイムの始まる前の時間もずれるべきだろ？
> 違うの？

違う。決められた時間（世界的には夜2時が多いらしい）に
1時間時計を進める。言い換えるとその日が23時間になる。
また終わるときは1日が25時間になる。

夜間が短くなるということは、夜間バッチを開始して
処理完了までの猶予時間が1時間減るということ。
もちろん2時間ずらすなら、2時間ずれる

夜中の2時に初めて朝6時までに完了、すなわち4時間の間に
終わらせればよかった処理が、半分のたった2時間になるということ

**デフォルトの名無しさん** · 2018/08/16(木) 20:16:13.22

サマータイムで問題になるのは "今日" のデータを集計する時

当たり前だが日本で今日といったら、JSTの時間で
今日にあたるデータを集計しなければいけない

ではサマータイムに突入する日、この日は23時間しかない
では23時間分のデータを集めるので良いのか？
といったら要件による

今日一日のネットワークトラフィックであれば24時間の方が適切だろう。
だけど今日一日の来場者数であれば、23時間分で良いだろう

すなわち何が適切かを全て見直さなければいけない
それが一番大変

**デフォルトの名無しさん** · 2018/08/16(木) 20:22:58.88

サマータイムがあったからって、UTCで扱えば
問題ないかのように言ってるやつがいるがそれは大間違いだ

なぜなら、UTCは変わらずとも人間の行動が変わるからだ

日本時間朝10時（=UTC 1時）に業務開始だったものが
UTC 0時に業務開始に変わる。

その他すべての日本人の行動が、UTCで見て1時間早くなる

**デフォルトの名無しさん** · 2018/08/16(木) 20:27:32.32

ｵﾚのｴﾚｶﾞﾝﾄなｻﾝﾌﾟﾙｺｰﾄﾞをみればわかるとおり
ｸﾗｲｱﾝﾄ側ではﾀｲﾑｿﾞｰﾝなんか一切気にせずに
ﾀｲﾑｿﾞｰﾝを含めて時刻を処理できることがわかる
しかも超簡単

　↓ｴﾚｶﾞﾝﾄなｻﾝﾌﾟﾙｺｰﾄﾞ
　https://ideone.com/pOGvRt
　　ほとんどｴｸｾﾙでﾏｸﾛ作ってｺﾋﾟって作ったわ
　　こんなもん人間が作るもんじゃない。。。
　①日本時間　https://i.imgur.com/m4EO0sL.png
　②ﾆｭｰﾖｰｸ時間（現在ｻﾏｰﾀｲﾑ中）　https://i.imgur.com/k6IFr2b.png
　③ﾊﾟﾘ時間（現在ｻﾏｰﾀｲﾑ中）　https://i.imgur.com/2vOsBYd.png
　④日本時間（ｻﾏｰﾀｲﾑ）　https://i.imgur.com/iNfxjHn.png

ｻｰﾊﾞｰからPOSIXﾀｲﾑを取得できたら
超簡単なsetSelectLocalTime()を呼びだすだけで
ﾌﾟﾙﾀﾞｳﾝの時刻が復元できることがｺｰﾄﾞから分かる

ｸﾗｲｱﾝﾄは超簡単なgetSelectLocalTime()を呼びだして取得できた値(POSIXﾀｲﾑ)を
ｻｰﾊﾞｰに送信するだけで適切な時刻が送信できることがｺｰﾄﾞから分かる

ｻｰﾊﾞｰ側でもｸﾗｲｱﾝﾄ側の時差なんか一切気にする必要ない
特殊な要件でもないかぎり、そもそもｻｰﾊﾞｰ側で時刻を保存するためにﾀｲﾑｿﾞｰﾝの情報すら取得不要

ｸﾗｲｱﾝﾄ側は、ｸﾗｲｱﾝﾄ側で設定されてるﾀｲﾑｿﾞｰﾝにあわせて表示する（超簡単なsetSelectLocalTime()を呼ぶだけ）だけだからな

※　つまりまともに設計されてるなら作るとき時差すら意識する必要すらない
※　ｺｰﾄﾞの修正すら不要　ｼｽﾃﾑの設定を更新する作業だけの話だからな　そして簡単な試験しておしまい
※　こんなに簡単にできるのは、もともとｼｽﾃﾑが国際化の基本機能を実現してるからだからな
※　そして、それはｸﾗｲｱﾝﾄ側でもｻｰﾊﾞ側でも実現されてる

**デフォルトの名無しさん** · 2018/08/16(木) 20:28:39.04

もしかして低学歴知恵遅れは
ｱﾏｿﾞﾝがいちいち夏時間を設定してないｸﾗｲｱﾝﾄ計算機の時差まで
考慮してくれるとか思ってんの？

もしかして低学歴知恵遅れは
ｸﾗｲｱﾝﾄ計算機に夏時間の対応がなかったら、
ｸﾗｲｱﾝﾄ計算機からｱﾏｿﾞﾝで買い物できなくなるとか思ってんの？

もしかして低学歴知恵遅れは
日本が夏時間になったら
日本からｱﾏｿﾞﾝで買い物できなくなるとか思ってんの？

もしかして低学歴知恵遅れは
日本が夏時間になったら
ｱﾏｿﾞﾝが大混乱するとか思ってんの？

ﾏｼﾞでそんな頭悪いこと思ってんの？

**デフォルトの名無しさん** · 2018/08/16(木) 20:29:17.61

データをUTCで記録していたとしよう。
そうすると人間の行動が1時間早くなることで
例えば何かしらのデータのピーク時間が
UTC 5時からUTC 4時にかわってしまうことになる。

日本的には特に何も変わってないわけだが、
データ上は大きな変化が発生したことになってしまう。

だからデータの種類によっては、サマータイムを考慮しなければならない
データをUTCで記録していたって、システムの仕様変更が発生する例だ

**デフォルトの名無しさん** · 2018/08/16(木) 20:31:09.04

時系列の時間発展のﾃﾞｰﾀでなにをｱﾎなこといってんのｺｲﾂ
著しく知能が低いﾔﾂがいうことはﾎﾝﾄな意味不明なことをいう
ｼｽﾃﾑの問題じゃないからな

**デフォルトの名無しさん** · 2018/08/16(木) 20:31:20.28

>>316
> 日本が夏時間になったら
> ｱﾏｿﾞﾝが大混乱するとか思ってんの？

大混乱は発生しないかもしれないが、多少の混乱は発生するだろうな。
なぜなら商品の売れる時間帯が1時間ずれることになる

時間帯によって売れやすい商品を検索の上位にしていたりすると
売上にも影響は出てくるだろう

**デフォルトの名無しさん** · 2018/08/16(木) 20:32:30.98

それも計算機ｼｽﾃﾑと一切関係ない
板違い

**デフォルトの名無しさん** · 2018/08/16(木) 20:33:01.79

>>320
計算システムは問題なくても
大混乱が起きるって話をしている。

**デフォルトの名無しさん** · 2018/08/16(木) 20:34:48.18

あのなｻﾏｰﾀｲﾑのこと考慮してないで作ってないﾚﾍﾞﾙじゃないﾜｹ
常識的な設計ができてないという話だからな

いちいち日本だけで動けばｲｲように作る必要がそもそもないからな
手間なんかかわらないのに

**デフォルトの名無しさん** · 2018/08/16(木) 20:36:31.56

>>322

> サマータイムは全体をずらすものなのだから
> サマータイムの始まる前の時間もずれるべきだろ？
> 違うの？

違う。決められた時間（世界的には夜2時が多いらしい）に
1時間時計を進める。言い換えるとその日が23時間になる。
また終わるときは1日が25時間になる。

夜間が短くなるということは、夜間バッチを開始して
処理完了までの猶予時間が1時間減るということ。
もちろん2時間ずらすなら、2時間ずれる

夜中の2時に初めて朝6時までに完了、すなわち4時間の間に
終わらせればよかった処理が、半分のたった2時間になるということ

**デフォルトの名無しさん** · 2018/08/16(木) 20:36:34.07

やっぱりな低学歴知恵遅れは
問題の本質がなんにも理解できてない

**デフォルトの名無しさん** · 2018/08/16(木) 20:36:47.75

>>322

サマータイムで問題になるのは "今日" のデータを集計する時

当たり前だが日本で今日といったら、JSTの時間で
今日にあたるデータを集計しなければいけない

ではサマータイムに突入する日、この日は23時間しかない
では23時間分のデータを集めるので良いのか？
といったら要件による

今日一日のネットワークトラフィックであれば24時間の方が適切だろう。
だけど今日一日の来場者数であれば、23時間分で良いだろう

すなわち何が適切かを全て見直さなければいけない
それが一番大変

**デフォルトの名無しさん** · 2018/08/16(木) 20:38:04.48

>>324
問題の本質は、サマータイム導入で
システム改修のために長い検証期間と
大きなコストかかるってこと。

お前は計算システム "だけ" 動いてるから
それで満足していればいいじゃないですかｗ

**デフォルトの名無しさん** · 2018/08/16(木) 20:38:41.01

そんなもん決めの問題だからな
一回決めたらおしまい

低学歴知恵遅れはどうでもいいしょうもない心配しかしないからな
しかもこのｽﾚにいるような低学歴知恵遅れには無関係な話

**デフォルトの名無しさん** · 2018/08/16(木) 20:39:28.04

要件通りに適切に動いてるのに
かえろというならおｶﾈもらうだけだからな

**デフォルトの名無しさん** · 2018/08/16(木) 20:40:29.20

>>327
ほら、言い返せなくなっちゃったｗ

夜間バッチの時間が1時間短くなっても
計算システムは動いてますからねーｗ

ただ朝の営業時間に間に合わなくなるだけですよねーｗ

**デフォルトの名無しさん** · 2018/08/16(木) 20:40:38.60

低学歴知恵遅れのは
開発したほうに間違いなく瑕疵がある

**デフォルトの名無しさん** · 2018/08/16(木) 20:42:17.92

>>328
だから一日が23時間になることで、また世界的に見ると
日本人の行動がUTC時間で1時間早くなることで、
もともとの要件を満たせなくなってないかの検証に
莫大な時間とコストがかかるっていうのが本質的な問題

**デフォルトの名無しさん** · 2018/08/16(木) 20:45:46.88

また同じこと繰り返すのか
>>90>>92>>112>>125>>126
>>127>>128>>130
>>131

もう散々きっちり回答済だからな
もう相手はしない

**デフォルトの名無しさん** · 2018/08/16(木) 20:50:28.01

半角の人、繰返してるって自覚はあるんだ
ずっと同じこと言ってるよね

**デフォルトの名無しさん** · 2018/08/16(木) 20:51:23.19

世にも奇妙な物語～繰り返す人～

**デフォルトの名無しさん** · 2018/08/16(木) 20:52:38.01

ｵﾚはﾋﾟﾝﾎﾟﾝﾄで回答はできるだけﾕﾆｰｸにしてる
SQLでdsitinctつけたような美しい回答だからな
情報価値も高い

**デフォルトの名無しさん** · 2018/08/16(木) 20:57:27.31

このスレは現実にサマータイムに対応が必要なシステムを扱う人間のためのものなので
対応が必要ないと思う人は専用のスレでも立ててそっちで啓蒙してくれないかな

**デフォルトの名無しさん** · 2018/08/16(木) 21:01:49.15

要件に合わせたDateTimePickerみたいなのを自作しちゃってるところは大変だよな
特に終了日の重複時刻を入力された時にそれがUTC換算でどちらを意図した入力なのか判断しようがない
ネットオークションの終了日時の設定とかどうすんだろ

**デフォルトの名無しさん** · 2018/08/16(木) 21:06:27.91

自由に時刻が入力出来るところはもうそれがUTC+9なのかUTC+11なのかをユーザーに明示してもらうか、どちらか決めうちであることを明記して換算してもらうかしかやりようがない気がするな。
結局システム屋だけじゃなくて一般ユーザーも何かしらの対応が必要になる。やっぱ影響でかすぎる。

**デフォルトの名無しさん** · 2018/08/16(木) 21:13:56.51

頭が弱い人は、サマータイムが起きてもUTCで扱っていれば
コンピュータは止まらないから問題ないとか言ってるが
論点はそこじゃないんだよね。

論点はサマータイムが起きた時、それをどのように扱いたいのかという仕様の話
一日が23時間または 25時間の日ができるが、その時間で処理して良いのか
24時間に数値を補正するのか、UTCでみた24時間として
（つまりサマータイムがなかったものとして）処理するのか

世界的に見ると日本人が1時間早く行動するようになるが、
それに世界は合わせてくれるのか。

コンピュータさえ動いていればOKとか言ってるから
現実には大きな問題が発生することに気づけない

**デフォルトの名無しさん** · 2018/08/16(木) 21:22:18.61

アホ「サマータイム導入するかもしれないので、今から対策を考えましょう
2時間になるかもしれません。それを考慮しようと思います。
でもいきなり2時間ずれるとか体内時計がついていかないと思うんですよ。
きっと政府は、1時間ずつ二回に分けてずらすとか言うと思うんですよね。
だからスプリングタイム、サマータイム、そして秋にサマータイムの終わり、
冬にスプリングタイムの終わりってやると思うんですよね？
今からそれに備えて対応したいんで金ください
YAGNIなんて敵ですよ。予めいろんな事態に備えないと。金ください」

**デフォルトの名無しさん** · 2018/08/16(木) 22:22:38.80

>>333
いや、タイムゾーンとサマータイムが区別ができていなかったのが、
一応ぐぐって調べた痕跡はある。

**デフォルトの名無しさん** · 2018/08/16(木) 22:30:09.42

サマータイム開始日と終了日が明確なら対応は簡単じゃないの？
始業時間をちょっと変えてバンって感じで
勤怠プログラム作ったこと無いから平気で言えるけど

**デフォルトの名無しさん** · 2018/08/16(木) 22:37:42.90

>>342
まんまブラック顧客が言いそうな暴論でワロタ

**デフォルトの名無しさん** · 2018/08/16(木) 22:45:35.55

>>342
まず大抵の国内向け勤怠管理はJST決めうちで作ってあるはずだから、ここを何かしらの方法で直さなくちゃいけない。
でもってそれを直すことで副作用がないかどうかテストをしなくちゃいけない。
これでシステムの内部的には勤務時間を正確に計算できるようになったとして、
次にこれを画面に表示したり印刷したりする場合にどう表現するか考えて、それを実装しなくちゃいけない。
サマータイム期間内と期間外をまたぐ勤務時間があった時に、ただ09/15 03:00とだけ書いてあったらそれが1度目の3時なのか2度目の3時なのかわからない、など対処すべきことは沢山ある。

**デフォルトの名無しさん** · 2018/08/16(木) 22:51:04.03

>>342
プログラムを直すのなんて簡単なんだよ
問題は、例えば夜勤の人がタイムゾーンをまたぐとき
その日は勤務時間が短くていいのか、短いとしたら給料も減らしていいのか等を決めないといけないだろ？
そういうことを考えてない上から改修しろと言われてしまうと
意見伺いや仲裁も全部SEの責任になって大変面倒なことになる
当然勝手に決めたら怒られる

**デフォルトの名無しさん** · 2018/08/16(木) 23:26:21.91

まだ低学歴知恵遅れそんなこといってんのか
ｼｽﾃﾑではｻﾏｰﾀｲﾑもﾀｲﾑｿﾞｰﾝも扱い方も管理のしかた同じなのに

**デフォルトの名無しさん** · 2018/08/16(木) 23:27:03.14

低学歴底辺の負けず嫌いは異常だからな
ﾎﾝﾄなすぐに分かる

**デフォルトの名無しさん** · 2018/08/16(木) 23:28:50.93

なんどもいうようだが
まずな低学歴底辺の知恵遅れは
自分がいかにｺﾞﾐでｸｽﾞな存在なのか自覚する必要がある

ﾎﾝﾄなｺﾞﾐｸｽﾞのﾁﾝｶｽだからな

わかってんの？

**デフォルトの名無しさん** · 2018/08/17(金) 00:50:04.46

半角君のいないスレが必要だな

**デフォルトの名無しさん** · 2018/08/17(金) 01:49:18.83

>>346
システムの動作に依存するパラメータが法令にある時刻で(労基法の深夜割増は22時からとか)、
そのパラメータがサマータイム例外規定とかで一部の工場は24時からとかになったらどうするのって話なわけで
UTCで管理してれば2時間のズレは表示上の問題でしかない、という話以上の問題がそこにはあるだろう

法令の時刻をDST実施中にUTC+9で読めばいいのかUTC+11で読めばいいのか現時点ではわからないのだから
例えば深夜割増の開始判定時刻は現状では365日JSTの場合しかないからUTCの13時と決まっているけれど、
今後の行政の動き次第では開始判定時刻がUTCの11時になったり、UTCの13時になったりとケースバイケースなわけで、
そんなの事前にシステム設計側で把握しておくことは不可能だっただろうって話だ。
そもそもJSTのローカルタイムのままシステムを動かすのか、JSTで表現されたローカルタイムをJDTとして再解釈して
システムを動かすのかもケースバイケースなわけで、スタンドアロンなシステムなら単なる決めの問題だが、
連携して動いているシステムでこの方針を統一できない場合もあってその場合はテストを相当にやりなおさなくちゃいけないだろう
ただそれを説明してお客さんが納得してくれるとも限らないからタイムゾーンを変えるなんてことを本当にやるのか？と皆思ってるわけで

**デフォルトの名無しさん** · 2018/08/17(金) 04:35:47.51

簡単にまとめると、サマータイムが一時間だとして

1. サマータイム開始時・・・一日が23時間になる
2. サマータイム終了時・・・一日が25時間になる
3. サマータイム中・・・世界基準で考えると日本が一時間早く動き出す
4. サマータイム導入前に記録されたデータは上記に当てはまらない
5. サマータイム導入後に撤回されたら未来の予定に調整が必要

ってところかな。5は撤回されなければ対応する必要はないけど
なんか導入してダメだったらやめればいいだけって考えてそうだから、
やめるのにもコストが掛かりますよってことで書いた

**デフォルトの名無しさん** · 2018/08/17(金) 05:02:22.25

通信手段を持たない組込機器とか、誰がアップデートするの？

**デフォルトの名無しさん** · 2018/08/17(金) 05:36:59.52

>>351
そう。試験導入とか、2年で一旦やめるとか、アホの極み。

**デフォルトの名無しさん** · 2018/08/17(金) 06:05:59.00

半角くんってエンジニアじゃないよな。
仮にシステムに関わる人間だとしても、渡された詳細設計書通りにコードを書くことしか出来なさそう。
見えてる視野がそのレベルの広さしかないんだもん。

**デフォルトの名無しさん** · 2018/08/17(金) 10:42:27.67

ハンコテの域に入ってるし多分かなりのやばいやつ

**デフォルトの名無しさん** · 2018/08/17(金) 11:58:36.33

web屋とかなら半角くんも間違っちゃいないけどな
工場のシステムとか他社システムが絡むもんの入れ替えとか考えたくもないわ

**デフォルトの名無しさん** · 2018/08/17(金) 12:05:26.03

>>356
Web屋から見ても何から何まで間違っとるわw
静的なhtmlのサイトでちょっとjQueryでアニメーションつけてるくらいなら間違ってないだろうけどw

**デフォルトの名無しさん** · 2018/08/17(金) 13:33:52.00

>>350
やるなら法定時刻はUTCで定めてくれると、逆にありがたいけどね。
ただ海外、大陸をみると、現地時刻は幾つもある。
西海岸時間、中央時間、東海岸時間、あとはあるかはしらんが、ハワイのローカルタイム。
イギリスでもあんま知られていないようだが、太平洋に領地を持っていたりした。
数十年前なら香港なんかがある。

さて、そういう幾つものローカルタイムを文化として持った国は、法定時刻をどのように扱っているのか？
法的文書は、UTCで記録するのが、合理と思うが、タイムスタンプには、必ず「その時点の時差」を記録させる運用でないかと思う。

で、夏時間対応は、この時差記録機能の追加が柱になるんでないかと、個人的には考えている。
まあ、決めるのはじみんとー

**デフォルトの名無しさん** · 2018/08/17(金) 13:46:07.38

>>344
時差、タイムゾーンは、相対的な時刻の表示を替えること。
生活習慣上の時間軸で定められた時刻であれば、内規、おれルールを替える必要はない。
明日から9時が2時間早まるといって、わざわざルールを夏時間無適用の時刻で定め直す余計な手間になるから、そういう影響は少ないかと。

**デフォルトの名無しさん** · 2018/08/17(金) 13:49:03.56

何にしろ誰得？みたいな話。
政治ねたを引用すれば、ある新聞社は、夏時間導入に大賛成したけど、明るい内に呑みに行けないからと記者が厭がって廃止に世論を誘導して廃止させたとか、
そーすは不祥事のあと落ち着いたのに、やめもしないアイツ

**デフォルトの名無しさん** · 2018/08/17(金) 21:29:44.07

半角バカが真正バカなのはよくわかった。

**デフォルトの名無しさん** · 2018/08/17(金) 21:37:38.89

半角あばれる君、逃走して文字コードスレで暴動中

**デフォルトの名無しさん** · 2018/08/17(金) 21:39:41.45

ｵﾚがこのｽﾚにこなくてさみしいの？
はっきりいってなもうこのｽﾚはもう諦めた
計算機ｼｽﾃﾑと無関係な話しかしてないからな

ﾊﾞｶは問題のきりわけができないからな

あまりに頭悪いのしかいないからな

**デフォルトの名無しさん** · 2018/08/17(金) 21:41:20.85

エクセルがサマータイムに対応してないから
大変なことになるって騒がれてるな

**デフォルトの名無しさん** · 2018/08/17(金) 21:49:52.84

>>364
あれ速攻で否定されてたろ
そもそもExcelってアメリカ産だぞ

**デフォルトの名無しさん** · 2018/08/17(金) 21:51:12.35

>>362
今週1番嬉しいニュースだ

**デフォルトの名無しさん** · 2018/08/17(金) 22:15:32.77

な低学歴知恵遅れは願望のﾃﾞﾏばっかり流す
ｴｸｾﾙ単体ではおもいっきり対応してる

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の地域設定により表示形式が変化することを表しています。
　例えば、海外のユーザーとデータを共有する場合にこの形式を用いると、それぞれの地域で使われている日付形式に自動的に変更されます。

低学歴底辺知恵遅れは道具の使い方も分かってない
自分が使い方をしらないもしくは使えなければ対応できてないということになるからな

**デフォルトの名無しさん** · 2018/08/17(金) 22:20:28.04

　↓ｺﾚ(>>315)とまったく同じだからな
　①日本時間　https://i.imgur.com/m4EO0sL.png
　②ﾆｭｰﾖｰｸ時間（現在ｻﾏｰﾀｲﾑ中）　https://i.imgur.com/k6IFr2b.png
　③ﾊﾟﾘ時間（現在ｻﾏｰﾀｲﾑ中）　https://i.imgur.com/2vOsBYd.png
　④日本時間（ｻﾏｰﾀｲﾑ）　https://i.imgur.com/iNfxjHn.png

**デフォルトの名無しさん** · 2018/08/17(金) 23:01:03.69

半角ループが始まりました

**デフォルトの名無しさん** · 2018/08/17(金) 23:26:57.87

>>364
二時間ずらす森タイムに対応してんの？
古いVBAのマクロは改修しなくてもいいのね？