アカウント名:
パスワード:
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
米国在住の米国人で、ソフトウェア技術者をやってます。夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、表示のときのみローカルタイムに変換するという形でこの手の対応をしています。データ集計等は全て UTC で行います。IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか？単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。
#3512084 の者です。
私のところでは、元々１日１回実行していたようなバッチでも、実際には実行頻度を上げられる物が多いです。それらは１日に６回とか１２回とか実行するようにしています。最後に実行したのがいつなのか、どのタイムゾーンをベースにしたのか、サマータイムで１時間ずれた、といったことを利用者が意識しなくなっていきます。このような形に慣れた利用者は実行時刻を気にしなくなってくれるので、不具合等で１回実行されなかった場合でも修正して実行し直せば済むだけになることが多く、運用の手間が減ります。
昨日の広告の成果のデータ集計のように、１日にちょうど
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
実際のところ、夏時間対応済みのソフトは (スコア:0)
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
Re: (スコア:5, 興味深い)
米国在住の米国人で、ソフトウェア技術者をやってます。
夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、
表示のときのみローカルタイムに変換するという形でこの手の対応をしています。
データ集計等は全て UTC で行います。
IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
Re:実際のところ、夏時間対応済みのソフトは (スコア:0)
表示時刻は簡単に対応できるでしょうが、バッチ処理のスケジュールはどうしていますか？
単純にはUTCでスケジュールすれば良いように思いますが、利用時間がサマータイムでずれるのでUTCのままで大丈夫なのかは少し疑問です。
Re: (スコア:0)
#3512084 の者です。
私のところでは、元々１日１回実行していたようなバッチでも、
実際には実行頻度を上げられる物が多いです。
それらは１日に６回とか１２回とか実行するようにしています。
最後に実行したのがいつなのか、
どのタイムゾーンをベースにしたのか、
サマータイムで１時間ずれた、
といったことを利用者が意識しなくなっていきます。
このような形に慣れた利用者は実行時刻を気にしなくなってくれるので、
不具合等で１回実行されなかった場合でも
修正して実行し直せば済むだけになることが多く、
運用の手間が減ります。
昨日の広告の成果のデータ集計のように、
１日にちょうど