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

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

はいどうぞ

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

>>588
それじゃダメじゃん。
UTC+11になってる期間に、サマータイム終了後のUTC+9の時刻の入力をすることは当然ありうるんだから。
今のシステムがUTC+11だからといって入力者がそれを意図してるかは分からない。

もっと言えばアップデートが提供されず、タイムゾーンがUTC+9で固定されたままのAndroidユーザーが入力してくるケースとかもあるわけで。

クライアントのロケールと入力者の意図は必ずしも一致しない。

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

ローカルタイムだとサマータイム終了日の午前2時は2回やってくるんだから、
単に02:00とだけ入力された場合、それがUTC換算でどちらを意図した時刻なのかは自明にはなり得ない。

**デフォルトの名無しさん** · 2018/08/22(水) 13:35:05.80

>>585
ん？コンピュータを使うのは人間なんだから
人間にわせたほうが良いでしょ。
コンピュータに合わせて2進数使うとかおかしいし
なによりコンピュータは人間が楽をするために作られた道具

**デフォルトの名無しさん** · 2018/08/22(水) 17:03:34.92

ローカルタイムには、存在しない日時(サマータイム開始直後)もあったりすんだよね

**デフォルトの名無しさん** · 2018/08/22(水) 17:10:14.01

>>591
表示部にだけ使うっていってんだろ
文盲かよ

**デフォルトの名無しさん** · 2018/08/22(水) 17:11:07.78

>>591
半角先生もそうだけど、コンピュータの中のことしか考えてない奴が一定数いるんだよな
それを使う人間と、その人間がやりたいことが出来るかという視点がスッポリ抜け落ちてる

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

>>589
入力したローカルタイムをunixtimeに変換するシステムの関数がその時刻がサマータイムか判定すればいい気がするけど。
２番目のことについてはその通りでたしかにその問題は残る
古いのを使ってるくせにまともな動作を期待するなって言っとけばいい

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

>>590
その問題も残る
人間形式を複雑にすればするほど入力も複雑になる当たり前の摂理

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

>>589-590
OSの地域設定とTZデータベースがちゃんとしてれば
未来の時間を入力されたところで、その日がサマータイム対象かどうかを考慮した変換してくれるはず……
でも後でサマータイムが変更になったらまあ発狂せざるを得ないわな
(二年だけといっていたなあれは嘘だ、とか普通にありそうだし)

やっぱり入力時に意図されたであろう時差もペアで記録しておくのが現実的かね

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

>>594
だから人間とのインターフェースは人間寄りにするって言ってんだろ
計算機が内部では2進数で扱うが表示部は10進数にするのと同じだよ

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

傍目にも>>583は言葉足らずに思えるので、「やりたいこと」を当ててみるか

毎日定時(ローカルタイム)に行う処理があって、加えて特定の日付でそれに依存した追加処理をしたい
将来サマータイムが変更されても問題ないように作りたいのでローカルタイムで記録することに意味がある、とかかな
現実には結構多いケースかもしれない

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

>>595の後半は強引すぎた
サマータイムに対応済みか条件文で判定できるようにして対応してなかったら適当な処理をする

**デフォルトの名無しさん** · 2018/08/22(水) 17:43:57.06

>>597
発狂はしない
unixtimeで保存するから人間形式の仕様が変わっても関係無い

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

>>599
なくね？全部unixtimeで処理・保存すればいい気がするけど
かんがえるのめんどいからなんか具体例だしてみ

**デフォルトの名無しさん** · 2018/08/22(水) 17:47:57.23

>>595
Androidの場合は大して古くなくてもアップデートが提供されないからなかなか切り捨てにくいよなあ
どうすっぺかねほんと

**デフォルトの名無しさん** · 2018/08/22(水) 17:49:50.56

>>603
>>600

**デフォルトの名無しさん** · 2018/08/22(水) 17:53:49.16

>>604
すまん見逃してた。そうね、未対応なクライアントに関しては強制的にJSTとみなすのが現実的かね。

**デフォルトの名無しさん** · 2018/08/22(水) 17:54:47.13

>>601
いやいや、入力した人間の意図なんてわかんないだろ
外国の放送を録画したいとかあるかもしれないし

**デフォルトの名無しさん** · 2018/08/22(水) 17:57:31.38

