[特設]サマータイム対応相談室
■ このスレッドは過去ログ倉庫に格納されています
具体的に例を示してUTCで記録するだけで問題が解決しないことを示そう
イギリスとモロッコはともにUTC+0000である。
イギリスはサマータイムを実施しているがモロッコは実施していない
さてイギリスとモロッコに住む人がともに朝8時に目覚ましをかけたとしよう
UTC+0000なのだからUTCで記録するとどちらも同じ8:00ということになる
ではUTCで8:00にアラームが鳴ると設定されている場合に、
どちらも同じ時間にアラームを鳴らしていいだろうか？
残念ながらサマータイム中のイギリスは違う。1時間繰り上げているために
モロッコで8:00は、イギリスでは9:00になる
この時間のずれに対応するのが本当のサマータイム対応
UTCで8:00にアラームが鳴るという設定を、正しく機能させるにはどうするか？
それには「どこの国」という情報が必要になる。
それがわからないとサマータイムを実施しているかどうかすらわからないし、
何時に時間をずらすのかもわからない
またサマータイムを実施しているからと言って、1時間繰り上げるかどうかはものによる
だから「サマータイムの時にどうするか？」という情報も必要になる。
今回の日本のように2時間とか言っているなら「何時間ずらすか？」の情報も必要になるかもしれない
（国情報のみでずらす時間が決定できるなら、国情報のみでよいが）
前スレ [特設]サマータイム対応相談室
https://mevius.5ch.net/test/read.cgi/tech/1533947968/ あ、その2をつけ忘れたｗ
朝9:00の意味することが二通りあるんだよ
日本標準時をJSTとして
日本夏時間をJDTと呼ぶならば
9:00は、JSTで9:00（UTCだと0:00）、JDTでも9:00（UTCでは前日23:00）なのか
JSTで9:00（UTCだと0:00）、JDTで10:00（UTCは同じく0:00）
アラームだと期待するのは前者なんだが、
そうするとUTCで0:00と設定するのはダメだし
UTCで23:00と設定するのもダメ
設定時間が日付によって変わる。というのがサマータイムの本質なわけ ローカライゼーションとインターナショナリゼーションの違いにも似てるな
UTCで記録してもインターナショナリゼーションレベルの対応しかできない
サマータイムに対応するのはローカライゼーション（現地の文化に合わせること）
UTCで記録することはこっち
https://globalization.co.jp/resource/g11n/i18n/
> インターナショナリゼーションとは
> インターナショナリゼーションとは、ソフトウェア（アプリやウェブを含む）を
> さまざまな言語や地域に対応できる形に作っておくことを指します。
サマータイム対応はこっち
https://globalization.co.jp/resource/g11n/l10n/
> ローカリゼーションとは、ソフトウェア（アプリやウェブを含む）を
> 特定の言語や地域に合う形にすることを指します。
一時間ずらす日時は、地域によって異なる >>1
業務要件がわからないってだけですよね
それって決めの問題だけだと思うけど >>4
だから、サマータイム対応 = 要件決め なんですよ
一律に何かをやれば万事解決なんてことはありません。
だから大変なんですね。
相談しましょう サマータイムは生活を変えるためのものだから
目覚ましは標準時に合わせるのが普通だと思う ん？世界標準時？日本標準時？
日本標準時だろうけど、日本標準時がJSTからJDTに変わると
1時間早く起きないといけないんだよね
日本での表示上はどちらも9:00だけど、世界標準時から見ると1時間前に起きることになる >>7
たぶんユーザーと話してもサマータイムには
対応しなくていいって言われると思うｗ >>8
標準時は地域ごとの時間のことだから
世界時と言ったがいんじゃないかな
標準時が冬時間か夏時間かは
夏時間の期間を国が決めるからそれによって決まるよ
目覚ましは標準時に従うのが普通でしょ >>9
先回りしてサマータイムの問題をこのように整理しました
このように対応しようと思います、よろしくご査収くださいませ、でおｋでしょ >>10
> 目覚ましは標準時に従うのが普通でしょ
そうするとUTCで時間を保存するのはあまり意味がないんだよね >>12
時間を保存するっていうのは何が目的なのかな
時間を保存しておいて他のタイムゾーンに変換して
出力したいのさってことなら意味はあるかと
ログを見れればいいってのなら標準時でも良いと思うけど 時間の計算をするときはUTCが良いから
正規形としてUTCを採用するのは良いと思うよ >>1-2
「09:00」は日付なしで正式なローカルタイム時刻表現形式ではない特殊な表現形式であって、その形式だとその意味は日付によって変わるのだから毎日その日の日付を付け加えて正式なローカルタイム形式を完成させてからunixtimeにデコードするのが真っ当では？ サマータイムに対応した目覚ましなら夏時間か冬時間か指定できるっしょ UTCオフセットを入力できるようにして
全世界のタイムゾーンに対応してるぜってのも良いかもね カレンダーの機能が搭載されてるなら
夏時間の指定も必要ないのか サマータイムなんて導入されるはずがない
討論するだけ時間の無駄 >>19
オリンピック委員会の森とか斉藤とか、IT有識者（）の宮脇とか、落合陽一とか、
このスレのID:EIhBcxjq さんとか・・・馬鹿が馬鹿を晒してるのをみるの楽しくない？
そういう娯楽だと思ってるよ。 前スレ埋めとけよ
この板なぜか980過ぎてもdat落ちしないんだからさ あまり騒がなくなってきたのは有耶無耶にして忘れてしまおうというながれか >19
その考え方は危ない
そんなことに成る筈は無い
と思ってて放って置いたら何時の間にかする連中の勢いが増してそうなっちゃいました
ってのが良くある
だからおかしな考えが出てきたら徹底的に叩かないといけない
今までこの手の話が出ては消えてを繰り返していたのに成立したケースがぽつぽつある
最近はデマが広がり易くなってるし
油断が一番危険
守る為に戦わないと何時の間にか盗られていた
なんて事になる どうなるかはわからないけれども
適切な選択肢を作れるように状況を整理しておくのは大事なこと
このスレの意義はそこにあると思う 要件定義もできない連中がオレオレ実装すげーだろってグダグダのマウント合戦になるだけだろ… 消化不十分で終わったのでコピペ
サマータイムに対応したcronを作るとなったら
どういう仕様にすればいいだろうか？
一般的なユースケースとして毎日深夜1:30分に
バックアップ処理を開始する。
サマータイムに入る時1時から2時に時間が進み
サマータイムが終わる時は2時から1時に時間が戻るものとする 1時から2時間が進むのだから深夜1:30分に
タイマーをセットしても発動しない。
1分毎に発動し、指定した時間が過ぎたかどうかで判断する必要がある
2時から1時に時間が戻るため、1:30分が2回発生する
だから一回発動したものは再度発動しないように制御する必要がある
UTCで時間を判断してしまうと、1:30にセットしたものが
2:30分に発動してしまうことになるので、
ローカルタイムで時間を判断する。
この時JSTとかJDTとかは無視する。
現在のタイムゾーンで、1:30を過ぎたかどうかで判断する
こんなところで大丈夫なのかな？
たかがcronでもサマータイム対応は大変だね やっぱり外部とのシステム連携が一番大変かな
スマホとかだと特にね
スマホのスケジュール管理アプリ。クラウドにデータ保存するが
インターネットに接続してないときはローカルにデータを記録するものとする
データはUTCもしくはタイムゾーン付きの日時で保存する
これで問題は解決するように思えるが、
スマホが古くてサマータイムへのアップデートに
対応できない場合アプリ側で対応することになる
なぜならサマータイムに対応するためにJSTのままスマホの時間を
1時間早くするだろうから時間がずれる
アプリをバージョンアップし、サマータイム中はJDTとして扱うようにする？
でもこれでもスケジュールで毎日1:30にアラームとか設定するとおかしくなるので
ローカル時間で管理しないとダメかな？ アラーム系が鬼門だな。
いままでは毎日同じ時間にアラームをセットするなら
最初に設定した日時に24時間（86400秒）を足していったのが
次のアラームの時間だけど、サマータイムに入るときは23時間、
出るときは25時間たさないと次のアラームの時刻にならない
どうプログラミングするのが楽なんだろうね。
一旦タイムゾーン情報をなくしてから足していくとか？ でも1:30にセットして、サマータイムで1:00が2:00に飛ぶ場合
いつアラームがなればいいかは場合によるんだよな
例えば、1:30にアラームをセットして、2:00に鳴ったら30分遅れたことになる
その30分前だから0:30分にアラームが鳴らないといけない
0:00の90分後としてアラームをセットしたなら2:30に鳴らなければいけない
さっきのcronの仕組みだと、1:30にアラームをセットしたら2:00にアラームが鳴る
鳴らないのが正解のパターンもあるかもしれない。
ソレを含めると
でも1:30にセットして、サマータイムで1:00が2:00に飛ぶ場合
・アラームはならない
・0:30にアラームが鳴る
・2:00（=1:00）にアラームが鳴る
・2:30にアラームが鳴る
この4パターンが考えられるだろう 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b) 少なくとも、日時指定の直接指定方式と
現在（特定の日時）から何分後といった相対指定
この２つは必要になるんだろうな
「24時間サイクルで通知する」のと
「毎日○時○分に通知する」とでは
意味が違うわけか 低能の考え方なんてどうでもいいから日記帳にでも書いとけよ… >>35
半角カナ使ってると知恵遅れ認定されちゃうぞ 一応ちゃんと何らかの問題を解決しようとしているようには見えるだけ
指摘されたら罵倒してループ、よりは健全に見えてしまう 1分おきにローカルタイムをチェックして、
指定時間だったらアラームを鳴らす >>38
それだとサマータイム開始時の1時間進む処理に対応できないので
指定時間を超えていたらアラームを鳴らすにしないといけない。
といっても、何時間も超えているのに鳴らすのは不自然なので
そこらへんはいろいろと細かいルールが有る
詳しくは、ここのcronの処理フローとかが参考になると思う
https://moro-archive.hatenablog.com/entry/2015/03/17/011823 https://www.turbolinux.co.jp/products/server/11s/user_guide/cron.html
> cron のデーモンである crond は、1 分毎に設定ファイルを参照し、
> 設定されているジョブを定期的に実行します。
定期的に処理を実行する方法を考えた人は多いだろし
そのやり方もいくつかあるだろうけど、cronと同じ方法を
真っ先に思いついた人はセンスがある サマータイム開始時の1時間て、その日にその時間は無いのだから、
鳴らす必要無いんじゃね、閏年の2月末みたいに >>41
それは要件次第だから日付を扱うもの（ほとんど）毎に
検討する必要がある。まあ絶望的に大変な仕事だ 色々の前に端末ログオン出来ない可能性も考えてみるべき
ケルベロスは時刻を見ている
銀行などのトークン(有体物)も同様だがOAuthでも時刻トークンが使われている 流石にOAuthはUTC使ってるだろ
日本独自で実装したようなものは知らんが Windowsって、1949年の日本DSTに対応してる？
UTCからローカルタイムに変換しても、+10とはならないんだけど >>45
どのAPIを使うかによって結果が変わる
昔からあるAPIだと変換対象がいつかとか考えず「現在の」時差が適用される
変換対象の時点でのサマータイムを反映したければWindows7で新設されたAPIを使わないといけない
あと設定やらレジストリがどーのこーのあった筈 新しくAPIを作るんじゃなくて、互換性を切ればいいのに さて、時差情報は、誰が持ち、とこととこに記録されているでしょうか。
この新すらはつまらん。 ズレタイに
(補習)夏時間対応答えクレクレ「落第ギリギリの憩いの場」
にした方がいい 全然関係ないけどペットってサマータイムに対応させていいのか？ ある日突然1時間（2時間）ずらすとかでないなら、
明るくなったら活動するという体内時計に従うと思うんだけどな
でも室内飼いとかだとそうでもないかもな 猫だったら元々人間の生活時間に関係なく勝手に寝たり起きたりしてるから ひらめいた！ じゃあ俺ら、猫になればいいんじゃね！ >>57
それだ！時間、時刻、ローカルタイムの概念をなくそう！
夏時間対応もいらないし、時差もないから単純にUTCで記録して、UTCで表示する。
二度とふざけた経済需要喚起を目的としたかき混ぜに利用されない、影響されないためには、
ローカルタイム撤廃が最適解 たかだか20年ローカルタイム撤廃を貫けば、 それで日本の標準時間はUTCで理解される。
21時起床
0時就寝
そう思い込ませれバのよいだけ。
今のサマータイム推進と7時間しか違わないだけのことですよ！ まあ明治時代の人はそれ経験しただろうしやれないことはないだろう
しかし問題は表示上の数字よりも生活時間じゃね
サマータイムという形を取らなくても始業を夏に幾らか早める法律は制定可能だし
一部の公務員は既に適用されてしまってるらしいぞ >>57
オリンピックも中止！
それどころかローカルタイムの概念も必要無くなる！
そして仕事も無くなる！ 今、2020年8月1日10時で予約した場合、どうなるの >>63
それが日本時間であれば、日本時間（ローカルタイム）の
10時に発動するのが期待する動作だろうね >>64
夏時間開始時には「そんな時刻はありません」
夏時間終了時には「どちらの時刻でしょうか」
ということになりませんか 10時だから影響ないんじゃね
いやまあ、9時に切り替えを実施するみたいなアホ制度になるかもしれんけれど 余りにもアホくさいので現行の日本政府はレガシーと見做してボイコット、
新たに日本共和国を電子的に立ち上げる コンピューターネットワークだけのルールで動くサイバーコミュニティ。
ArcadianProject.竜宮島か。夢があるな >>70
前スレでも色々障害が挙げられたが、賞味期限を挙げたやつはいなかったな
やっぱり本当の障害は予想外から来るもんだ >>72
配送に関しては話してはいたが。
日本は下手にコンビニが24時間営業だからな
1時間減るならともかく1時間増えると廃棄の時間も変わる。
その時間に合わせて次の商品も並べないといけないから・・・
いろいろずれていくな >>73
麻雀パイのように「牌は定期的にかき混ぜるのが健全(自分のポジションに影響でない範囲で)」と考える人間は多い。 緯度が高い地域はサマータイムの恩恵は有りそうだけど
8割りも反対してるのか意外です
緯度が低くなると恩恵なんて大して無いから無駄な手間なだけ
止めるべき 廃止賛成が過半数を割った国はEU内2か国だけ！
https://hbol.jp/174056
意見公募の結果を国別に見ると、1年に2回の時間変更に90％以上が
反対を表明した上位5か国はフィンランド95％、ポーランド95％、スペイン93％、
リトアニア91％、クロアチア90％である。一方、過半数を割った国はキプロス47％、ギリシャ44％の2か国だけである。
国別の意見提供者の多かった上位5か国はドイツ3.79％、オーストリア2.94％、
ルクセンブルグ1.78％、フィンランド0.96％、エストニア0.94％。
参加者の最も低かった国は英国で、僅か0.02％。それでも時間変更反対派が82％を占めた。 >>75
高すぎても意味ない
白夜だと日が沈まずずっと昼だから 毎日2時0分に定時処理を行うという仕様も
指定時刻に意味があるのか、24時間間隔が重要なのか、一日一回ならなんでもいいのか
意図を汲み取っていかんとならん
うんざり まあ、日本でのサマータイム導入は、そもそも
1. 2019年、2020年だけ
2. 2か月間だけ
3. 2時間移動
以上がすべてクレイジーだとみんなが思っているわけだが。
実際あからさまにクレイジーだし。
でもさ、2020年のみの祝日移動についても怒ろうよ？
マジでありえないからさ！ 祝日は増えたり減ったり変わったりするものだし、春分の日や秋分の日のように
毎年2月にならないと翌年の祝日の日付が決まらないものがある
最初から計算では求められらずデータで管理するしかないものだって
わかってるのでそれに対応できてないとしたらシステムのほうが悪い >>80
その中に基準を動かすなんてキチガイじみたものはないよ 祝日と夏時間は異なるからね
例えに祝日を出して夏時間も同じ
と言うのはFaxとインターネッツが
同じと言ってるようなもの
抽象化し過ぎて対応コストという本質的な問題から
目を背けてる 夏時間に対応してないシステムはたくさんある
対応するとしてどうやるんですか
現実的に可能ですかということを考えなければいけない
システムが悪い、森元が悪い、安倍ぴょんがー
と言ったところで問題は解決しない >>79
夏時間の対応による経済的損失は2兆円という試算もある
国が景気良く金をばら撒かないと中小企業は潰れてしまう
それをやる気概が政府にあればいいが >>83
質問に質問で返すなよ。
基準を動かすとは、何を言ってるのか言えって だよな。祝日を移動するのは、時間を移動してるわけじゃない。
スケジュールアプリとか使ったことないのかな？
毎週何曜日に予定を入れる機能とかあるでしょ？
祝日は1年ごとの繰り返し予定と一緒だよ
で、毎週何曜日に予定を入れる機能っていうのは変更ができる。月曜日から火曜日とかにね。
この時「今週の予定のみ変更」と「今週以降の予定のみ変更」を選ぶことができるはず
祝日で言えば、2020年のみ、祝日予定の変更というわけだ。
他にも創業記念日ということでその会社のみの休日があったり
祝日が休みではなかったり、人によって祝日が異なったりする
だから祝日の変更機能はシステムに搭載されてる
時間をずらすのとはわけが違うよ なんで祝日の話してんねん
関係ないやろが！（ブチ切れ） 二ヶ月全部祝日にすれば時間がどうなろうと文句は出ないんじゃないかな( サービス業はがっぽり儲かるかもわからんね
デフレ脱却するならそれくらいやらんと >>90
会社固有の休みとか、お前固有の休みとかは自分で勝手に入れればいい。
サマータイムにせよ、祝日移動にせよ、
「xxxx年だけに固有」
というのは面倒以外の何でもない。
「xxxx年以降」だとかならまだしもさ！！！！！！！！
ウザいだけ。しんどいだけ。未来のプログラマーにいちいち負担を強いるだけ。
負債をシレッと未来に分散して、「これウザいんだけど」って叩かれる時にはとっくに死んでるから俺シラネ、という発想のジジイの腐れ発想にムカつくんだよ！！！！！！！！ >>85
システムはJSTのまま走らせて
このシステムはサマータイムに対応していませんの張り紙しておけ
これが今からできる最善策さ
マニュアル対応というやつだ >>99
「移動はヤメロ」って話。
2020も「祝日増やせばいいじゃん」は散々出た。
移動はマジでおかしい。 >>100
それはいい。
レシートの時刻も全部手書きで修正だなw ハッピーマンデーのような規則性すらないんだからな！！
面倒すぎる。未来100年に渡って迷惑をかける。
森喜朗は今すぐ刺されてどうにかなれ。 祝日は変にルールに基づいて決めようとするとハマるので
単純な祝日リストを作るのが本手だが。
祝日移動すんなとか言ってる人は春分の日とかどうしてんのかね。 そりゃ春分の日も移動すんなだろ
毎年移動してるのにねｗ 便利？ サマータイムは電気代節約とか
システムの都合で作ったものじゃん
電気料金というシステムの都合で導入したもの オリンピックは口実で、真相は残業代ゼロ法案とのコンボ狙いとも噂されてるな
電気代にしろ早朝の涼しい時間帯を工場等が使って、夜の暑い時を家庭に押し付ける
トータルで言えば各家で個別に冷房を動かす分効率悪くて逆効果なんだが企業は得をする
オリンピック、残業、電気代のどれ目当てにしろそれを便利ということは
つまり>>109は労働者や現場社長なんかより更に上の階級に属しているご身分なんだろう。羨ましいことで 断念おめでとう
本当におめでとう
検討は続けるような物言いなのは引っかかるけれども。オリンピックは口実に過ぎなかったんだなあって
でもまあ、とにかく今はおめでとう！おめでとう！ いやぁ
本当に良かった
これで無意味で余計な事をしなくて済むし
もうここを見ることも書き込む無駄をしなくて済む
おめでとう
このスレどうするの?(笑) でもまだ油断は出来ない。奴らはまだ諦めていない。
五輪終了後でもいいからやりたいとかほざいてるようだ。 人にサマータイムを願う心があればいずれ第二第三の略 フジの韓流と同じで何の前触れもなくまたぶっこんでくる気がする 大阪万博が決定したからその為に導入だ
とかやる可能性も無きにしも非ず 結局票田に媚びてるだけだからおまいらがどう思おうとサマータイムが導入されることになる 以前から出ては消えるを繰り返しているからね
油断すれば何時の間にか導入
というのは十分にありえる
又誰か騒ぎ出したら頭を抑えないと何時の間に導入されてしまったりするからね
見つけたら叩くしかない
つーか
そろそろ元号か・・・ 日の出と共に一日が始まる的な理論だし
サマータイムって ■ このスレッドは過去ログ倉庫に格納されています
