BLOGOS 、サマータイム導入の提灯記事が酷すぎる件 その3(宮脇睦氏)

質の低いデマに近いブログを平気で載せまくってる BLOGOS さんのサマータイムについての酷い記事を紹介するコーナー

パート３です

BLOGOS 、サマータイム導入の提灯記事が酷すぎる件 その2(essa 氏)

質の低いデマに近いブログを平気で載せまくってる BLOGOS さんのサマータイムについての酷い記事を紹介するコーナー

パート２です

BLOGOS 、サマータイム導入の提灯記事が酷すぎる件 その1(船田元 氏)

質の低いデマに近いブログを平気で載せまくってる BLOGOS さん

赤旗のニュースを採用したBLOGOSの記事が酷いので図解してみた
【デマ】記録的な猛暑で電力不足にならないのは太陽光発電のおかげ【菅直人元首相】
【悲報】#BLOGOS 串カツ田中さん の禁煙のニュースちゃんと読んでなくてデマで炎上させる。一部のTwitter民拡散して開き直った挙句人格攻撃、個人情報公開を要求

サマータイムについてもかなりひどい記事が混じっています。
偏った記事が多いというよりは、質より量で、色々な人の記事を集めてて信頼できないものが多いというのが正しいのでしょうが、これでは、全ての記事の信頼性がなくなってしまいます (;˘ω˘)

とりあえず、3つの記事について
…詳しく解説して行きます

サマータイム、IT分野では、単に時間の調整だけでは済まないという話

1. GMT（グリニッジグリニッジ標準時）からの計算ルーチンが必要になる

これは分かると思う、世界標準時から、日本時間にするのが単に9時間足せばいいだけではなくなるので大変だ。
多分、殆どの人はこの程度の修正でIT分野は住むのではないかと思ってるはずだ。

例えば、 IsDST みたいな関数で、夏時間が適用されてるかどうかという処理が必要になる。
こうしないと、累積時間を計算をするときに2時間狂ってしまう。



2. JST（日本標準時） に加えて JDT（日本夏時間） の定義が必要になりそれを使わなくてはいけない

これが実は凄く厄介だ。
夏時間には、 スプリング フォワード（春季に2時間進める）とフォール バック（秋期に2時間戻す）処理に関する問題があって、例えば、 スプリング フォワード で午前 1時から3時にスキップする決まりになった場合、 この日の 午前 1時から２時59分59秒 が指定された場合は無効にする処理を入れなくてはいけない

問題は、フォールバックだ。
この日 午前3時になったら、午前１時に戻す決まりになったとすると、
この日の午前１時から２時５９分５９秒までの時間帯は２重に存在する。
これを回避するために、海外では、コンピュータの時刻管理に、DSTかどうかを表すフラグや、現在のタイムゾーンが何なのかを保存するようになっている。

例えば、11月5日にフォールバックがあった場合
夏時間に対応したコンピュータはこんな風になる

