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

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

はいどうぞ

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

UTCに変換すれば良い
UTCから変換すればいいというのは
その通りなんだけど銀行潰れるとわかってて金預ける人がいないように
今現在ローカルタイムに依存してしまってるものがあるでしょうと

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

ﾆｭｰﾖｰｸはいま
夏時間でﾀｲﾑｿﾞｰﾝはEDT
夏時間が終われﾀｲﾑｿﾞｰﾝはESTになる

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

>>551
それで何が解決するん？
サマータイムの問題は何かしら？

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

むしろなんの問題もおきないことが証明されてる
低学歴知恵遅れが
低学歴知恵遅れな作りにしなければな

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

そもそも解決すべき問題がない

意味不明なことを問題だと思いたい低学歴知恵遅れのｵﾂﾑの問題

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

>>556
ではサマータイムの対応で先生にできることは
何もないのでご卒業おめでとうございます

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

>>552
ローカルタイムは不連続関数なのに連続関数と仮定して作られたシステム？

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

>>558
誰お前、先生に言いつけるぞ

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

先生、スレのOBとしてやっちゃってください

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

>>551
それだと例えば5月のファイルのタイムスタンプもサハリン時間で表示されてしまう

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

なんの問題もない

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

むしろ全体で連続してる

すべてUTCを基準にした
ｻﾊﾘﾝ時間基準
すべて夏時間基準(JDT)になってる
なにも間違ってない

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

一方そのころサハリンでは

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

他所の国のタイムゾーンに依存してホンマに大丈夫なんでっか？

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

タイムゾーンの使い方を間違えてると思うの
日本マイクロソフトがきっとなんとかしてくれるよ

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

知恵遅れが知恵遅れな作りにしてなければ
なんの問題も起きない

ﾀｲﾑｿﾞｰﾝなんかただの相対値の定義だからな

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

ﾆｭｰﾖｰｸはいま
夏時間でﾀｲﾑｿﾞｰﾝはEDT
夏時間が終われﾀｲﾑｿﾞｰﾝはESTになる

このとおり夏時間は
ﾀｲﾑｿﾞｰﾝを切り替えてるだけだからな

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

>>567
サハリンのタイムゾーンに依存する日本のシステム
を推奨するわけですね先生は
そしてそれは賢いことだとお考えですね

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

>>568
サハリン？　サハリンの実績は？

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

回避できない問題なんかないということだからな
MSが対応しなくても回避できる

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

サハリンに依存するシステムは嫌だわ
サハリンのことなんか何も知らんし

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

>>571
サハリンに依存することでか？

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

ローカルタイムに依存するシステムが沢山あっても不思議じゃないな
今現在サハリンに依存するシステムを構築する先生もいる

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

ｻﾊﾘﾝはSFでは帰属未定地
ｳﾝｺｿ連が不法占拠してる
歴史的に日本固有の領土

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

>>575
ワロてもうたわくそが

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

>>537
それはODをUTCで設定しない馬鹿が悪い

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

上の方で地域によっても年ごとにサマータイムは違うという話に対して
IANAのデーターベースまで持ってきた先生が
なんで時差が同じなら別地域のタイムゾーンを流用していいなんて後退をしてるのか、ｺﾚｶﾞﾜｶﾗﾅｲ

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

調べてみたら、ロシアの標準時って変更される事があるんだね。

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

とりあえずこのスレのみんなでサハリンに視察に行こう。
幸い引率の先生もいらっしゃることだし。

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

半角くんの引率でサハリン旅行は楽しそうだな
機内では国境を超えた瞬間にみんなでスマホのタイムゾーンを変えて、盛大にお祝いしよう

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

サマータイムはなにも悪くない

ローカルタイムとかいう人間向けに整形された時刻の表現方法を機械システム内部に使ってるやつが悪い

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

>>582
ローカルタイム使わないと、サマータイムに対応できないじゃん
ローカルタイムは自動的に時間を制御してくれるけど、
UTCを使ってるとサマータイムになっても時間ずらしてくれないよ

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

むしろ世界中の時計の時刻をUTCにしたらいいじゃないか？

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

>>583
ローカルタイムは人間向けの表現方法だから(機械内部のUTC表現から変換して)表示部にだけ使うのが真っ当だと思わない？

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

逆に人間から入力されたローカルタイム形式の時刻表現は機械内部に取り込むときにUTCに逆変換する

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

>>586
その時に入力者がUTC+9とUTC+11のどちらを意図してるかを明示してもらわないといけなくなると思うんだけど、どうすんのがベストなんだろ。

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

>>587
そんなのシステムのロケールに従うに決まってるだろ

**デフォルトの名無しさん** · 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時間なのかは入力者に明示してもらわない限り分からないって、上で言われてたやん