日本における時差のシナリオに関してご意見をお聞かせください
早速解答していこう。
ユーザー設定のタイム ゾーンの作成（時間帯を、既定でコンピュータ上にあるもの以外に、プログラム的に作成すること）
必要。一つのアプリケーション内で複数のタイムゾーンを取り扱う可能性がある。SQL StringはSQLのコレーションをインスタンス毎に持つが、それと同じようにDateTime型のインスタンス毎に他忌むぞーを保持すればいいのではないか。
ユーザー設定のタイム ゾーンを恒久的にコンピュータ上に書き戻す
稼動中のコンピューターの現在のタイム ゾーンの変更
あればいいレベル。システムのタイムゾーンに関しては、WindowsのUIの改良により問題とならなくなるかもしれない。
サマー タイム設定を切った状態でタイム ゾーンのコピーの作成
サマー タイムのため、時計の時刻を前後した際のローカル タイムが未確定、もしくは曖昧／重複にあるかどうかを問い合わせる関数
必要性を感じさせるシナリオが考えついたけどレアケースかな。プラントの運用・監視システムのトレンド監視で必要になる可能性がある。（一時的にでも時刻が戻ったり重なってしまうことが問題となるケース）
歴史的経緯によって基本になる差分が年毎に変わったタイムゾーン（前述の夏時刻法に対する実装が関係してきます）
実際の法制度にはフレームワークの更新とは切り離して追従・対応していくべき。
スレッド単位、もしくはプロセス単位のアンビエント タイム ゾーン*1の設定
一行で簡潔に変換を可能にするヘルパ関数（TimeZone.Convert(time, “Pacific”, “Eastern”) のような）
DateTime型のインスタンス毎にタイムゾーンを持てば、そのようにする必要がない。
“PST”, “EDT”といったタイム ゾーンを組み込んだDateTimeに対する解析と書式設定
文字列に関しては全世界に対応できる略字が作れるか、そのような標準があるか問題となるかも。ただ、ToString()メソッドで適切な（理解できる）文字列が帰ってくることは必要。
こんなところ。
コメント