時刻	TZ	GMT
01:30:00	JDT(日本夏時間）	14:30
02:15:00	JDT(日本夏時間）	15:15
02:45:00	JDT(日本夏時間）	15:45
01:00:00	JST(日本標準時）	16:00
01:45:00	JST(日本標準時）	16:45

日本のシステムは、国内の夏時間を考慮している物なんてほとんどない。
タイムゾーンかDSTのフラグをデータベースに追加して、データベースを再構築するか、さもなくば時刻を全部GMTで内部的に処理するように変更するために、過去のデータベースを変換しなければならない。
(元々、Linux Time を直接保存するなど、GMTで処理している物であれば、特に気にしなくてもいいだろうが、表示系が関わるものについては、フォールバックを考慮して、重複する時間帯について何らかの対策を行わなくては不具合が出るのだ。
例えば、未来の時間にスケジューリングされてコンピュータが暴走したり、
時間が巻戻ってしまったり、
処理がなかった事になってしまったり・・・
と色々考えられる


3. 海外との時差が変わる！

日本が海外の時刻との差を考える時ももちろんそうなのだが…。それだけにとどまらない。
どういう事かというと、海外から日本の時差を考慮する必要が生まれる。
例えば、海外の株式取引上のシステム、開場時間などが２時間狂ったまま処理をすると、大損害を出す可能性もある。
要するに、日本だけではなく、海外のシステムにも迷惑がかかるのだ

他国への迷惑なんて考えてなかった？
まさか、その為の費用も税金で賄うんじゃないでしょうね？・ω・



4. 2年限定で、ルールを元に戻す方針！？

毎年運用ルールが固定化されるのであれば、この仕様変更は必要なので、全てのIT 分野で修正が行われるだろう。
しかし、時限的なものなので、適用間に合わなかったから、そのまま放置してしまおう、なんてシステムが出てきたらさぁたいへん。
そのシステムが、JDT に対応しているかどうかで処理が変わってしまう！・ω・
自社のシステムが全部サマータイムに対応してても、お客さんのシステムが対応してなくて、事故につながることだって考えられる。

2000年問題は恒久的な問題だったから、曜日がずれたまま運用するなんてことは考えられなかったけど、一時的な変更だと、絶対、運用でカバーなんてシステムが出て来るのは目に見えている ・ω・

対応してるシステムと対応してないシステムが連携すると大混乱になると思うよ！


5. 子供や老人や病気向けの人のソリューションと、例のない2時間のサマータイム

実は、海外では、子供や赤ちゃん、病人など向けに
いきなり1時間生活のリズムを変えることを強要せずに、
15分ずつ、起床時間や就寝時間をスライドさせて負担を減らそうっていう試みが行われている国もあるよ！ ・ω・

普通のサマータイムは1時間だから、4日かけてフォールバックやスプリングフォワードに対応することになる。

ところが、日本では ソ連占領地域のベルリン位しか前例のない2時間のサマータイムを導入しようとしています。
いきなり次の日から2時間起床・就寝時間が早くなったり、遅くなったりするのを強いるわけではないのなら、
1週間かけて 2時間ずらす処理を入れなくてはいけないのだ！

うわー、面戸臭い！！！


2000年問題の時は、はっきり言って1だけよかったのですが、サマータイム対応だと、数倍大変なのがお分かりいただけるでしょうか？

さぁ、これ、見てもまだ本気で導入できるって主張する IT関係者おりゅ？ (((((・ω・)))))

【ネタ】あれ？産経のニュースが正しいのなら、もしかして、サマータイムって永久に来ないのでは(((・ω・)))？！

【東京五輪】酷暑対策でサマータイム導入へ　秋の臨時国会で議員立法　３１、３２年限定（1/2ページ） - 産経ニュース

東京五輪・パラリンピックの酷暑対策として、夏の時間を２時間繰り上げるサマータイム（夏時間）導入に向け、本格検討に入った。与党はお盆明けにも制度設計に入り、秋の臨時国会への議員立法提出を目指す。平成３１、３２両年の限定導入となる公算が大きい。複数の政府・与党関係者が明らかにした。

( ^o^) 。o ( 平成31年と32年だけにサマータイム導入するってさ )

( ˘⊖˘) 。o( あれ？平成31年6月からサマータイムって平成いつまでだっけ？ )

2019年ＧＷ、政府が10連休検討　天皇即位・改元を祝賀　　：日本経済新聞
天皇陛下譲位は平成３１年４月３０日　改元は５月１日（1/2ページ） - 産経ニュース

|平成31年は4月30日まで| ┗(☋｀ )┓三

( ◠‿◠ )☛ そこに気づいてしまったか、サマータイム。お前には消えてもらう


▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ





　　　　　　。 o (  はっ、夢か… )
　　∧∧
　 ( ･ω･)
　_| ⊃／(＿＿＿
／ ヽ_(＿＿＿_／
￣￣￣￣￣￣￣

「サマータイム実施は不可能」スライドが話題　「経済被害が兆単位」「サイバーテロをお膳立て」立命大・上原教授が指摘 - ITmedia NEWS

夏時間の適用日と終了日のタスクスケジューラーの動作はどうなってるの？

サマータイムがどうやばいかを極端な例で非エンジニアに説明すると、もし原発の制御プログラムに「午前1時に冷却水排水」「午前2時に排水中止」みたいなコードがあって、午前2時がサマータイムで消えたとき、何も対策しないと冷却水が消失します。

— 平田朋義 (@tomo3141592653) August 6, 2018

こういう説明をしてる人がいたので、実際の Windows のタスクスケジューラーの動作について調べてみました。


INFO: Task Scheduler Behavior at Daylight Saving Time Transitions and Other Events

サマータイム（DST）移行処理について この記事では、2つの夏時間の移行シナリオを指定するために、Spring Forward（SF）とFall Back（FB）という用語を使用します。 DSTが有効になると、SFが発生します。システム時刻は、たとえば、午前2時の地元の日曜日の朝など、1時間前に調整されます。したがって、2：00：00〜2：59：59の時間は、そのタイムゾーンのその日のシステムには表示されません。 FB中にその逆が起こります。システム時間は、例えば、午前2時の地元の日曜日の朝など、1時間後に調整されます。そのタイムゾーンでは、1：00〜1：59：59の間の分が繰り返されます。システム内で2回発生します。

・ω・ ここまでは、わかる

スプリングフォワード SF遷移によって発生した時間内にスケジュールされたタスクに対して、スケジューラプログラムが動作する可能性のあるいくつかの方法があります。 動作1     その時間帯にその分が表示されないため、スケジューラはその分にスケジュールされているタスクを無視することがあります。この動作は、一部のアプリケーションでは適切な場合があります。スケジューラはそれらの時間がスケジュールに配置されるのを防ぎません。 動作2     DSTが発生していない場合、開始された実際の時刻にこれらのタスクを開始します。たとえば、午前2時5分に予定されているタスクは、実際には午後3時5分（DST）に実行されます。このアプローチは、互い違いにして配列しなければならないタスクに役立ちます。ただし、この方法では、最初のタスクに依存する別のタスクの後に1つのタスクが実行される可能性があります。たとえば、あるタスクが2:30にスケジュールされ、フォローアップタスクが3:15にスケジュールされている場合、3:15タスクが最初に実行され、次に2:30タスクが実行され、3:30に実行されます。 動作3     時間を圧縮し、欠落したタスクを、移行後のある時点で実行するようにスケジュールされた順序で実行します。この動作は、タスクを順番に保持します。しかし、いくつかのタスクがSFタイムアウト中にスケジュールされる場合、それらはほぼ同時に開始するように見えます。特定のタイミングとシーケンスを必要とする相互依存関係は、タスクのステップの失敗を引き起こす可能性があります。これは、最新のMicrosoftスケジューラが使用する方法です。

動作１は、時間が来ないのでスキップされるケース
動作２は、動作順序についてパラドックスが発生するケース
動作３は、圧縮して実行されるので、処理時間の問題が出るかもしれないケース（ Windows はこれ ）

フォールバック 以下は、時間の繰返し時にスケジュールされているタスクに対してスケジューラプログラムが動作するいくつかの動作です。 動作1     時間が繰り返されるため、スケジュールされた時間が発生するたびにタスクを再実行します。これは共通の要件ではないようです。ただし、この動作は一部のアプリケーションでは適切である可能性があります。 動作2     DSTが発生していない場合の実際の時刻にこれらのタスクを開始します。たとえば、その午前2時5分に予定されているタスクは、1:05の標準時（2番目の1:05ウォール・クロック時間）で実行されます。 動作3     スケジュールされたウォールクロック時にタスクを開始します。この動作は、その日付の午後2時に開始する予定のタスクを1時間遅延させますが、その時間を超えるすべてのタスクは、シーケンスと実際の時間間隔で発生します。最新のMicrosoftスケジューラがこの方法を使用しているようです。ただし、移行瞬間に正確に発生するようスケジュールされたタスクは、その瞬間に実行される可能性があります。たとえば、午前2時に発生するようにスケジュールされたタスクは、標準時の午前1時に実行されます（方法2のように）。

動作１は、時間が巻き戻るので、時間通り、２回実行されてしまうケース
動作２は、該当時間までの残り時間から逆算されて実行されるケース
動作３は、実際のシーケンスと等間隔で実行されるケース（ Windows はこれ ）



Twitter の例のように、２回実行されたり、処理がスキップされたりすることはなさそうですが
「冷却水を１時間注水する」ではなく「冷却水を注水開始」「冷却水を注水終了」というスケジュールだったら一瞬で終わってしまう、なんてケースはあるかもしれませんね・ω・