2016-04-24 16 views
0

分、時、日、月、年のバケットにデータを格納しています。すべてのデータはUTCで保存されます。時系列データとUTC変換

クライアントがタイムゾーンで4/23/2016 7:00pmという時間の合計を照会したい場合、クライアントは時間をUTC-4/24/2016 2:00amに変換し、照会を行います。参照のための画像。

Hour conversion from PDT to UTC

これは、時間と分バケットの完全に正常に動作します。しかし、クライアントが1日のバケットの合計を望む場合を見てみましょう。クライアントが4/24/2016の地元の日の娘を望む場合、彼らはまた、4/24/2016で解決するUTCに時間を変換するでしょう。 4/24/2016 UTCのバケツには、現地日の4/23/2016から7時間分のデータが含まれており、現地日の最後の7時間を逃しています4/24/2016。クエリが正しい合計を返さないため、これは問題のようです。 UTCの日の合計を返します。

この例で何か不足していますか?または時間間隔> 1時間にデータバケットを格納することは悪い考えですか?

答えて

1

日、月、年のバケットにはすべてタイムゾーンが設定されています(この場合はUTC0)。異なる時間帯の日/月/年の集約をレポートしたい場合、それは最終的には時間の集合であり、そのタイムゾーンの開始日と終了日の概念を使用して計算して保存する必要があります。

+0

これは私が考えていることです。これに共通のデザインパターンはありますか? –

+1

タイムゾーンを調整する必要がある場合、TZオフセットは正式なクエリパラメータになります。特定のタイムゾーンの日/月/年の集計を事前計算するか、タイムゾーンのためにオンザフライで行うかは、リソースと要件によって異なります。 – welch

0

この例でのユーザーの視点はPSTで、データはUTCで格納されているため、1日分の集計を表示することを願っています。私がPSTであれば、4/24にある時間に関係なく、1日分の集計を返すように選択すると、3月24日午前7時から3/25 7:00までUTCに照会することになりますpm。これがあなたの意図であれば、ユーザーが1日分のデータを合計するために選択した事実に基づいて、変更された開始日と終了日になります。数分、数時間、数日、数ヶ月でデータを保存するというデザインには何の問題もありません。

実際には1日分のデータを定義することは問題です。それは上記の24時間前または24時間前です。

+0

私の意図はちょうど24時間です。しかし、バケツを保管しておいてバケツを見ていると、3/24 7:00〜3/24 7:00 pmのクエリーができなくなります。その日のバケットにはその日の集計データが必要です時間水準まで下がる。 –