时间系列数据和UTC转换
我将数据存储在分钟，小时，日，月和年桶中。所有数据都以UTC格式保存。假设客户端处于PDT时间（-07：00 UTC）时间系列数据和UTC转换
如果客户想要查询其时区中小时总计4/23/2016 7:00pm，他们会将时间转换为UTC - 4/24/2016 2:00am并进行查询。图片以供参考。
这适用于小时和分钟桶完美的罚款。但是，让我们看看客户需要一天的总和的情况。如果客户需要4/24/2016的当地天数，他们会将时间转换为UTC，这也将在4/24/2016中解决。 UTC日存储桶中的数据包含当地日期4/23/2016 7小时的数据，并且错过当地日期的最后7小时4/24/2016。这似乎是一个问题，因为查询不会返回正确的总和。它返回UTC时间的总和。
我是否错过了这个例子？或者在时间间隔>数小时内存储数据桶是一个坏主意？
您的一天，每月和每年桶中都有一个时区（本例中为UTC0）。如果您想报告不同时间段的日/月/年总计，那最终是不同的小时数集合，您需要使用该时区的一天的开始和结束的概念来计算和存储它们。
由于此示例中用户的角度是PST并且数据以UTC存储，因此您必须有一个标志或指示表明希望看到整天的聚合值。如果我是PST，无论4月24日是什么时间，如果我选择返回一整天的汇总，我想查询UTC从3/24上午7:00到3月25日7:00下午。如果这是您的意图，则基于用户选择总结一天数据的事实，它将成为修改的开始和结束日期。我没有看到您的设计在几分钟，几小时，几天，几个月内存储数据的问题。
这实际上是您定义一天数据的问题。是指定时间前24小时还是当天24小时，这是我在上面讨论过的。
我的意图是一天24小时。但是如果我存储日桶并查看日桶，如果日桶只有当天的总数据，我将无法查询从3/24上午7:00到下午3/24下午7:00，因为这需要下降到小时级别。 –
这就是我的想法。这是否有一个共同的设计模式？ –
不是真的，除了要注意的是，如果要容纳时区，则TZ偏移将成为正式的查询参数。无论您是选择预先计算特定时区的日/月/年聚合还是随时为任何时区执行聚合，都将取决于您的资源和要求。 – welch