２０２０年 東京オリンピック
開催日程 ２０２０年７月２４日～８月９日
※ ソフトボールとサッカーは先行して ２０２０年７月２２日から競技開始
※ 本記事記載時点情報
まぁ、今年の実績ベースで言えば、外気温最高マックス ぶち厚いデェー期間まっさかりである。
ほぼ毎日外気温最高温度は ３５℃以上になるわけですよ。
やる気を見せるえらい人々（推定無能のお偉いさん）
競技選手や観客の健康面を考慮して、２時間早く開始すれば、涼しい朝の時間に済ませられるのでは？
よし、サマータイム導入だ！ オリンピック関連期間、２時間前倒しになるサマータイムを導入するぞ！！
なお、２年間限定の制度とするぞ！！ オリンピック終わったら元通りだ！！
周囲の反応やネット記事で見かけたのいろいろ：
面倒なのであえてソースは再発掘しないことにする。すでに消えているかもしれないし。
・ IT系のきちんとしている人々
サマータイム導入 → システムクロックが変動する
→ ありとあらゆる互換性確認・検証、パッチ実装など対応
→ サマータイム発動時に立ち会いなどの工数
しかもカットオーバーまで２年？
死ぬる・・・
・ IT系を語るダメな人々
サマータイム導入→最新のシステムなら問題ない（どや）
→ サマータイム発動日にシステム停止して、再起動時に時計を２時間変更すればいいだけだろ（どや）
→ 設定変えるだけだろ？瞬殺なのでは？（どや）
→ ２０００年問題だって、アレアだけ騒動になったけどなんともなかったじゃん？
サマータイムもなんともないよ。他の国ではやってるんだろ？（どや）
・経済評論家？ その他一般的な記事？
サマータイム導入→？？？？億円の経済効果が見込める（どや）
サマータイム導入→ 競技開始が２時間早まる 朝の競技はより涼しい時間に始まる
→ 夕方の涼しい時間に始まるはずの競技は２時間早まりより暑い時間に始まってしまうという課題がある（コントかね
・経営陣
サマータイム導入 → システム対応に向けた IT予算投資 → ２年後には単なるムダ金なのでは？？
・公共交通機関系
サマータイム導入 → え？え？ 始発時間２時間繰り上げないといけないの？
・本当に賢い人々
サマータイム導入とか変なこと言ってないで、オリンピックを ９月開催に期間変更すればよいだけでは？
※ 脚色多めです。話半分で。
それはさておき。サマータイムってそもそもなんだっけかのおさらい。
夏時間とか、サマータイムとか、Daylight Saving Time (DST) と呼ばれたりしているけれども、
この仕組みの本質は 暑いかどうかなんて一切考慮されてないことを忘れてるんじゃないかね。
夏場に日照時間が長くなることから、
朝、明るいのに寝てるとか、まだ早いけど明るいから目が覚めて、通学・通勤時間まで二度寝しにくくて時間勿体なくね？
夕方、学校、仕事終わってもまだ外明るいんだけれどもそんなに時間残ってないから楽しめないよね？
よし、それなら １時間前倒しにしたら、１時間早起きしても外明るいし、通学・通勤出来るね？
通常時間帯よりも１時間早く 学校・仕事が終わるから、自由時間開始から日没までの時間が１時間伸びるよね？
(1時間の Daylight Saving) よっしゃ、遊びんさい！
である。
無論、正しい見解ではないかもしれないが、なんかこんなノリの制度であったはず。
大事なのは、暑いから、涼しいから、という見解はどこにも挟まってないことだ。
つまり暑さ対策でサマータイムを導入云々は対策したいことと方法論のミスマッチも甚だしいという。
なんでサマータイム案なんて浮上したんだ。大丈夫かね、一応エラい立ち位置にいる人々は。
それはそれとして、この東京オリンピックのためのサマータイムを導入せざるを得ないとなった場合に
どのステップで対処していかざるを得ないのか。
時刻情報としてサマータイムを実装する仕組みのベースとしては、海外でサマータイムが実用されていたりすることから
ある程度 OS 部分で実装済みとも言えなくもない。
サマータイムが何時から有効になって何時無効になるのかは、どうやら Time Zone データベースに列挙されている模様。
Windows ならレジストリ、 Linux ベースシステムなら OS 定義ファイル。
Time Zone の 名称に、ルールが紐づいて定義されていて、システムがそれをうまく見て処理する。
仮に Time Zone ： "SHIMSOFT Daylight Time"/ "SDT" と定義し、
ルールとして 開始：2019/7/1 0:00 終了 2019/9/1 0:00 保存時間 2:00
という風なものを追加しておく。
このとき、コンピューターで Time Zone "SHIMSOFT Daylight Time" or "SDT" を選択しておいた場合、
2019/7/1 0:00 になった瞬間、夏時間設定が働いて 2時間先送りされ時計情報は 2019/7/1 2:00 を返すようになり、
0:00～2:00 までは消失する。
2019/9/1 0:00 になった瞬間、夏時間設定が解除されて 2時間戻されて時計情報は 2019/8/31 22:00 を返すようになる。
2019/8/31 22:00～ 9/1 0:00 までの２時間は、２度繰り返される。システム的にはタイムリープする。
これ、各自でそれぞれに定義を作って差し込んでも出来るんだろうけれど、
Windows は多分 Windows Update で夏時間設定関連の更新かかったら勝手になくなるし
新しい PC や サーバー設定するたびに忘れずに定義を追加設定しないといけないし、面倒であること間違いなし。
Linux 関連もそうだろうし、目的が 東京オリンピックにまつわる、であれば世界的に定義を広めなくてはならないので、
主要な OS 提供メーカーに OS レベルで組み込んでもらう必要があるのだろうね。
Windows で言えば Microsoft さんにお願いして 日本のオリンピック対応用のタイムゾーン定義入れて世界共通設定で配って～
ていう話である。
Linux で言えば主要ディストリビューターに？、 Mac OS / iOS は Apple に、 Android は Google に。
Windows Update を容易に当てられない環境にある Windows 機にはまず降ってこない更新になるのだろうし、
Android は Google さんが超迅速もぁくぃっくりぃ に対応してくださっても、ハードウェアベンダー/携帯キャリアーが更新配れないとなったら
よもやの Time Zone 対応のために機種変更を迫られるのである。
まぁ、そのハードルが超えられて Time Zone 定義を配られたとしよう。
多分、OS は正しく定義ファイルさえ入ればサマータイムは動くだろうね。
その上のアプリ、大丈夫かね？
失われる２時間は多分、大きな問題になりにくい。
普段でもシステムの時計が NTP などで同期出来ておらず時刻ずれしていた場合においても、手動で未来の時間に手直しすることはあまり問題にならないケースが多い。
ただ、失われる時間に動くはずだったスケジュールジョブの類が動かない、同時に動いてはいけないジョブが同時に動き出すなどの
システムトラブル時に併発しそうな問題が時間制御問題で発生する可能性は否めない。
スケジュールジョブの時間が、内部的に Time Zone に依存せず GMT で動くトリガーに変換されていたら大丈夫かもしれないけれど。
重複する２時間は多分、致命的である。
データベースやなんかで時系列処理が重要視されるものは、過去時間に戻るリスクはかなり高い。
スケジュールジョブ的なものが 同じジョブが二度動いてしまうなどの不具合が起こる可能性がある。
スケジュールジョブの時間が、内部的に Time Zone に依存せず GMT で動くトリガーに変換されていたら大丈夫かもしれないけれど。
アプリケーション上で、日付や日時を記録する部分の対応。
もし、GMT での記録ではなくて Time Zone 設定に基づいて得られる時計情報を元にデータ登録するものであれば、
重複する２時間のデータは、時系列に整列させにくい状態になり得る。
これはデータ中の整合性を欠く可能性がでてくるわけで、アプリケーションの作りによる。
まぁ、クライアントアプリを操作する端末の時計便りで時間フィールドを埋める場合で、
Time Zone を意識して作ってありますとかいうのがどれだけあるか、、、
アプリケーション、業務システムが 出来合いのパッケージシステムであるなら、パッケージシステムのベンダーが何らかの対処を準備し
そのパッチなり適用に向けて業務システム計画停止などおろおろしなくてはならないんだろう。
オリンピック後には意味ない無駄仕様対応のために。
まぁ、現実路線で行くと、今検討されているサマータイム対応（朝を２時間早くしたい）のは
オリンピック対応圏内の話であるし（サマータイム対応効果があるかないかは別問題として）、
アプリケーション・システムとして改修対応が現実的ではない場合も想定し、
東京オリンピック期間想定のサマータイム実装に「強制力はないものとし、使いたい人は使ってみたらいい」程度に
法令？条例？政令？準備したきゃしてもらって、賢者は使用しない。
Time Zone のコード表記を取りまとめている標準化機構があるのかどうか良く分からなかったが、
既存の「Tokyo Standard Time」や「JST」、製品によっては「Japan」や「Tokyo, Osaka, Sapporo」て出てくる奴の定義は
変更せず、サマータイム対応困難、もしくは対応拒否システムの従来環境様に手を入れず、
新規に「Tokyo Daylight Time」「JDT」、「Japan DST」「Tokyo, Osaka, Sapporo DST」 など新しいコードを取得して貰って
東京オリンピック用夏時間に対応したい、対応可能なシステムだけ新しい Time Zone コードを各自任意で選択する方式
として貰う。
これが現実解でしょうな。
無論、こんな苦労してサマータイム対応したとして、競技選手の競技中が涼しくなることはない。
これの対応のためにパッチ適用作業などに費用投資をした企業のお財布だけが涼しくなる。
「弊社社内システム日本の夏時間に対応しております！」は何の売り文句にもならなくて
物が売れたりして儲かる余地は何もないのに、投資させられて、東京オリンピック後には二度と使わないムダ金。
概ねみんな サマータイム対応拒否選択で何事も起こらんじゃろ。
もし、お偉いがたがとちくるって 既存の Time Zone コードの定義変更させて、システムに強制的に東京オリンピックサマータイムが
無条件に発動する羽目になった場合で、システムデータ上に致命的な損害が出た場合は
お国相手に損害賠償請求と化するしかないんでしょうね、、、面倒だからそれはやめて欲しいなぁ、、、