>>606
そんなのサマータイム以前の時差の問題だろ
今現在そういうサービスとかでどういう処理してるか考えれば問題起こらないことわかると思うけど

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

>>602
例もなにもそのまんま、5年後の正午(ローカル)になんかしたいけどサマータイム本当に2年で終わるのかなあ心配だなあ
どう転んでもいいようにローカルタイムで保存しとけ、って発想で作られるシステムは出てくるはず

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

複雑怪奇な人間フォーマットのままで内部処理するシステムが悪
単純で全世界共通で絶対的なunixtimeに正規化してから処理するべきだと思うけど

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

>>608
サマータイムが終わろうが始まろうがunixtimeで処理すれば何の影響もなくね？

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

>>607
未来の時刻を入力後にサマータイムのルール自体が変更になった、という仮定の話なのはOK？
unixtimeのみで記録していると国内時間を意図していた時にずれるし
時差込みで記録していても海外時間を意図していた時にずれる
ユーザーの意図なんてわかんないだろ

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

>>611
なるほど

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

>>593
> 表示部にだけ使うっていってんだろ

翻訳じゃないんだから、サマータイムは表示だけの問題じゃないぞ
具体的に言えば、サマータイムに入る当日
ローカルタイムの1日は23時間になる。
UTCは変わらず24時間にもかかわらずだ。
そしてサマータイムが終わる日、その日は25時間になる
表示だけの問題じゃない。一日の長さが変わるんだよ

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

>>610
> サマータイムが終わろうが始まろうがunixtimeで処理すれば何の影響もなくね？

unixtimeで処理したら、一日の長さが23時間または 25時間に
なる場合に対応できない

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

はぁ...

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

つらい

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

具体的に言うと、サマータイム開始の日が夜勤の場合、労働時間が1時間短くなる。
その当日だけ、1時間分給料を減らさなければならない。
逆にサマータイムが終わる人は労働時間を1時間増やすことになる

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

サマータイムで切り替わった日の朝は1時間早くこなければいけない
ローカルタイムの出勤時間は何も変わらないが、
unixtimeで扱っている場合は、一時間出勤時間を変更しなければいけない

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

思考停止してる

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

>>619
いいからなにか言い返せよｗ
1時間が23時間になる場合にどうやって対処しろと？

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

夜間バッチの実行にも支障が出るからな。
夜間が1時間短くなるということは、1時間早く実行しなければ朝まで間に合わないかもしれない。
だが、1時間早く実行しようとしたら、まだ業務中かもしれない。
1時間早く処理するために、プログラムの見直しやサーバー増強が必要になるかもしれない
unixtimeで扱っていると、サマータイムがないのと同じ時間で処理されてしまう
つまりunixtimeはサマータイムに対応していないも同然

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

unixtimeのどこにいても変わらないという性質は
日本のサマータイムを無視するという意味になるからな。
サマータイムに対応するにはunixtimeで処理してはダメだということだ

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

>>620
虐めんなw
考え直せるなんて5chでの議論相手としては相当に上等だぞ

**デフォルトの名無しさん** · 2018/08/22(水) 19:00:02.56

>>617
開始時間と終了時間をUTCで記録すればなんの問題もないね

**デフォルトの名無しさん** · 2018/08/22(水) 19:03:51.26

朝9時になったぞ。なんで機械は動いてないんだ！？
unixtime処理してますので、後一時間後には動きます
時計は9時を指してるぞ？どういうことだ？

だからーそれは表示がそうなってるだけなんだってー
人間のほうが一時間はやく起きてきたんでしょー
コンピュータは正確なの

**デフォルトの名無しさん** · 2018/08/22(水) 19:06:16.06

>>624
UTCで記録したらサマータイム中でも
一時間早くならないじゃんｗ

**デフォルトの名無しさん** · 2018/08/22(水) 19:07:42.05

結局就業時間がUTC基準で数時間ズレる事実はどうにもならないのね

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

サマータイムがないUTCの時間で行動しましょうっていうのは
結局サマータイム批判ではないか

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

結局の所、本質は日本人が1時間早く行動しましょうっていうことだからね
時間がずれるのではなく、人間の行動時間がずれる
システムはその人間の時間に合わせないといけない

