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

夏時間のせいで医療記録が飛ぶ」記事へのコメント

  • どんな対応をしているのでしょうか。

    なにもしないと時間ごとのデータ集計とかおかしくなりますよね。

    • by Anonymous Coward on 2018年11月08日 9時53分 (#3512084)

      米国在住の米国人で、ソフトウェア技術者をやってます。
      夏時間の他にタイムゾーンの時差も似たような問題を起こします。

      私のところでは、データベース等に記録する時間を全て UTC に統一し、
      表示のときのみローカルタイムに変換するという形でこの手の対応をしています。
      データ集計等は全て UTC で行います。
      IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。

      親コメント
      • by Anonymous Coward

        > 夏時間の他にタイムゾーンの時差も似たような問題を起こします。

        そういえばあっちじゃ普通すぎて話題にも上らないけど、大陸横断したら普通にタイムゾーンが
        違って数時間ズレるんだっけ。グレハン旅行した時,到着時刻が現地時間で「午前二時」とか書いて
        あっても、自分の腕時計は出発側のタイムゾーンのままだったから、到着するのがあと10分なのか
        1時間10分なのかも分からなくて困った。

        日本国内じゃ、バスや鉄道で国内を移動してるだけなのに、
        「ここから隣のタイムゾーンだから腕時計1時間巻き戻さなくっちゃ」
        みたいなことは想像しにくい。そういうのは外国旅行の話だもの
        #さらにそこに夏時間のコンボ。うへえ。

        • by Anonymous Coward

          この前のEU圏の夏時間から冬時間の切り替え直前に飛行機に乗ったんだけど、
          機内情報システムの出発地の時刻がちゃんと冬時間に切り替わったのをみて、当たり前だけど感動したわ

      • by Anonymous Coward

        表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか?
        単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。

        • by Anonymous Coward

          #3512084 の者です。

          私のところでは、元々1日1回実行していたようなバッチでも、
          実際には実行頻度を上げられる物が多いです。
          それらは1日に6回とか12回とか実行するようにしています。
          最後に実行したのがいつなのか、
          どのタイムゾーンをベースにしたのか、
          サマータイムで1時間ずれた、
          といったことを利用者が意識しなくなっていきます。
          このような形に慣れた利用者は実行時刻を気にしなくなってくれるので、
          不具合等で1回実行されなかった場合でも
          修正して実行し直せば済むだけになることが多く、
          運用の手間が減ります。

          昨日の広告の成果のデータ集計のように、
          1日にちょうど

      • by Anonymous Coward

        データを記録するだけのソフトウェアならそういう運用もありかと思うが、
        毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、
        UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンから
        デイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい?

        • by Anonymous Coward

          #3512358 にも数パターン書かせて頂きましたが、それ以外のポイントとしては、
          うちでは、全ての処理を私が管理する100台程度の AWS 上のサーバ群で実行しており、
          従業員の端末やオフィスにある端末で実行する物はありませんね。

          ですので、ローカル時間を意識するのは、
          せいぜい従業員の勤務時間に合わせて東海岸の午前5時に当たる時間に実行する、
          といった程度で済んでいます。

          一番運用が楽になるパターンは、やはり実行頻度を上げるものですね。

          • by Anonymous Coward

            オンプレミスで実行するかどうかなんて話はしていないけど。
            「ローカル時間に合わせて」実行する必要があるものは、UTC管理だと困るんじゃね?という話をしているのよ。

            で、その「ローカル時間を意識する」、「せいぜい」のケースの処理はどういう具合に?
            やっぱり半年毎に手作業でずらす、とか?w

            • UTCで記録されてても、「ローカルのhh:mmか」のチェックだけだと、ですね。

              単発アクションでも、「夏時間で飛ぶ時間内だと不発(ローカル時間にxx:xxが存在しないので)」「夏時間で戻って2発(ローカル時間のyy:yyが1日に2度ある)」がないようにするのは、どうしてるのか、は気になるよね

              # ほんとうに局所化できれてれば、たぶんそこで「存在する時間内で前発動」とか「2回やらないかチェックする」とかすればいいかもだけど...

              --
              M-FalconSky (暑いか寒い)
              親コメント
              • by Anonymous Coward

                なるほど。質問の意図を理解できていませんでした。

                避けていますね。ローカル時間の特定の hh:mm に実行する、という要件を。
                そのような必要性がないように仕様を詰めています。
                今まで全て簡単に説得できてきました。

              • by Anonymous Coward

                カスタマーをプログラマの技量に合わせさせているわけかw

              • by Anonymous Coward on 2018年11月09日 19時22分 (#3513089)

                なぜそう見下すような発言をするかね。

                一連のコメントにはプログラマの技量が足りないと断言できるような内容は無い。

                むしろ、カスタマーの要求をなんでも鵜呑みにして複雑でメンテ不能なシステムにしてしまわずに、きちんと要件を把握して必要な機能を取捨選択できる、良い技術力を持った人物であることが伺えるのだが。

                親コメント
      • by Anonymous Coward

        > 米国在住の米国人で、ソフトウェア技術者をやってます。
         
        slashdot.orgで十分だろうに、なぜこんな場末を覗いてるんだろう...?

        • by Anonymous Coward

          日本語に触れていないと忘れてしまうからです。

192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり

処理中...