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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2018/08/11(土) 09:39:28.62ID:GyOCk5m6
はいどうぞ
2018/08/21(火) 23:54:32.32ID:ubmHyRTx
>>531
では表示の問題とはなんですか？
533デフォルトの名無しさん
垢版 |
2018/08/21(火) 23:55:19.52ID:3gTjznwF
UTC基準のｼﾘｱﾙ値保存してるのに
ﾌｧｲﾙのﾀｲﾑｽﾀﾝﾌﾟが変わるﾜｹがない

普通にmakeでもなにも問題おきなし
2018/08/21(火) 23:56:07.34ID:ubmHyRTx
表示の問題とは何ですか？って質問です
535デフォルトの名無しさん
垢版 |
2018/08/21(火) 23:56:54.49ID:3gTjznwF
時刻の大小関係が狂うことなんかないからな
makeは依存関係とﾀｲﾑｽﾀﾝﾌﾟのﾙｰﾙに基づいて動く
一切問題なんかおきない
2018/08/21(火) 23:57:42.84ID:ubmHyRTx
ほうほうそれで表示の問題とは何ですか？
2018/08/21(火) 23:58:36.63ID:EIn52tlL
>>485
VTOCは対応してないぞ
COBOLもアウトだ
汎用機どうにもならん
538デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:03:30.79ID:cgNlHyUI
ﾌｧｲﾙのﾀｲﾑｽﾀﾝﾌﾟの表示で
具体的な問題なんか発生しない

ﾀｲﾑｽﾀﾝﾌﾟの大小関係の整合がくずれることはない
※ UTC基準で正確な時刻だからな
2018/08/22(水) 00:03:56.59ID:yaQgvnB8
スマホ未満のシーケンサーとかIoT機器とか逆に鯖よりでかい汎用機は厳しいな
バッチスケジュールがサマータイムと重なる鯖もやばい
簡単に出来ると言う奴死んでくれ
540デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:04:02.32ID:cgNlHyUI
対応できないのは触らなければいい
2018/08/22(水) 00:05:20.70ID:DjdqEJdz
>>538
表示の問題だと言ったのは先生ですが
それは撤回されるという事ですね？
2018/08/22(水) 00:05:51.26ID:yaQgvnB8
>>538
UTC対応してない汎用機のトランザクションログどうするのよ
ファイルシステムもローカル時間だよ
543デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:06:45.36ID:cgNlHyUI
表示の問題で
問題がおきることはない

低学歴知恵遅れの日本語ﾘﾃﾗｼの低さは異常だからな
2018/08/22(水) 00:07:58.78ID:yaQgvnB8
>>543
あるわいボケ
WindowsとLinuxだけがOSじゃないんだぜ
2018/08/22(水) 00:08:02.36ID:DjdqEJdz
>>543
表示する上でも重複起きないですか？
2018/08/22(水) 00:08:47.20ID:zKJOcwC8
レシートのタイムスタンプも修正必要？
547デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:10:59.08ID:Sj5zqs8z
UTC時刻は連続で、それらの差でそのまま時間が計算できる時刻の表現方法。
ローカルタイムはUTCの一価の写像で不連続で、それらの差がそのまま時間にならない時刻の表現方法。

合ってる？
548デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:11:02.31ID:cgNlHyUI
表示で重複おきようがおきまいが
なんの問題もおきないからな
2018/08/22(水) 00:13:25.43ID:DjdqEJdz
>>548
見てわかんないじゃないですか
2018/08/22(水) 00:15:02.44ID:DjdqEJdz
ローカルタイムに依存するものはシステムも業務も
影響受けるんですよ、だからサマータイムは大変なんです
551デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:16:00.90ID:cgNlHyUI
ﾀｲﾑｿﾞｰﾝが併記されてたらわかる

別に夏時間がおわったら
現時点の時差に従って時刻を表示すればしまいだからな
どうでもいい仕様の決めの問題

このとおり
https://i.imgur.com/7Kkiiju.png
①日本時間（ﾀｲﾑｽﾀﾝﾌﾟ）
https://i.imgur.com/og6eH3p.png
②ｻﾊﾘﾝ時間（ﾀｲﾑｽﾀﾝﾌﾟ）

