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

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

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

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

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

    • 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

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

    • 時間情報はUTCで記録/処理して、現場で表示するときだけその場の時間帯に修正するとか?

      親コメント
      • by Anonymous Coward

        電子カルテの場合、1970年以前の治療記録を持つ年寄りのデータはUTCでは困る。
        (過去の紙データを電子化している場合だが。)

        • ・UTCはタイムゾーンの話で、1970年は関係ないのでは?
          ・POSIX Time の話だとしたら、Unix Epochからの経過秒数を負の数にすれば対応できそう

          親コメント
        • by Anonymous Coward

          現行の協定世界時の起点は確かに1972年1月1日だけどそれを起点にグレゴリオ歴をベースに過去に一日単位で戻していく分には問題ないだろう?
          さすがにもう天保暦の時代に生きていたひとの事は考慮しなくてもいいだろう。
          そういう古い紙カルテを電子化したデータで秒単位以下の制度が問題になることは実際にあり得るのか?

        • by Anonymous Coward

          カルテの保存義務期間は5年なので、まず問題にはなりませんよ。
          そんな古い紙カルテはまず残っていないので。

          #正確には診療終了後5年

          • by Anonymous Coward

            初診が1964年の持病があってここの先生に50年間以上ずっとお世話に、なんてあったらアウトじゃないの

            • by Anonymous Coward

              宮内庁病院とか広島赤十字・原爆病院とか日本赤十字社長崎原爆病院とかには、そんな古い紙カルテが普通にあるだろう。

          • by Anonymous Coward

            診療終了後5年たったカルテを探してして廃棄する医療機関は、おそらく多くないです。
            探して廃棄するのが手間ということと、廃棄してしまうとその後再診したときに困る可能性があるからです。

            カルテ保管庫が狭くて泣く泣く廃棄することはあると思いますが、「まず残っていない」はあり得ないです。

    • by Anonymous Coward on 2018年11月08日 10時37分 (#3512109)

      夏時間の開始/終了とシフト時間がどうだったのか該当システムで後から確認するのは困難なケースが考えられるので、

      時刻の記録には、例えばUTCに加えて、その時刻が夏時間かどうか、夏時間の場合は何分シフトしているのかも分かるように
      同時に記録しておいた方が無難

      親コメント
    • by Anonymous Coward

      金融系のソフトは市場が開いてない週末にメンテして対応してるから問題ないが、
      医療系はどうなってるのか

      • by Anonymous Coward

        明け方に、縮退運用に切り替えてメンテするのが通例かと。

    • by Anonymous Coward

      内部的にはUTC管理で表示とかでローカルタイムが必要な時だけ設定しておいたタイムゾーンに従って変換というのはありますね。

    • by Anonymous Coward

      シンプルなのは内部的にはUTCで管理して、UI入出力だけ夏時間にする。
      ただ、毎朝N時みたいな現地時間に従属する項目は項目別に適切な対処が必要。
      夏時間中は夏時間分実施時刻をずらす(夏時間を無視する)なら入出力時に夏時間を換算するだけで済むけど……

      ていうかこのストーリーの事例でも、システムを夏時間のないタイムゾーン設定して夏時間中はユーザが読み替えればいいようにも思う。
      定時検診とかの時刻は非夏時間ベースのが良いだろうし……

      • by Anonymous Coward

        病院内などの限定された範囲ですむならそれで良さそうですが、
        外部とやり取りするときに混乱することになると思います。

        その方法だと、外部とのやりとりの変換コストや間違い発生リスクの方が
        問題になりそうです。

ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ

処理中...