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

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

  • by Anonymous Coward

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

    • by Anonymous Coward

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

      • by Anonymous Coward on 2014年11月03日 10時35分 (#2705117)

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

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

        みたいになっているとき、処理系の中で使われる標準時はnew()したときのものかtoStr()したときのものか調べないといけない。
        結局、全部のプログラムを見直さないといけないというのと同じくらいボリュームあるんだ。

        2000年問題の再来くらいの処理なんだけど、システムの数が2000年から増えている。
        とてもただでなんかできないよ。

        #例はどの言語でも大体ありそうな記述にしただけで厳密にどれにならったというのはない、関数の名前とかは適当に解釈してください。

        親コメント
        • by nim (10479) on 2014年11月04日 10時31分 (#2705566)

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

          親コメント
          • by Anonymous Coward

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

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

処理中...