ﾎﾝﾄなかわいそうなぐらい頭悪い
2018/08/22(水) 00:17:36.80ID:DjdqEJdz
UTCに変換すれば良い
UTCから変換すればいいというのは
その通りなんだけど銀行潰れるとわかってて金預ける人がいないように
今現在ローカルタイムに依存してしまってるものがあるでしょうと
553デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:18:25.29ID:cgNlHyUI
ﾆｭｰﾖｰｸはいま
夏時間でﾀｲﾑｿﾞｰﾝはEDT
夏時間が終われﾀｲﾑｿﾞｰﾝはESTになる
2018/08/22(水) 00:18:56.71ID:DjdqEJdz
>>551
それで何が解決するん？
サマータイムの問題は何かしら？
555デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:19:51.37ID:cgNlHyUI
むしろなんの問題もおきないことが証明されてる
低学歴知恵遅れが
低学歴知恵遅れな作りにしなければな
556デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:20:48.94ID:cgNlHyUI
そもそも解決すべき問題がない

意味不明なことを問題だと思いたい低学歴知恵遅れのｵﾂﾑの問題
2018/08/22(水) 00:22:09.08ID:DjdqEJdz
>>556
ではサマータイムの対応で先生にできることは
何もないのでご卒業おめでとうございます
558デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:22:29.98ID:Sj5zqs8z
>>552
ローカルタイムは不連続関数なのに連続関数と仮定して作られたシステム？
2018/08/22(水) 00:23:16.22ID:DjdqEJdz
>>558
誰お前、先生に言いつけるぞ
2018/08/22(水) 00:23:56.93ID:DjdqEJdz
先生、スレのOBとしてやっちゃってください
2018/08/22(水) 00:27:10.40ID:ObhFVXyF
>>551
それだと例えば5月のファイルのタイムスタンプもサハリン時間で表示されてしまう
562デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:27:37.81ID:cgNlHyUI
なんの問題もない
563デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:29:40.50ID:cgNlHyUI
むしろ全体で連続してる

すべてUTCを基準にした
ｻﾊﾘﾝ時間基準
すべて夏時間基準(JDT)になってる
なにも間違ってない
2018/08/22(水) 00:30:45.70ID:DjdqEJdz
一方そのころサハリンでは
2018/08/22(水) 00:31:37.38ID:DjdqEJdz
他所の国のタイムゾーンに依存してホンマに大丈夫なんでっか？
2018/08/22(水) 00:33:41.09ID:DjdqEJdz
タイムゾーンの使い方を間違えてると思うの
日本マイクロソフトがきっとなんとかしてくれるよ
567デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:34:22.98ID:cgNlHyUI
知恵遅れが知恵遅れな作りにしてなければ
なんの問題も起きない

ﾀｲﾑｿﾞｰﾝなんかただの相対値の定義だからな
568デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:36:34.28ID:cgNlHyUI
ﾆｭｰﾖｰｸはいま
夏時間でﾀｲﾑｿﾞｰﾝはEDT
夏時間が終われﾀｲﾑｿﾞｰﾝはESTになる

このとおり夏時間は
ﾀｲﾑｿﾞｰﾝを切り替えてるだけだからな
2018/08/22(水) 00:37:52.25ID:DjdqEJdz
>>567
サハリンのタイムゾーンに依存する日本のシステム
を推奨するわけですね先生は
そしてそれは賢いことだとお考えですね
2018/08/22(水) 00:38:44.60ID:DjdqEJdz
>>568
サハリン？　サハリンの実績は？
571デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:39:42.38ID:cgNlHyUI
回避できない問題なんかないということだからな
MSが対応しなくても回避できる
2018/08/22(水) 00:40:20.09ID:DjdqEJdz
サハリンに依存するシステムは嫌だわ
サハリンのことなんか何も知らんし
2018/08/22(水) 00:41:00.23ID:DjdqEJdz
>>571
サハリンに依存することでか？
2018/08/22(水) 00:42:25.24ID:DjdqEJdz
ローカルタイムに依存するシステムが沢山あっても不思議じゃないな
今現在サハリンに依存するシステムを構築する先生もいる
575デフォルトの名無しさん
垢版 |
2018/08/22(水) 00:43:24.88ID:cgNlHyUI
ｻﾊﾘﾝはSFでは帰属未定地
ｳﾝｺｿ連が不法占拠してる
歴史的に日本固有の領土
2018/08/22(水) 00:47:54.04ID:DjdqEJdz
>>575
ワロてもうたわくそが
2018/08/22(水) 02:16:54.09ID:AXf2QKcH
>>537
それはODをUTCで設定しない馬鹿が悪い
2018/08/22(水) 02:22:42.15ID:feXPALIV
上の方で地域によっても年ごとにサマータイムは違うという話に対して
IANAのデーターベースまで持ってきた先生が
なんで時差が同じなら別地域のタイムゾーンを流用していいなんて後退をしてるのか、ｺﾚｶﾞﾜｶﾗﾅｲ
2018/08/22(水) 02:41:01.36ID:3u9WNKO9
調べてみたら、ロシアの標準時って変更される事があるんだね。
2018/08/22(水) 06:22:43.77ID:1ZySJXOP
とりあえずこのスレのみんなでサハリンに視察に行こう。
幸い引率の先生もいらっしゃることだし。
2018/08/22(水) 11:54:02.89ID:0XlZNPWV
半角くんの引率でサハリン旅行は楽しそうだな
機内では国境を超えた瞬間にみんなでスマホのタイムゾーンを変えて、盛大にお祝いしよう
2018/08/22(水) 12:45:47.13ID:g2YEMIVY
サマータイムはなにも悪くない

