「夏時間切り替え、苦労して導入する価値はある？」記事へのコメント

控えめな対応

[Anonymous Coward]

ソフトウェアサービスだと、タイムゾーンへの対応は当然行いますよ。
内部では UTC で管理して、見せる方は Localtime にするってことですよね。
表示の変更はユーザが選ぶようにしてるので、自動にはあえてしなくてもいいかなと。
きりがないので。

Re:控えめな対応

[Anonymous Coward]

過去の時刻を参照するとき、その時点の時刻がサマータイムに該当するか照会しなければいけないので
今あるソフトはほぼすべて見直しが必要。

Re:控えめな対応

[Anonymous Coward]

ちなみにWindowsのLocalTimeToFileTimeは、いつの時刻を渡しても現在サマータイムかどうかに応じて変換するというたいへん漢らしい仕様です。

Re:控えめな対応

[Egtra (38265)]

なお、ちゃんとその年の情報を見て変換する関数TzSpecificLocalTimeToSystemTimeなども存在します。DST を含む日付と時刻の処理方法 [microsoft.com]：特定のアップデートを適用したWindows XP/Server 2003から使えます。

Re:

[Anonymous Coward]

そんじゃ直さなくてもいいか。
これは仕様です。マイクロソフトも同様に処理しています。キリッ。とか言えばいいのかな。

Re:

[Anonymous Coward]

で、日本がサマータイム対応になった時にサポート終了しているWindowsにサマータイム対応のパッチが提供されなくて、泣くことになるわけだ。

Re:

[Anonymous Coward]

案外これがサマータイム導入断念の決定的な理由になるかもしれん。

Re:控えめな対応

[saitoh (10803)]

文字列表示の時刻→UTCなどへの変換が一意でなくなるとおもうのですが。夏時間が終わるときには1時間時刻が戻るわけですが、「11月2日午前1時30分」をUTCに変換するには情報が足りませんよね。

Re:

[Anonymous Coward]

だから文字列化するのは表示のときだけで内部は全部UTCであるべき。

Re:控えめな対応

[saitoh (10803)]

外部から文字列を与えられて内部表現に変換する部分を皆無にはできないですよね。 一旦人間が読めるように印刷出力する際にはUTCというわけにはいかないおんで。 たとえば(オンライン型ではない)タイムカードとか手書きの勤務簿の入力とか。