.NET Fxにおけるタイムゾーン関連の改良

日本における時差のシナリオに関してご意見をお聞かせください
早速解答していこう。
ユーザー設定のタイム ゾーンの作成(時間帯を、既定でコンピュータ上にあるもの以外に、プログラム的に作成すること)

必要。一つのアプリケーション内で複数のタイムゾーンを取り扱う可能性がある。SQL StringはSQLのコレーションをインスタンス毎に持つが、それと同じようにDateTime型のインスタンス毎に他忌むぞーを保持すればいいのではないか。

ユーザー設定のタイム ゾーンを恒久的にコンピュータ上に書き戻す
稼動中のコンピューターの現在のタイム ゾーンの変更

あればいいレベル。システムのタイムゾーンに関しては、WindowsのUIの改良により問題とならなくなるかもしれない。

サマー タイム設定を切った状態でタイム ゾーンのコピーの作成
サマー タイムのため、時計の時刻を前後した際のローカル タイムが未確定、もしくは曖昧/重複にあるかどうかを問い合わせる関数

必要性を感じさせるシナリオが考えついたけどレアケースかな。プラントの運用・監視システムのトレンド監視で必要になる可能性がある。(一時的にでも時刻が戻ったり重なってしまうことが問題となるケース)

歴史的経緯によって基本になる差分が年毎に変わったタイムゾーン(前述の夏時刻法に対する実装が関係してきます)

実際の法制度にはフレームワークの更新とは切り離して追従・対応していくべき。

スレッド単位、もしくはプロセス単位のアンビエント タイム ゾーン*1の設定
一行で簡潔に変換を可能にするヘルパ関数(TimeZone.Convert(time, “Pacific”, “Eastern”) のような)

DateTime型のインスタンス毎にタイムゾーンを持てば、そのようにする必要がない。

“PST”, “EDT”といったタイム ゾーンを組み込んだDateTimeに対する解析と書式設定

文字列に関しては全世界に対応できる略字が作れるか、そのような標準があるか問題となるかも。ただ、ToString()メソッドで適切な(理解できる)文字列が帰ってくることは必要。

こんなところ。

コメントを残す