ローカルタイムとかいう人間向けに整形された時刻の表現方法を機械システム内部に使ってるやつが悪い
2018/08/22(水) 12:48:10.34ID:O2PM/1qE
>>582
ローカルタイム使わないと、サマータイムに対応できないじゃん
ローカルタイムは自動的に時間を制御してくれるけど、
UTCを使ってるとサマータイムになっても時間ずらしてくれないよ
2018/08/22(水) 12:54:33.89ID:BKQgx/dM
むしろ世界中の時計の時刻をUTCにしたらいいじゃないか？
2018/08/22(水) 13:04:10.09ID:LAzf51US
>>583
ローカルタイムは人間向けの表現方法だから(機械内部のUTC表現から変換して)表示部にだけ使うのが真っ当だと思わない？
2018/08/22(水) 13:06:29.28ID:IfumfbHf
逆に人間から入力されたローカルタイム形式の時刻表現は機械内部に取り込むときにUTCに逆変換する
2018/08/22(水) 13:11:46.94ID:0XlZNPWV
>>586
その時に入力者がUTC+9とUTC+11のどちらを意図してるかを明示してもらわないといけなくなると思うんだけど、どうすんのがベストなんだろ。
2018/08/22(水) 13:12:22.28ID:IfumfbHf
>>587
そんなのシステムのロケールに従うに決まってるだろ
2018/08/22(水) 13:15:49.90ID:0XlZNPWV
>>588
それじゃダメじゃん。
UTC+11になってる期間に、サマータイム終了後のUTC+9の時刻の入力をすることは当然ありうるんだから。
今のシステムがUTC+11だからといって入力者がそれを意図してるかは分からない。

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

クライアントのロケールと入力者の意図は必ずしも一致しない。
2018/08/22(水) 13:18:54.59ID:0XlZNPWV
ローカルタイムだとサマータイム終了日の午前2時は2回やってくるんだから、
単に02:00とだけ入力された場合、それがUTC換算でどちらを意図した時刻なのかは自明にはなり得ない。
2018/08/22(水) 13:35:05.80ID:O2PM/1qE
>>585
ん？ コンピュータを使うのは人間なんだから
人間にわせたほうが良いでしょ。
コンピュータに合わせて2進数使うとかおかしいし
なによりコンピュータは人間が楽をするために作られた道具
2018/08/22(水) 17:03:34.92ID:nGc79qSt
ローカルタイムには、存在しない日時(サマータイム開始直後)もあったりすんだよね
2018/08/22(水) 17:10:14.01ID:C7qNO044
>>591
表示部にだけ使うっていってんだろ
文盲かよ
2018/08/22(水) 17:11:07.78ID:I86cqmu2
>>591
半角先生もそうだけど、コンピュータの中のことしか考えてない奴が一定数いるんだよな
それを使う人間と、その人間がやりたいことが出来るかという視点がスッポリ抜け落ちてる
2018/08/22(水) 17:15:11.80ID:StT9/L8q
>>589
入力したローカルタイムをunixtimeに変換するシステムの関数がその時刻がサマータイムか判定すればいい気がするけど。
２番目のことについてはその通りでたしかにその問題は残る
古いのを使ってるくせにまともな動作を期待するなって言っとけばいい
2018/08/22(水) 17:16:48.20ID:U3N+h8F9
>>590
その問題も残る
人間形式を複雑にすればするほど入力も複雑になる当たり前の摂理
2018/08/22(水) 17:17:39.15ID:feXPALIV
>>589-590
OSの地域設定とTZデータベースがちゃんとしてれば
未来の時間を入力されたところで、その日がサマータイム対象かどうかを考慮した変換してくれるはず……
でも後でサマータイムが変更になったらまあ発狂せざるを得ないわな
(二年だけといっていたなあれは嘘だ、とか普通にありそうだし)

