アカウント名:
パスワード:
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
米国在住の米国人で、ソフトウェア技術者をやってます。夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て 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で十分だろうに、なぜこんな場末を覗いてるんだろう...？
日本語に触れていないと忘れてしまうからです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
実際のところ、夏時間対応済みのソフトは (スコア: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)
日本語に触れていないと忘れてしまうからです。