アカウント名:
パスワード:
ソフトウェアサービスだと、タイムゾーンへの対応は当然行いますよ。内部では UTC で管理して、見せる方は Localtime にするってことですよね。表示の変更はユーザが選ぶようにしてるので、自動にはあえてしなくてもいいかなと。きりがないので。
過去の時刻を参照するとき、その時点の時刻がサマータイムに該当するか照会しなければいけないので今あるソフトはほぼすべて見直しが必要。
ちなみにWindowsのLocalTimeToFileTimeは、いつの時刻を渡しても現在サマータイムかどうかに応じて変換するというたいへん漢らしい仕様です。
なお、ちゃんとその年の情報を見て変換する関数TzSpecificLocalTimeToSystemTimeなども存在します。DST を含む日付と時刻の処理方法 [microsoft.com]:特定のアップデートを適用したWindows XP/Server 2003から使えます。
そんじゃ直さなくてもいいか。これは仕様です。マイクロソフトも同様に処理しています。キリッ。とか言えばいいのかな。
で、日本がサマータイム対応になった時にサポート終了しているWindowsにサマータイム対応のパッチが提供されなくて、泣くことになるわけだ。
案外これがサマータイム導入断念の決定的な理由になるかもしれん。
だから文字列化するのは表示のときだけで内部は全部UTCであるべき。
内部がUTCならいいんだけどとくに日本国内向けのサービスだとたいていJSTになっていて阿鼻叫喚
おまえらもしかしてタダでやろうと思っているの?阿鼻叫喚にならないようにカネとるんだよ、カネ。
…って言えたらいいのにな。
いえ、タダでやらせようと思っている人たちがいます。ていうかノーコストで導入できると思っていそうな人たちが永田町あたりにいそうでマジ怖いです。
永田町だけじゃないだろ。そこいら中にいるとおもうぞ。自分とこの営業にもいるんじゃないか?客が「その予算がない」っていうと、すぐにとんでもない金額で勝手に口約束する奴とか。
営業には日本中の企業にそれを半強制するような権限はないので
特に出力ファイルやログデータにローカルタイムのHHMMSSが含まれていたら、ソートが狂ったりファイル名が衝突したり悲惨ですね。
バッチが飛ばされたり2回実行されたりとかもありそうです。
バッチ扱うようなシステムだと、通常アプリケーション日付ってのもありませんか?日付が 05:00 JST で切り替わる(○月×日は、5:00 から 29:59 までになる)ようなやつ。
これはUTCならいいとかそういう問題じゃないんだ。時差をoffset=new Date('Z');epochLocaltime=UtcLocaltime+offset;
みたいにしてとっているとき、それが違う標準時で適用されていないか、つまり最初に取った値をずっと使うような処理になっていないか調べないといけない。そして、today=new Date();yesterday=today.clone();yesterday.day=today.day-1;dateString=yesterday.toStr();
みたいになっているとき、処理系の中で使われる標準時はnew()したときのものかtoStr()したときのものか調べないといけない。結局、全部のプログラムを見
内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの?そもそも時刻を文字列で扱うべきじゃないし。
その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので全部検討し直しから始めないといけないということ。#今は一つしかないのでぞんざいに扱っても露見しないだけ。
夏時間から元に戻るとき、1:59:59 の次が 1:00:00 になるなどの逆転現象が発生するので、一番地雷になりそう。NTPにしてもOS時間カウンタにしても、逆戻りするといろいろヤッカイなので単調増加+進み具合で調整にしているわけで。
サマータイム突入時と終了時はアメリカだってトラブル起きるのに何言ってんだ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
控えめな対応 (スコア:0)
ソフトウェアサービスだと、タイムゾーンへの対応は当然行いますよ。
内部では UTC で管理して、見せる方は Localtime にするってことですよね。
表示の変更はユーザが選ぶようにしてるので、自動にはあえてしなくてもいいかなと。
きりがないので。
Re:控えめな対応 (スコア:1)
過去の時刻を参照するとき、その時点の時刻がサマータイムに該当するか照会しなければいけないので
今あるソフトはほぼすべて見直しが必要。
Re:控えめな対応 (スコア:2, 興味深い)
ちなみにWindowsのLocalTimeToFileTimeは、いつの時刻を渡しても現在サマータイムかどうかに応じて変換するというたいへん漢らしい仕様です。
Re:控えめな対応 (スコア:1)
なお、ちゃんとその年の情報を見て変換する関数TzSpecificLocalTimeToSystemTimeなども存在します。DST を含む日付と時刻の処理方法 [microsoft.com]:特定のアップデートを適用したWindows XP/Server 2003から使えます。
Re: (スコア:0)
そんじゃ直さなくてもいいか。
これは仕様です。マイクロソフトも同様に処理しています。キリッ。とか言えばいいのかな。
Re: (スコア:0)
で、日本がサマータイム対応になった時にサポート終了しているWindowsにサマータイム対応のパッチが提供されなくて、泣くことになるわけだ。
Re: (スコア:0)
案外これがサマータイム導入断念の決定的な理由になるかもしれん。
Re:控えめな対応 (スコア:2)
Re: (スコア:0)
だから文字列化するのは表示のときだけで内部は全部UTCであるべき。
Re:控えめな対応 (スコア:2)
Re: (スコア:0)
内部がUTCならいいんだけどとくに日本国内向けのサービスだとたいていJSTになっていて阿鼻叫喚
Re:控えめな対応 (スコア:1)
おまえらもしかしてタダでやろうと思っているの?
阿鼻叫喚にならないようにカネとるんだよ、カネ。
…って言えたらいいのにな。
Re: (スコア:0)
いえ、タダでやらせようと思っている人たちがいます。
ていうかノーコストで導入できると思っていそうな人たちが永田町あたりにいそうでマジ怖いです。
Re: (スコア:0)
永田町だけじゃないだろ。
そこいら中にいるとおもうぞ。
自分とこの営業にもいるんじゃないか?
客が「その予算がない」っていうと、すぐにとんでもない金額で勝手に口約束する奴とか。
Re: (スコア:0)
営業には日本中の企業にそれを半強制するような権限はないので
Re: (スコア:0)
特に出力ファイルやログデータにローカルタイムのHHMMSSが含まれていたら、ソートが狂ったりファイル名が衝突したり悲惨ですね。
Re:控えめな対応 (スコア:1)
バッチが飛ばされたり2回実行されたりとかもありそうです。
Re:控えめな対応 (スコア:1)
バッチ扱うようなシステムだと、通常アプリケーション日付ってのもありませんか?
日付が 05:00 JST で切り替わる(○月×日は、5:00 から 29:59 までになる)ようなやつ。
Re: (スコア:0)
これはUTCならいいとかそういう問題じゃないんだ。
時差を
offset=new Date('Z');
epochLocaltime=UtcLocaltime+offset;
みたいにしてとっているとき、それが違う標準時で適用されていないか、つまり最初に取った値をずっと使うような処理になっていないか調べないといけない。
そして、
today=new Date();
yesterday=today.clone();
yesterday.day=today.day-1;
dateString=yesterday.toStr();
みたいになっているとき、処理系の中で使われる標準時はnew()したときのものかtoStr()したときのものか調べないといけない。
結局、全部のプログラムを見
Re:控えめな対応 (スコア:1)
内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの?
そもそも時刻を文字列で扱うべきじゃないし。
Re: (スコア:0)
その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので
全部検討し直しから始めないといけないということ。
#今は一つしかないのでぞんざいに扱っても露見しないだけ。
Re: (スコア:0)
夏時間から元に戻るとき、1:59:59 の次が 1:00:00 になるなどの逆転現象が発生するので、一番地雷になりそう。
NTPにしてもOS時間カウンタにしても、逆戻りするといろいろヤッカイなので単調増加+進み具合で調整にしているわけで。
Re: (スコア:0)
サマータイム突入時と終了時はアメリカだってトラブル起きるのに何言ってんだ?