実は先日、8/1 に社内で異動しまして、18 年間続けてきたコンサルタントからクラウドソリューションアーキテクトにロールチェンジしました。さてこの blog もタイトルを変えるべきかどうなのか……とかまったり考えていたら、ここ数日、びっくりするような話題が飛び込んできました。
2020 年のオリンピックに向けて、限定的（または恒久的）にサマータイムを導入する、というもの。話を聞いたときに耳を疑ったのですが、いやもう絶対に不可能だろう、と私も思いました；。上記に取り上げた立命館大学の上原さんのスライドは非常によくまとまっていて、ホントこれ、と思いましたが、一方で Windows をはじめとするコンピュータシステムでそもそもサマータイムがどのような取り扱いになるのかを知らない人は多いのでは？、と思います。
実はずいぶん昔に国際化対応アプリケーションの開発方法を調べたことがあり、そのときにタイムゾーン（時差情報）をどのように取り扱うのか、をまとめたことがあります。おそらく皆様の参考になるのでは、と思いますので、若干手直しして情報共有してみます。10 年以上前の資料なので、画面のスナップショットがまさかの XP や Vista（！）だったりするのはご容赦、なのですが、考え方は特に変わっていないので、今でも普通に通用する内容かなと思います。（もし何か変わっているところがあったら教えていただけると嬉しいです；。）
ちょっと長いスライドなので、夏時間（サマータイム）という観点から要点を抜き出すと、以下の 2 つがポイントです。
① Windows OS 上では、夏時間はタイムゾーンの変更として取り扱われる (p.10)
夏時間に入る＝別の国のタイムゾーンに移動したのと同じようなこととして扱われます。イメージとしては、日本国内にいながら、時差のある国へ海外旅行に行ったのと同じような取り扱いになる、と考えるとわかりやすいかと思います。（なお、夏時間などのタイムゾーン情報はレジストリ情報として管理されており、Windows Update によりメンテナンスされています。なので本資料ではカバーしていませんが、 .NET Core で作ったアプリを Linux 上で動作させたりする場合にはまた別の注意が必要になってきます。）
② DateTime 型の加減算処理を行う際は、必ず UTC を介して行う (p.35, 36)
.NET Framework 上で日付をプログラミングする際、DateTime 型でプログラミングされている方が多いと思いますが、DateTime 型はオフセット値（UTC からの時差）を持つことができません。DateTime 型は、「見た目の数値」をそのまま加減算処理してしまうため、夏時間前後でのオフセット値の変化に対応できません。このため、DateTime 型で加減算処理を行う場合には、必ず UTC を介して計算する必要があります。（ちなみにこの問題に対応するために導入されたのが DateTimeOffset 型です。）
アメリカでは国内に主に 4 つのタイムゾーンがある上に夏時間まであるため、プログラミングを行う際にタイムゾーンを考慮したプログラミングを行うのは当然なのですが、日本国内の場合、長らく単一のタイムゾーンしかなかったため、タイムゾーンを考慮した形で設計・実装・テストされているシステムは非常に少ないでしょう。正直なところ、今の状況で夏時間が導入された場合のことを考えると、日本の開発の実情を知る自分としてはかなりぞっとします。（「うちのシステムは夏時間が導入されても大丈夫です！」と言える国内開発者はどれだけいるのだろうかと．．．．；）
2020 年に併せた夏時間の導入はあまりにも無茶すぎる、とエンジニア的な観点からは思いますが、とはいえこれからの IT エンジニアにとって、タイムゾーンや夏時間（サマータイム）を理解し、国際化対応アプリケーションを作る（海外でも動作するアプリを書く）ことは必須かと思います。この資料が、IT エンジニアのみなさんにとって、タイムゾーンや夏時間（サマータイム）を理解する一助になれば幸いです。