ローカルタイムを使っていれば、勝手に時間を合わせてくれるけど
UTCを使っていると、時間を合わせてくれない。
だから別途サマータイムへの対応の修正が必要になる。

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

>>618
日跨ぎ処理なんかに影響が出そうだよな

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

相変わらず低学歴知恵遅れは頭悪いわ
低学歴知恵遅れはｸｿ頭悪いからちょっとした工夫すらできない
で、ｸｿ頭悪いｼｽﾃﾑ作るﾜｹ

例えば年間の営業時間ﾃﾞｰﾀﾍﾞｰｽがある
ｺｲﾂはﾛｰｶﾙﾀｲﾑで保存する（念のため一緒にUTCの通秒値も保存するのがﾍﾞｽﾄ）
ﾀｲﾑｿﾞｰﾝがかわっても固定だ
で、その場合でも必ずそのﾛｰｶﾙﾀｲﾑからその時点のUTCの通秒値に変換してから処理する

考え方は簡単
低学歴知恵遅れでなければ
こんなことすぐに分かるし気付くからな

たとえば計算機を日本からｱﾒﾘｶへもっていって
計算機が提供するｻｰﾋﾞｽは同じだとする

しかし計算機はｱﾒﾘｶにあるから
とりあえずｱﾒﾘｶのﾀｲﾑｿﾞｰﾝにあわせる

そのときｱﾒﾘｶの時刻になると困る部分だけ
ﾛｰｶﾙﾀｲﾑで保存や処理をすればｲｲﾜｹだからな
それ以外はすべてUTCでいい

ともかくな低学歴知恵遅れのｸｿﾆｰﾄと底辺ﾄﾞｶﾀの知能は低すぎるﾜｹ
まず出発点の考え方が間違ってるからな

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

>>631
なるほど

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

>>611
>>597の通り、入力時に意図した機械内部表現から人間フォーマットに変換する関数を併記しないと正しくデコードできないな

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

>>613
ローカルタイム形式の時刻表現は単純に差分を取るだけでは時間を計算できない表現方法だからでは？

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

>>614
＞一日の長さが23時間または 25時間になる
人間フォーマット時刻で単純な差分で計算したら見かけ上はそう見えるだけで絶対的な時間はそんなことならないのでは？

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

>>626
ローカルタイムからunixtimeに変換するときにちゃんと時間がずれることね？

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

>>621
終了時刻のunixtimeから処理時間を引いたunixtime形式の開始時間をローカルタイム形式で入力すればいいのでは？　そもそもローカルタイムは単純な加減算で時間の計算はできない表現方法だし。

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

>>622
ローカルタイムの加減算で時間を計算したり足したりするから問題が起きるので？
そもそもローカルタイム形式は単純な減算では時間を計算できない表現方法だし。
時間の計算はunixtimeでやるべきなのでは？

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

>>627
ローカルタイム形式では時間の計算はできないからでは？

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

保存はunixtimeからローカルタイムへのエンコード関数を併記した形式で、計算や処理はunixtimeで、表示は適切なエンコード関数でローカルタイムにエンコードされた時刻表現でおこなうようにシステムを作るべきでは？

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

先生はサハリンで分身の術を身に付けました

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

>>631
先生、UTCで保存してても地域時間の5時までに終わらせなければいけない処理を
地域時間の4時にスケジュールしてたら調整が必要になりますよね
https://light.dotup.org/uploda/light.dotup.org543318.png

地域時間に依存してる処理が多いのがサマータイムの対応で大変なところですよね

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

具体的には>>611の場合には
未来で開始された定期実行サービスは保存されたunixtimeとエンコード関数のペアを取り出したあと、unixtimeを取り出されたエンコード関数でローカルタイムにエンコードした後、未来の時点でのエンコード関数の逆関数でローカルタイムをunixtimeでデコードすればいい

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

unixtimeにデコード

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

UTCでスケジューリングしつつ、サマータイムが導入されたら
時間をずらす作業が必要ですね

UTC使ってるから問題ないんだとはならないですよね
なぜならば業務は地域時間に依存してるから

UTCを使っていても地域時間に合うようにスケジューリングを調整しないといけない

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

簡単なバッチのスケジューリングだけでも面倒に思えてきますね

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

