サマータイム、IT分野では、単に時間の調整だけでは済まないという話
1. GMT(グリニッジグリニッジ標準時)からの計算ルーチンが必要になる
これは分かると思う、世界標準時から、日本時間にするのが単に9時間足せばいいだけではなくなるので大変だ。
多分、殆どの人はこの程度の修正でIT分野は住むのではないかと思ってるはずだ。
例えば、 IsDST みたいな関数で、夏時間が適用されてるかどうかという処理が必要になる。
こうしないと、累積時間を計算をするときに2時間狂ってしまう。
2. JST(日本標準時) に加えて JDT(日本夏時間) の定義が必要になりそれを使わなくてはいけない
これが実は凄く厄介だ。
夏時間には、 スプリング フォワード(春季に2時間進める)とフォール バック(秋期に2時間戻す)処理に関する問題があって、例えば、 スプリング フォワード で午前 1時から3時にスキップする決まりになった場合、 この日の 午前 1時から2時59分59秒 が指定された場合は無効にする処理を入れなくてはいけない
問題は、フォールバックだ。
この日 午前3時になったら、午前1時に戻す決まりになったとすると、
この日の午前1時から2時59分59秒までの時間帯は2重に存在する。
これを回避するために、海外では、コンピュータの時刻管理に、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. 海外との時差が変わる!
日本が海外の時刻との差を考える時ももちろんそうなのだが…。それだけにとどまらない。
どういう事かというと、海外から日本の時差を考慮する必要が生まれる。
例えば、海外の株式取引上のシステム、開場時間などが2時間狂ったまま処理をすると、大損害を出す可能性もある。
要するに、日本だけではなく、海外のシステムにも迷惑がかかるのだ
他国への迷惑なんて考えてなかった?
まさか、その為の費用も税金で賄うんじゃないでしょうね?・ω・
4. 2年限定で、ルールを元に戻す方針!?
毎年運用ルールが固定化されるのであれば、この仕様変更は必要なので、全てのIT 分野で修正が行われるだろう。
しかし、時限的なものなので、適用間に合わなかったから、そのまま放置してしまおう、なんてシステムが出てきたらさぁたいへん。
そのシステムが、JDT に対応しているかどうかで処理が変わってしまう!・ω・
自社のシステムが全部サマータイムに対応してても、お客さんのシステムが対応してなくて、事故につながることだって考えられる。
2000年問題は恒久的な問題だったから、曜日がずれたまま運用するなんてことは考えられなかったけど、一時的な変更だと、絶対、運用でカバーなんてシステムが出て来るのは目に見えている ・ω・
対応してるシステムと対応してないシステムが連携すると大混乱になると思うよ!
5. 子供や老人や病気向けの人のソリューションと、例のない2時間のサマータイム
実は、海外では、子供や赤ちゃん、病人など向けに
いきなり1時間生活のリズムを変えることを強要せずに、
15分ずつ、起床時間や就寝時間をスライドさせて負担を減らそうっていう試みが行われている国もあるよ! ・ω・
普通のサマータイムは1時間だから、4日かけてフォールバックやスプリングフォワードに対応することになる。
ところが、日本では ソ連占領地域のベルリン位しか前例のない2時間のサマータイムを導入しようとしています。
いきなり次の日から2時間起床・就寝時間が早くなったり、遅くなったりするのを強いるわけではないのなら、
1週間かけて 2時間ずらす処理を入れなくてはいけないのだ!
うわー、面戸臭い!!!
2000年問題の時は、はっきり言って1だけよかったのですが、サマータイム対応だと、数倍大変なのがお分かりいただけるでしょうか?
さぁ、これ、見てもまだ本気で導入できるって主張する IT関係者おりゅ? (((((・ω・)))))
1か月かけて1日4分ずらしていくよ! …とか、非搭載時計のほうが売れる予感。
時間外・深夜残業の計算にも響くし。
…正直、搭載するとなれば、不定時法対応のほうがマシなのではと考える。
過去に学んでないなあ、提案者は。