アカウント名:
パスワード:
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
米国在住の米国人で、ソフトウェア技術者をやってます。夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、表示のときのみローカルタイムに変換するという形でこの手の対応をしています。データ集計等は全て UTC で行います。IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
> 夏時間の他にタイムゾーンの時差も似たような問題を起こします。
そういえばあっちじゃ普通すぎて話題にも上らないけど、大陸横断したら普通にタイムゾーンが違って数時間ズレるんだっけ。グレハン旅行した時，到着時刻が現地時間で「午前二時」とか書いてあっても、自分の腕時計は出発側のタイムゾーンのままだったから、到着するのがあと10分なのか1時間10分なのかも分からなくて困った。
日本国内じゃ、バスや鉄道で国内を移動してるだけなのに、「ここから隣のタイムゾーンだから腕時計1時間巻き戻さなくっちゃ」みたいなことは想像しにくい。そういうのは外国旅行の話だもの＃さらにそこに夏時間のコンボ。うへえ。
この前のEU圏の夏時間から冬時間の切り替え直前に飛行機に乗ったんだけど、機内情報システムの出発地の時刻がちゃんと冬時間に切り替わったのをみて、当たり前だけど感動したわ
表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか？単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。
#3512084 の者です。
私のところでは、元々１日１回実行していたようなバッチでも、実際には実行頻度を上げられる物が多いです。それらは１日に６回とか１２回とか実行するようにしています。最後に実行したのがいつなのか、どのタイムゾーンをベースにしたのか、サマータイムで１時間ずれた、といったことを利用者が意識しなくなっていきます。このような形に慣れた利用者は実行時刻を気にしなくなってくれるので、不具合等で１回実行されなかった場合でも修正して実行し直せば済むだけになることが多く、運用の手間が減ります。
昨日の広告の成果のデータ集計のように、１日にちょうど
データを記録するだけのソフトウェアならそういう運用もありかと思うが、毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンからデイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい？
#3512358 にも数パターン書かせて頂きましたが、それ以外のポイントとしては、うちでは、全ての処理を私が管理する１００台程度の AWS 上のサーバ群で実行しており、従業員の端末やオフィスにある端末で実行する物はありませんね。
ですので、ローカル時間を意識するのは、せいぜい従業員の勤務時間に合わせて東海岸の午前５時に当たる時間に実行する、といった程度で済んでいます。
一番運用が楽になるパターンは、やはり実行頻度を上げるものですね。
オンプレミスで実行するかどうかなんて話はしていないけど。「ローカル時間に合わせて」実行する必要があるものは、UTC管理だと困るんじゃね？という話をしているのよ。
で、その「ローカル時間を意識する」、「せいぜい」のケースの処理はどういう具合に？やっぱり半年毎に手作業でずらす、とか？ｗ
UTCで記録されてても、「ローカルのhh:mmか」のチェックだけだと、ですね。
単発アクションでも、「夏時間で飛ぶ時間内だと不発(ローカル時間にxx:xxが存在しないので)」「夏時間で戻って2発(ローカル時間のyy:yyが1日に2度ある)」がないようにするのは、どうしてるのか、は気になるよね
# ほんとうに局所化できれてれば、たぶんそこで「存在する時間内で前発動」とか「2回やらないかチェックする」とかすればいいかもだけど...
なるほど。質問の意図を理解できていませんでした。
避けていますね。ローカル時間の特定の hh:mm に実行する、という要件を。そのような必要性がないように仕様を詰めています。今まで全て簡単に説得できてきました。
カスタマーをプログラマの技量に合わせさせているわけかｗ
なぜそう見下すような発言をするかね。
一連のコメントにはプログラマの技量が足りないと断言できるような内容は無い。
むしろ、カスタマーの要求をなんでも鵜呑みにして複雑でメンテ不能なシステムにしてしまわずに、きちんと要件を把握して必要な機能を取捨選択できる、良い技術力を持った人物であることが伺えるのだが。
> 米国在住の米国人で、ソフトウェア技術者をやってます。 slashdot.orgで十分だろうに、なぜこんな場末を覗いてるんだろう...？
日本語に触れていないと忘れてしまうからです。
時間情報はUTCで記録/処理して、現場で表示するときだけその場の時間帯に修正するとか？
電子カルテの場合、1970年以前の治療記録を持つ年寄りのデータはUTCでは困る。(過去の紙データを電子化している場合だが。)
・UTCはタイムゾーンの話で、1970年は関係ないのでは？・POSIX Time の話だとしたら、Unix Epochからの経過秒数を負の数にすれば対応できそう
現行の協定世界時の起点は確かに1972年1月1日だけどそれを起点にグレゴリオ歴をベースに過去に一日単位で戻していく分には問題ないだろう?さすがにもう天保暦の時代に生きていたひとの事は考慮しなくてもいいだろう。そういう古い紙カルテを電子化したデータで秒単位以下の制度が問題になることは実際にあり得るのか?
カルテの保存義務期間は5年なので、まず問題にはなりませんよ。そんな古い紙カルテはまず残っていないので。
#正確には診療終了後5年
初診が1964年の持病があってここの先生に50年間以上ずっとお世話に、なんてあったらアウトじゃないの
宮内庁病院とか広島赤十字・原爆病院とか日本赤十字社長崎原爆病院とかには、そんな古い紙カルテが普通にあるだろう。
診療終了後５年たったカルテを探してして廃棄する医療機関は、おそらく多くないです。探して廃棄するのが手間ということと、廃棄してしまうとその後再診したときに困る可能性があるからです。
カルテ保管庫が狭くて泣く泣く廃棄することはあると思いますが、「まず残っていない」はあり得ないです。
夏時間の開始/終了とシフト時間がどうだったのか該当システムで後から確認するのは困難なケースが考えられるので、
時刻の記録には、例えばUTCに加えて、その時刻が夏時間かどうか、夏時間の場合は何分シフトしているのかも分かるように同時に記録しておいた方が無難
金融系のソフトは市場が開いてない週末にメンテして対応してるから問題ないが、医療系はどうなってるのか
明け方に、縮退運用に切り替えてメンテするのが通例かと。
内部的にはUTC管理で表示とかでローカルタイムが必要な時だけ設定しておいたタイムゾーンに従って変換というのはありますね。
シンプルなのは内部的にはUTCで管理して、UI入出力だけ夏時間にする。ただ、毎朝N時みたいな現地時間に従属する項目は項目別に適切な対処が必要。夏時間中は夏時間分実施時刻をずらす(夏時間を無視する)なら入出力時に夏時間を換算するだけで済むけど……
ていうかこのストーリーの事例でも、システムを夏時間のないタイムゾーン設定して夏時間中はユーザが読み替えればいいようにも思う。定時検診とかの時刻は非夏時間ベースのが良いだろうし……
病院内などの限定された範囲ですむならそれで良さそうですが、外部とやり取りするときに混乱することになると思います。
その方法だと、外部とのやりとりの変換コストや間違い発生リスクの方が問題になりそうです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
実際のところ、夏時間対応済みのソフトは (スコア:0)
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
Re:実際のところ、夏時間対応済みのソフトは (スコア:5, 興味深い)
米国在住の米国人で、ソフトウェア技術者をやってます。
夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、
表示のときのみローカルタイムに変換するという形でこの手の対応をしています。
データ集計等は全て UTC で行います。
IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
Re: (スコア:0)
> 夏時間の他にタイムゾーンの時差も似たような問題を起こします。
そういえばあっちじゃ普通すぎて話題にも上らないけど、大陸横断したら普通にタイムゾーンが
違って数時間ズレるんだっけ。グレハン旅行した時，到着時刻が現地時間で「午前二時」とか書いて
あっても、自分の腕時計は出発側のタイムゾーンのままだったから、到着するのがあと10分なのか
1時間10分なのかも分からなくて困った。
日本国内じゃ、バスや鉄道で国内を移動してるだけなのに、
「ここから隣のタイムゾーンだから腕時計1時間巻き戻さなくっちゃ」
みたいなことは想像しにくい。そういうのは外国旅行の話だもの
＃さらにそこに夏時間のコンボ。うへえ。
Re: (スコア:0)
この前のEU圏の夏時間から冬時間の切り替え直前に飛行機に乗ったんだけど、
機内情報システムの出発地の時刻がちゃんと冬時間に切り替わったのをみて、当たり前だけど感動したわ
Re: (スコア:0)
表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか？
単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。
Re: (スコア:0)
#3512084 の者です。
私のところでは、元々１日１回実行していたようなバッチでも、
実際には実行頻度を上げられる物が多いです。
それらは１日に６回とか１２回とか実行するようにしています。
最後に実行したのがいつなのか、
どのタイムゾーンをベースにしたのか、
サマータイムで１時間ずれた、
といったことを利用者が意識しなくなっていきます。
このような形に慣れた利用者は実行時刻を気にしなくなってくれるので、
不具合等で１回実行されなかった場合でも
修正して実行し直せば済むだけになることが多く、
運用の手間が減ります。
昨日の広告の成果のデータ集計のように、
１日にちょうど
Re: (スコア:0)
データを記録するだけのソフトウェアならそういう運用もありかと思うが、
毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、
UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンから
デイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい？
Re: (スコア:0)
#3512358 にも数パターン書かせて頂きましたが、それ以外のポイントとしては、
うちでは、全ての処理を私が管理する１００台程度の AWS 上のサーバ群で実行しており、
従業員の端末やオフィスにある端末で実行する物はありませんね。
ですので、ローカル時間を意識するのは、
せいぜい従業員の勤務時間に合わせて東海岸の午前５時に当たる時間に実行する、
といった程度で済んでいます。
一番運用が楽になるパターンは、やはり実行頻度を上げるものですね。
Re: (スコア:0)
オンプレミスで実行するかどうかなんて話はしていないけど。
「ローカル時間に合わせて」実行する必要があるものは、UTC管理だと困るんじゃね？という話をしているのよ。
で、その「ローカル時間を意識する」、「せいぜい」のケースの処理はどういう具合に？
やっぱり半年毎に手作業でずらす、とか？ｗ
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
UTCで記録されてても、「ローカルのhh:mmか」のチェックだけだと、ですね。
単発アクションでも、「夏時間で飛ぶ時間内だと不発(ローカル時間にxx:xxが存在しないので)」「夏時間で戻って2発(ローカル時間のyy:yyが1日に2度ある)」がないようにするのは、どうしてるのか、は気になるよね
# ほんとうに局所化できれてれば、たぶんそこで「存在する時間内で前発動」とか「2回やらないかチェックする」とかすればいいかもだけど...
M-FalconSky (暑いか寒い)
Re: (スコア:0)
なるほど。質問の意図を理解できていませんでした。
避けていますね。ローカル時間の特定の hh:mm に実行する、という要件を。
そのような必要性がないように仕様を詰めています。
今まで全て簡単に説得できてきました。
Re: (スコア:0)
カスタマーをプログラマの技量に合わせさせているわけかｗ
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
なぜそう見下すような発言をするかね。
一連のコメントにはプログラマの技量が足りないと断言できるような内容は無い。
むしろ、カスタマーの要求をなんでも鵜呑みにして複雑でメンテ不能なシステムにしてしまわずに、きちんと要件を把握して必要な機能を取捨選択できる、良い技術力を持った人物であることが伺えるのだが。
Re: (スコア:0)
> 米国在住の米国人で、ソフトウェア技術者をやってます。
slashdot.orgで十分だろうに、なぜこんな場末を覗いてるんだろう...？
Re: (スコア:0)
日本語に触れていないと忘れてしまうからです。
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
時間情報はUTCで記録/処理して、現場で表示するときだけその場の時間帯に修正するとか？
Re: (スコア:0)
電子カルテの場合、1970年以前の治療記録を持つ年寄りのデータはUTCでは困る。
(過去の紙データを電子化している場合だが。)
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
・UTCはタイムゾーンの話で、1970年は関係ないのでは？
・POSIX Time の話だとしたら、Unix Epochからの経過秒数を負の数にすれば対応できそう
Re: (スコア:0)
現行の協定世界時の起点は確かに1972年1月1日だけどそれを起点にグレゴリオ歴をベースに過去に一日単位で戻していく分には問題ないだろう?
さすがにもう天保暦の時代に生きていたひとの事は考慮しなくてもいいだろう。
そういう古い紙カルテを電子化したデータで秒単位以下の制度が問題になることは実際にあり得るのか?
Re: (スコア:0)
カルテの保存義務期間は5年なので、まず問題にはなりませんよ。
そんな古い紙カルテはまず残っていないので。
#正確には診療終了後5年
Re: (スコア:0)
初診が1964年の持病があってここの先生に50年間以上ずっとお世話に、なんてあったらアウトじゃないの
Re: (スコア:0)
宮内庁病院とか広島赤十字・原爆病院とか日本赤十字社長崎原爆病院とかには、そんな古い紙カルテが普通にあるだろう。
Re: (スコア:0)
診療終了後５年たったカルテを探してして廃棄する医療機関は、おそらく多くないです。
探して廃棄するのが手間ということと、廃棄してしまうとその後再診したときに困る可能性があるからです。
カルテ保管庫が狭くて泣く泣く廃棄することはあると思いますが、「まず残っていない」はあり得ないです。
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
夏時間の開始/終了とシフト時間がどうだったのか該当システムで後から確認するのは困難なケースが考えられるので、
時刻の記録には、例えばUTCに加えて、その時刻が夏時間かどうか、夏時間の場合は何分シフトしているのかも分かるように
同時に記録しておいた方が無難
Re: (スコア:0)
金融系のソフトは市場が開いてない週末にメンテして対応してるから問題ないが、
医療系はどうなってるのか
Re: (スコア:0)
明け方に、縮退運用に切り替えてメンテするのが通例かと。
Re: (スコア:0)
内部的にはUTC管理で表示とかでローカルタイムが必要な時だけ設定しておいたタイムゾーンに従って変換というのはありますね。
Re: (スコア:0)
シンプルなのは内部的にはUTCで管理して、UI入出力だけ夏時間にする。
ただ、毎朝N時みたいな現地時間に従属する項目は項目別に適切な対処が必要。
夏時間中は夏時間分実施時刻をずらす(夏時間を無視する)なら入出力時に夏時間を換算するだけで済むけど……
ていうかこのストーリーの事例でも、システムを夏時間のないタイムゾーン設定して夏時間中はユーザが読み替えればいいようにも思う。
定時検診とかの時刻は非夏時間ベースのが良いだろうし……
Re: (スコア:0)
病院内などの限定された範囲ですむならそれで良さそうですが、
外部とやり取りするときに混乱することになると思います。
その方法だと、外部とのやりとりの変換コストや間違い発生リスクの方が
問題になりそうです。