やっぱり入力時に意図されたであろう時差もペアで記録しておくのが現実的かね
2018/08/22(水) 17:18:53.42ID:lRAN2Avu
>>594
だから人間とのインターフェースは人間寄りにするって言ってんだろ
計算機が内部では2進数で扱うが表示部は10進数にするのと同じだよ
2018/08/22(水) 17:29:03.17ID:feXPALIV
傍目にも>>583は言葉足らずに思えるので、「やりたいこと」を当ててみるか

毎日定時(ローカルタイム)に行う処理があって、加えて特定の日付でそれに依存した追加処理をしたい
将来サマータイムが変更されても問題ないように作りたいのでローカルタイムで記録することに意味がある、とかかな
現実には結構多いケースかもしれない
2018/08/22(水) 17:41:44.07ID:Sj5zqs8z
>>595の後半は強引すぎた
サマータイムに対応済みか条件文で判定できるようにして対応してなかったら適当な処理をする
2018/08/22(水) 17:43:57.06ID:Sj5zqs8z
>>597
発狂はしない
unixtimeで保存するから人間形式の仕様が変わっても関係無い
2018/08/22(水) 17:46:22.87ID:Sj5zqs8z
>>599
なくね？全部unixtimeで処理・保存すればいい気がするけど
かんがえるのめんどいからなんか具体例だしてみ
2018/08/22(水) 17:47:57.23ID:I86cqmu2
>>595
Androidの場合は大して古くなくてもアップデートが提供されないからなかなか切り捨てにくいよなあ
どうすっぺかねほんと
2018/08/22(水) 17:49:50.56ID:Sj5zqs8z
>>603
>>600
2018/08/22(水) 17:53:49.16ID:I86cqmu2
>>604
すまん見逃してた。そうね、未対応なクライアントに関しては強制的にJSTとみなすのが現実的かね。
2018/08/22(水) 17:54:47.13ID:feXPALIV
>>601
いやいや、入力した人間の意図なんてわかんないだろ
外国の放送を録画したいとかあるかもしれないし
2018/08/22(水) 17:57:31.38ID:Sj5zqs8z
>>606
そんなのサマータイム以前の時差の問題だろ
今現在そういうサービスとかでどういう処理してるか考えれば問題起こらないことわかると思うけど
2018/08/22(水) 18:00:11.10ID:feXPALIV
>>602
例もなにもそのまんま、5年後の正午(ローカル)になんかしたいけどサマータイム本当に2年で終わるのかなあ心配だなあ
どう転んでもいいようにローカルタイムで保存しとけ、って発想で作られるシステムは出てくるはず
2018/08/22(水) 18:01:41.86ID:Sj5zqs8z
複雑怪奇な人間フォーマットのままで内部処理するシステムが悪
単純で全世界共通で絶対的なunixtimeに正規化してから処理するべきだと思うけど
2018/08/22(水) 18:04:18.63ID:Sj5zqs8z
>>608
サマータイムが終わろうが始まろうがunixtimeで処理すれば何の影響もなくね？
2018/08/22(水) 18:06:32.61ID:feXPALIV
>>607
未来の時刻を入力後にサマータイムのルール自体が変更になった、という仮定の話なのはOK？
unixtimeのみで記録していると国内時間を意図していた時にずれるし
時差込みで記録していても海外時間を意図していた時にずれる
ユーザーの意図なんてわかんないだろ
2018/08/22(水) 18:07:59.27ID:Sj5zqs8z
>>611
なるほど
2018/08/22(水) 18:10:51.57ID:O2PM/1qE
>>593
> 表示部にだけ使うっていってんだろ

翻訳じゃないんだから、サマータイムは表示だけの問題じゃないぞ
具体的に言えば、サマータイムに入る当日
ローカルタイムの1日は23時間になる。
UTCは変わらず24時間にもかかわらずだ。
そしてサマータイムが終わる日、その日は25時間になる
表示だけの問題じゃない。一日の長さが変わるんだよ
2018/08/22(水) 18:11:43.52ID:O2PM/1qE
>>610
> サマータイムが終わろうが始まろうがunixtimeで処理すれば何の影響もなくね？