>>645
目的の時刻の表現方法がローカルタイムならスケジューリングの入力もローカルタイムにするべきじゃね？

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

人間はローカルタイムしか入力しない

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

内部で適切な処理をしてunixtimeに変換する

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

人間はなにも考えずに時計をみて入力すればいい

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

その「適切な処理」が9時間なのか11時間なのかは入力者に明示してもらわない限り分からないって、上で言われてたやん

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

>>651
システムのロケールと入力された時刻の日付で人間の手を借りずにデコードできることね？
終了時にある一時間が重複するのが唯一の弊害

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

>>652
唯一だけど割と致命的だわね

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

>>653
複雑な表現方法には複雑な入力方法が付きまとうのは当然の摂理
それをちゃんとやれば何の問題もない
それで人間フォーマットの自由度が無限大になる

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

>>647
スケジューリングが地域時間に依存するとたとえば
地域時間の2:00に実行する処理はサマータイム突入時に処理されなくて
サマータイム脱出時に2回実行されちゃうの
https://light.dotup.org/uploda/light.dotup.org543319.png

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

>>650
2時間サマータイム非対応で1時間ずれた時計使っていたらどうする？

シンプルにやるならシステムはUTCで完結させて
入力者とか部屋の壁に換算表貼っておく

履歴データの洗い替えがそれでも面倒だよな

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

何だ、いつの間にか先生みたいなのが1人増えたのか。
◯◯になっていれば問題ないと言われても、そりゃそうですね、としか言えんわ。
現実にはそうなってないシステムが大半だから問題なんだっての。

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

>>657
サマータイムは悪くない
悪いのは不正な方法で構築されたシステム
適切にローカルタイムとunixtimeを使い分けて作り上げればサマータイム何かでは動じない&ユーザーを極端に煩わすことないシステムを作れる
と言いたいだけ

だからやるべきは不正な方法で構築されたシステムを一新することのただ一点
ユーザーがサマータイムを意識して極端にややこしい操作を強いられるというような問題は本来起こらないからサマータイム導入の不便はそこではない

**デフォルトの名無しさん** · 2018/08/22(水) 23:00:30.08

この人なんかアカデミックセクターの人っぽい
思考が完全に実務から乖離してる

**デフォルトの名無しさん** · 2018/08/22(水) 23:01:19.41

>>659
それ僕も思いました

生活は地域時間に依存してて
業務は生活に依存してて
システムは業務に依存してる

システム => 業務 => 生活 => 地域時間 => タイムゾーン => UTC
みたいな

**デフォルトの名無しさん** · 2018/08/22(水) 23:03:56.48

完成された理論をモチベーションにして地道な作業をするべきといいたいのかもしれない
そのためには数学的に思考を整理するべきだと思う

**デフォルトの名無しさん** · 2018/08/22(水) 23:04:21.85

半角君といい、言ってることがただの理想論だからな

**デフォルトの名無しさん** · 2018/08/22(水) 23:05:27.98

>>662
目を向けるべきは実際に行われる地道な作業ではなく数学的根拠だとおもう

**デフォルトの名無しさん** · 2018/08/22(水) 23:06:02.00

だめだこりゃ

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

根拠がはっきりとあるのに作業がめんどくさいとかいうひくい次元の議論を延々とする価値はないとおもう

**デフォルトの名無しさん** · 2018/08/22(水) 23:09:54.12

マジで学生っぽい
社会性なさそうだからポスドクとかかもしれない

**デフォルトの名無しさん** · 2018/08/22(水) 23:10:09.19

努力するば幸せになるという絶対的な法則があったとして、でも努力がめんどくさいよぉとか延々に呟くことは最適解ではないとおもう

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

作業に手間がかかることはサマータイムを実施しない方が良いことの理由になると思うけどね

サマータイムを導入する事によって得られるものはなんですか
サマータイムを導入する事によって生まれる負担はどれだけですか

それらを秤にかけて割に合わないと思われることを面倒くさいと表現してるだけで
そういうところに引っかかるのってなんだか数学者らしくないなって思った

> 努力がめんどくさいよぉとか延々に呟くことは最適解ではない

これはストローマン論法、別名バカの論法と呼ばれるものだから
数学的な思考が大事だと言うならあまりやらない方が・・・

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

