アカウント名:
パスワード:
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
米国在住の米国人で、ソフトウェア技術者をやってます。夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、表示のときのみローカルタイムに変換するという形でこの手の対応をしています。データ集計等は全て UTC で行います。IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
データを記録するだけのソフトウェアならそういう運用もありかと思うが、毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンからデイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい?
#3512358 にも数パターン書かせて頂きましたが、それ以外のポイントとしては、うちでは、全ての処理を私が管理する100台程度の AWS 上のサーバ群で実行しており、従業員の端末やオフィスにある端末で実行する物はありませんね。
ですので、ローカル時間を意識するのは、せいぜい従業員の勤務時間に合わせて東海岸の午前5時に当たる時間に実行する、といった程度で済んでいます。
一番運用が楽になるパターンは、やはり実行頻度を上げるものですね。
オンプレミスで実行するかどうかなんて話はしていないけど。「ローカル時間に合わせて」実行する必要があるものは、UTC管理だと困るんじゃね?という話をしているのよ。
で、その「ローカル時間を意識する」、「せいぜい」のケースの処理はどういう具合に?やっぱり半年毎に手作業でずらす、とか?w
UTCで記録されてても、「ローカルのhh:mmか」のチェックだけだと、ですね。
単発アクションでも、「夏時間で飛ぶ時間内だと不発(ローカル時間にxx:xxが存在しないので)」「夏時間で戻って2発(ローカル時間のyy:yyが1日に2度ある)」がないようにするのは、どうしてるのか、は気になるよね
# ほんとうに局所化できれてれば、たぶんそこで「存在する時間内で前発動」とか「2回やらないかチェックする」とかすればいいかもだけど...
なるほど。質問の意図を理解できていませんでした。
避けていますね。ローカル時間の特定の hh:mm に実行する、という要件を。そのような必要性がないように仕様を詰めています。今まで全て簡単に説得できてきました。
カスタマーをプログラマの技量に合わせさせているわけかw
なぜそう見下すような発言をするかね。
一連のコメントにはプログラマの技量が足りないと断言できるような内容は無い。
むしろ、カスタマーの要求をなんでも鵜呑みにして複雑でメンテ不能なシステムにしてしまわずに、きちんと要件を把握して必要な機能を取捨選択できる、良い技術力を持った人物であることが伺えるのだが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
実際のところ、夏時間対応済みのソフトは (スコア:0)
どんな対応をしているのでしょうか。
なにもしないと時間ごとのデータ集計とかおかしくなりますよね。
Re: (スコア:5, 興味深い)
米国在住の米国人で、ソフトウェア技術者をやってます。
夏時間の他にタイムゾーンの時差も似たような問題を起こします。
私のところでは、データベース等に記録する時間を全て UTC に統一し、
表示のときのみローカルタイムに変換するという形でこの手の対応をしています。
データ集計等は全て UTC で行います。
IP アドレスからユーザのタイムゾーンを調べることができる有料データベースを使用しています。
Re: (スコア:0)
データを記録するだけのソフトウェアならそういう運用もありかと思うが、
毎日ローカル時間の決まった時刻に決まった動作をさせるというようなソフトだと、
UTCで時間を管理していると、ローカルでユーザーが起動時間を設定したシーズンから
デイライトセービングの状態が切り替わった時に、1時間ずれてしまったりしないかい?
Re: (スコア:0)
#3512358 にも数パターン書かせて頂きましたが、それ以外のポイントとしては、
うちでは、全ての処理を私が管理する100台程度の AWS 上のサーバ群で実行しており、
従業員の端末やオフィスにある端末で実行する物はありませんね。
ですので、ローカル時間を意識するのは、
せいぜい従業員の勤務時間に合わせて東海岸の午前5時に当たる時間に実行する、
といった程度で済んでいます。
一番運用が楽になるパターンは、やはり実行頻度を上げるものですね。
Re: (スコア:0)
オンプレミスで実行するかどうかなんて話はしていないけど。
「ローカル時間に合わせて」実行する必要があるものは、UTC管理だと困るんじゃね?という話をしているのよ。
で、その「ローカル時間を意識する」、「せいぜい」のケースの処理はどういう具合に?
やっぱり半年毎に手作業でずらす、とか?w
Re: (スコア:1)
UTCで記録されてても、「ローカルのhh:mmか」のチェックだけだと、ですね。
単発アクションでも、「夏時間で飛ぶ時間内だと不発(ローカル時間にxx:xxが存在しないので)」「夏時間で戻って2発(ローカル時間のyy:yyが1日に2度ある)」がないようにするのは、どうしてるのか、は気になるよね
# ほんとうに局所化できれてれば、たぶんそこで「存在する時間内で前発動」とか「2回やらないかチェックする」とかすればいいかもだけど...
M-FalconSky (暑いか寒い)
Re: (スコア:0)
なるほど。質問の意図を理解できていませんでした。
避けていますね。ローカル時間の特定の hh:mm に実行する、という要件を。
そのような必要性がないように仕様を詰めています。
今まで全て簡単に説得できてきました。
Re: (スコア:0)
カスタマーをプログラマの技量に合わせさせているわけかw
Re:実際のところ、夏時間対応済みのソフトは (スコア:1)
なぜそう見下すような発言をするかね。
一連のコメントにはプログラマの技量が足りないと断言できるような内容は無い。
むしろ、カスタマーの要求をなんでも鵜呑みにして複雑でメンテ不能なシステムにしてしまわずに、きちんと要件を把握して必要な機能を取捨選択できる、良い技術力を持った人物であることが伺えるのだが。