unixtimeで処理したら、一日の長さが23時間 または 25時間に
なる場合に対応できない
2018/08/22(水) 18:14:28.74ID:Sj5zqs8z
はぁ...
2018/08/22(水) 18:15:39.28ID:Sj5zqs8z
つらい
2018/08/22(水) 18:20:58.04ID:O2PM/1qE
具体的に言うと、サマータイム開始の日が夜勤の場合、労働時間が1時間短くなる。
その当日だけ、1時間分給料を減らさなければならない。
逆にサマータイムが終わる人は労働時間を1時間増やすことになる
2018/08/22(水) 18:23:05.29ID:O2PM/1qE
サマータイムで切り替わった日の朝は1時間早くこなければいけない
ローカルタイムの出勤時間は何も変わらないが、
unixtimeで扱っている場合は、一時間出勤時間を変更しなければいけない
2018/08/22(水) 18:24:48.80ID:Sj5zqs8z
思考停止してる
2018/08/22(水) 18:27:38.07ID:O2PM/1qE
>>619
いいからなにか言い返せよｗ
1時間が23時間になる場合にどうやって対処しろと？
2018/08/22(水) 18:32:43.09ID:O2PM/1qE
夜間バッチの実行にも支障が出るからな。
夜間が1時間短くなるということは、1時間早く実行しなければ朝まで間に合わないかもしれない。
だが、1時間早く実行しようとしたら、まだ業務中かもしれない。
1時間早く処理するために、プログラムの見直しやサーバー増強が必要になるかもしれない
unixtimeで扱っていると、サマータイムがないのと同じ時間で処理されてしまう
つまりunixtimeはサマータイムに対応していないも同然
2018/08/22(水) 18:35:51.91ID:O2PM/1qE
unixtimeのどこにいても変わらないという性質は
日本のサマータイムを無視するという意味になるからな。
サマータイムに対応するにはunixtimeで処理してはダメだということだ
2018/08/22(水) 18:44:28.34ID:feXPALIV
>>620
虐めんなw
考え直せるなんて5chでの議論相手としては相当に上等だぞ
2018/08/22(水) 19:00:02.56ID:qeeSAqiw
>>617
開始時間と終了時間をUTCで記録すればなんの問題もないね
2018/08/22(水) 19:03:51.26ID:O2PM/1qE
朝9時になったぞ。なんで機械は動いてないんだ！？
unixtime処理してますので、後一時間後には動きます
時計は9時を指してるぞ？どういうことだ？

だからーそれは表示がそうなってるだけなんだってー
人間のほうが一時間はやく起きてきたんでしょー
コンピュータは正確なの
2018/08/22(水) 19:06:16.06ID:O2PM/1qE
>>624
UTCで記録したらサマータイム中でも
一時間早くならないじゃんｗ
2018/08/22(水) 19:07:42.05ID:3pfLjmIv
結局就業時間がUTC基準で数時間ズレる事実はどうにもならないのね
2018/08/22(水) 19:15:03.16ID:O2PM/1qE
サマータイムがないUTCの時間で行動しましょうっていうのは
結局サマータイム批判ではないか
2018/08/22(水) 19:45:25.33ID:O2PM/1qE
結局の所、本質は日本人が1時間早く行動しましょうっていうことだからね
時間がずれるのではなく、人間の行動時間がずれる
システムはその人間の時間に合わせないといけない

ローカルタイムを使っていれば、勝手に時間を合わせてくれるけど
UTCを使っていると、時間を合わせてくれない。
だから別途サマータイムへの対応の修正が必要になる。
2018/08/22(水) 20:17:05.48ID:oqm7/Tfy
>>618
日跨ぎ処理なんかに影響が出そうだよな
631デフォルトの名無しさん
垢版 |
2018/08/22(水) 20:59:32.26ID:cgNlHyUI
相変わらず低学歴知恵遅れは頭悪いわ
低学歴知恵遅れはｸｿ頭悪いからちょっとした工夫すらできない
で、ｸｿ頭悪いｼｽﾃﾑ作るﾜｹ

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

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

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

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

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

ともかくな低学歴知恵遅れのｸｿﾆｰﾄと底辺ﾄﾞｶﾀの知能は低すぎるﾜｹ
まず出発点の考え方が間違ってるからな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況