>>667
努力云々は置いといて、本来必要のない出費(社会人の時間はイコール金だ)を
迫られる人災のようなもんだからみんなやる気ないんだよ
勉強などの投資と異なり何をどうやっても利益には繋がらんしな
そして無事乗り切ったとしても裏方を知らないやつには大したことなかったのに大騒ぎしやがってと言われるだけなのは
2000年問題で経験済みでもある

あと、夜行便到着しない問題は物理的に解決しようがない

**デフォルトの名無しさん** · 2018/08/22(水) 23:24:04.33

ちなみにマジで学生
感覚的に思考回路50%活性状態で考えて書いてきたから数学的な根拠に基づいた最適システムを達成するための案として不完全だと思う

**デフォルトの名無しさん** · 2018/08/22(水) 23:26:09.01

>>670
数学科？

**デフォルトの名無しさん** · 2018/08/22(水) 23:26:29.43

>>668
>>669
なるほど
このスレのプログラマは数学的最適と経済的利益を天秤にかけてたのか

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

>>671
何科とかもない全部やる工業大学の凡人だから数学的根拠とか言ってるけど全部なんちゃって数学

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

>>665
サマータイムやらなければ良い
という根本的解決法がありますよ
抜本的解決さ

**デフォルトの名無しさん** · 2018/08/22(水) 23:43:02.65

>>672
> このスレのプログラマは数学的最適と経済的利益を天秤にかけてたのか

そんなこと言ってないよ、君の早合点だよ

森元さんは数学的最適(?)だからサマータイム導入するぞおらー
と声がけしてるわけではないっしょ、今年の夏は暑かったねオリンピックの年も
死ぬほど暑いだろうからサマータイム導入したらどうかねーという趣旨でしょ

サマータイム導入の目的はオリンピックの猛暑対策
それと経済的な損失を秤にかけて、割に合わんよねってこと

数学的最適については意味がわからない

**デフォルトの名無しさん** · 2018/08/22(水) 23:47:13.50

>>673
数学って印象は欠片もなかった、どちらかというと文学って思った

**デフォルトの名無しさん** · 2018/08/22(水) 23:58:12.57

サマータイム漱石

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

> 感覚的に思考回路50%活性状態

なんだろう、不思議と胸が締め付けられる

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

邪気眼が完全覚醒しちゃいそう

**デフォルトの名無しさん** · 2018/08/23(木) 03:37:26.07

>>675
> 森元さんは数学的最適(?)だからサマータイム導入するぞおらー
> と声がけしてるわけではないっしょ、今年の夏は暑かったねオリンピックの年も
> 死ぬほど暑いだろうからサマータイム導入したらどうかねーという趣旨でしょ

そんなわけないだろｗ
サマータイム導入するとその対応で仕事が増える
金を出す方は大変だが、金をもらう方の会社と裏でつながってるんだろ
結局は箱物事業と一緒、無駄なものを作って裏金をもらってる

暑さ対策なら1時間早く起きればいい話。早起き運動をしましょうでおわる
それぐらい思いつかないバカなわけ無いでしょ？

**デフォルトの名無しさん** · 2018/08/23(木) 05:38:17.55

対応できない所が沢山有る
それが解るのにサマータイムを勧めるのはただのアホです

**デフォルトの名無しさん** · 2018/08/23(木) 05:54:30.27

数学的というより思想や哲学の類の非実用的な思考だと思ってたけどw

**デフォルトの名無しさん** · 2018/08/23(木) 06:53:50.86

>>676
本人は論理的厳格さとして数学的だと言ってるのかもしれないけど、端から見ればただの机上の空論で、現実の様々な問題点を無視して事象を意図的に単純化して考えていて、悪い意味での数学っぽさはあったように思う。少なくとも工学、エンジニアリングの議論ではない。

**デフォルトの名無しさん** · 2018/08/23(木) 07:06:56.45

単純化っていうかUTCはサマータイムがないから
サマータイムを無視すれば問題は起きないって言ってるだけだからな。

仮にJSTが+9じゃなくて+0、つまりUTCになったとして
じゃあUTCにサマータイムを導入されても、サマータイム無視して
問題ないかっていうと当然そんなわけないわけで

