パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

  • by Anonymous Coward on 2014年11月02日 17時56分 (#2704880)

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

    • by Anonymous Coward on 2014年11月02日 20時42分 (#2704964)

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

      親コメント
      • by Anonymous Coward on 2014年11月02日 21時15分 (#2704982)

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

        親コメント
        • by Egtra (38265) on 2014年11月03日 18時32分 (#2705291)

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

          親コメント
        • by Anonymous Coward

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

        • by Anonymous Coward

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

          • by Anonymous Coward

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

      • by saitoh (10803) on 2014年11月04日 12時43分 (#2705618)
        文字列表示の時刻→UTCなどへの変換が一意でなくなるとおもうのですが。夏時間が終わるときには1時間時刻が戻るわけですが、「11月2日午前1時30分」をUTCに変換するには情報が足りませんよね。
        親コメント
        • by Anonymous Coward

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

          • by saitoh (10803) on 2014年11月10日 12時32分 (#2708699)
            外部から文字列を与えられて内部表現に変換する部分を皆無にはできないですよね。 一旦人間が読めるように印刷出力する際にはUTCというわけにはいかないおんで。 たとえば(オンライン型ではない)タイムカードとか手書きの勤務簿の入力とか。
            親コメント
    • by Anonymous Coward

      内部がUTCならいいんだけどとくに日本国内向けのサービスだとたいていJSTになっていて阿鼻叫喚

      • by Anonymous Coward on 2014年11月02日 19時40分 (#2704932)

        おまえらもしかしてタダでやろうと思っているの?
        阿鼻叫喚にならないようにカネとるんだよ、カネ。

        …って言えたらいいのにな。

        親コメント
        • by Anonymous Coward

          いえ、タダでやらせようと思っている人たちがいます。
          ていうかノーコストで導入できると思っていそうな人たちが永田町あたりにいそうでマジ怖いです。

          • by Anonymous Coward

            永田町だけじゃないだろ。
            そこいら中にいるとおもうぞ。
            自分とこの営業にもいるんじゃないか?
            客が「その予算がない」っていうと、すぐにとんでもない金額で勝手に口約束する奴とか。

            • by Anonymous Coward

              営業には日本中の企業にそれを半強制するような権限はないので

      • by Anonymous Coward

        特に出力ファイルやログデータにローカルタイムのHHMMSSが含まれていたら、ソートが狂ったりファイル名が衝突したり悲惨ですね。

      • by Anonymous Coward

        これはUTCならいいとかそういう問題じゃないんだ。
        時差を
        offset=new Date('Z');
        epochLocaltime=UtcLocaltime+offset;

        みたいにしてとっているとき、それが違う標準時で適用されていないか、つまり最初に取った値をずっと使うような処理になっていないか調べないといけない。
        そして、
        today=new Date();
        yesterday=today.clone();
        yesterday.day=today.day-1;
        dateString=yesterday.toStr();

        みたいになっているとき、処理系の中で使われる標準時はnew()したときのものかtoStr()したときのものか調べないといけない。
        結局、全部のプログラムを見

        • by nim (10479) on 2014年11月04日 10時31分 (#2705566)

          内部的にはすべてUNIX時間とかUTCで表現されていて、表示時のみローカルタイムに変換するようにしておけばいいんじゃないの?
          そもそも時刻を文字列で扱うべきじゃないし。

          親コメント
          • by Anonymous Coward

            その、ローカルタイムに変換する基準が2つあるというのがちゃんと理解されていないプログラムばかりなので
            全部検討し直しから始めないといけないということ。
            #今は一つしかないのでぞんざいに扱っても露見しないだけ。

      • by Anonymous Coward

        夏時間から元に戻るとき、1:59:59 の次が 1:00:00 になるなどの逆転現象が発生するので、一番地雷になりそう。
        NTPにしてもOS時間カウンタにしても、逆戻りするといろいろヤッカイなので単調増加+進み具合で調整にしているわけで。

    • by Anonymous Coward

      サマータイム突入時と終了時はアメリカだってトラブル起きるのに何言ってんだ?

身近な人の偉大さは半減する -- あるアレゲ人

処理中...