サマータイム無視していいなら、JSTであつかっていても
サマータイム無視すればいいはずなんだよ。

**デフォルトの名無しさん** · 2018/08/23(木) 07:13:28.14

ﾛｰｶﾙﾀｲﾑでも重なることなんかあるﾜｹがないからな
それは低学歴知恵遅れが頭悪い表示にしてるのがﾜﾙｲ

※　低学歴知恵遅れの自分の頭の悪さを棚にあがて
※　低学歴知恵遅れがおかしいおかしいと騒いでるﾜｹ
※　おかしい低学歴知恵遅れのｵﾂﾑというのがまだ理解できてない

ﾛｰｶﾙﾀｲﾑに空白ができることも重複することもあるﾜｹがないからな
ｺﾚもこのｽﾚの初期の段階ですでに説明済>>115
入力でも同じことだからな

つまりﾀｲﾑｿﾞｰﾝが保存されてなかったり、
表示されてなかったりする数字の羅列は
ﾛｰｶﾙ時刻ですらない、ただの数字の羅列（どこの時刻かすら分からない）
ﾛｰｶﾙ時刻の情報がそもそも欠落してるﾜｹだからな、もともとﾛｰｶﾙ時刻と呼べるｼﾛﾓﾉじゃない

低学歴知恵遅れは今度は入力の場合がどうこうと騒いでるが
ｺﾚでも問題なんかおきようがないからな
すでに説明してるとおり
すべて低学歴知恵遅れの知能の低さの問題

**デフォルトの名無しさん** · 2018/08/23(木) 07:15:29.03

　▽[02]：▽[00]　JST UTC+0900

と表示れてれば混乱なんかおきようがない

たとえばNYは夏時間
　▽[02]：▽[00]　EDT UTC-0400

冬時間になればこうなる
　▽[02]：▽[00]　EST UTC-0500

この例ならもともと日付なんか入ってないからな
なんらかのﾀｲﾑｿﾞｰﾝを意図した入力ｲﾝﾀｰﾌｪｰｽになる
※ 入力するやつは特定のﾀｲﾑｿﾞｰﾝを前提に入力してるﾜｹだからな

当然ﾀｲﾑｿﾞｰﾝを選択できるｲﾝﾀｰﾌｪｰｽもｱﾘだ
　▽|EDT UTC-0400|
　　|EST UTC-0500|

ここまで理解力が低いことから
軽度の池沼と推認される

海外ではなんの問題もなく普通に夏時間が運用されてるからな
問題はすべて低学歴知恵遅れのｵﾂﾑの問題

それ以外なにもない

**デフォルトの名無しさん** · 2018/08/23(木) 07:18:43.30

>>680
サマータイムの対応で仕事は増えるだろうけど
企業の利益につながるとは思えないだよね

サマータイム対策補助金とか作って
その金を回してもらうってのはあるかもしれない
政府が金を出して政治家の懐に入るODA方式

金もらうのが目的なら表に出てきてワシがやりましたとは
言わないんじゃないかなと

橋龍や野田が増税したように国の制度を変えることは
政治家の名誉欲を刺激するんじゃないかなと
名誉欲のためにサマータイム導入されたらかなわんけどね

オリンピックの競技時間は地域時間のこの時間でないと
いけませんって言うのが決まってたら早起き運動ではダメかもしれない
そうだとしてもサマータイム導入するよりもオリンピック委員会と交渉するのが先だね

日本の運動会は秋にやるのが通例なのでオリンピックも秋にやったら良いと思う
オリンピックは開催国の文化に合わせてやるってのも有りだと思うけどね
歴史があるとそう簡単に変えられないだろうけど
森元さんにはそういう方向でのリーダシップを期待したい

頑張れ森元さん
5chは森元さんを応援しています

**デフォルトの名無しさん** · 2018/08/23(木) 07:24:36.95

政府はｶﾈなんか一銭もだすﾜｹがない
低学歴知恵遅れがただ働きで治さないといけない
ほぼすべてが低学歴知恵遅れの瑕疵責任

低学歴知恵遅れに由来しない軽微な作業は
それはすべてﾕｰｻﾞｰの自己負担
低学歴知恵遅れなｼｽﾃﾑでもないかぎり大したｶﾈなんかかかるﾜｹがないからな