时间序列数据和UTC转换

Posted 2023-03-25

【中文标题】时间序列数据和UTC转换

【英文标题】：Time series data and UTC conversion

【发布时间】：2016-04-24 18:13:08

【问题描述】：

我将数据存储在分钟、小时、日、月和年存储桶中。所有数据均以 UTC 格式存储。假设客户端处于 PDT 时间（-07:00 UTC）

如果客户想要在他们的时区查询 4/23/2016 7:00pm 的小时总和，他们会将时间转换为 UTC - 4/24/2016 2:00am 并进行查询。图片供参考。

这对于小时和分钟存储桶非常有效。但是，让我们看看客户想要一天桶的总和的情况。如果客户想要4/24/2016 的本地日期，他们会将时间转换为 UTC，也可以在4/24/2016 中解析。 4/24/2016 UTC 日期存储桶包含从本地日期 4/23/2016 开始的 7 小时的数据，并且错过了本地日期 4/24/2016 的最后 7 小时。这似乎是一个问题，因为查询不会返回正确的总和。它返回 UTC 日期的总和。

我在这个例子中遗漏了什么吗？或者以 > 小时的时间间隔存储数据桶是个坏主意？

【参考方案1】：

您的日、月和年存储桶都包含一个时区（在本例中为 UTC0）。如果您想报告不同时区的日/月/年汇总，这最终是不同的小时集合，您需要使用该时区的一天开始和结束的概念来计算和存储它们。

【讨论】：

这就是我的想法。有没有一个通用的设计模式？

不是真的，除了注意如果要适应时区，TZ 偏移量将成为一个正式的查询参数。无论您是选择预先计算特定时区的日/月/年聚合，还是针对任何时区即时计算，都将取决于您的资源和要求。

【参考方案2】：

由于此示例中用户的视角是 PST，并且数据以 UTC 格式存储，因此您必须以某种方式显示希望查看一整天的聚合值的标志或指示。如果我是 PST，无论 4/24 是什么时间，如果我选择返回一整天的总价值，我想从 3/24 上午 7:00 到 3/25 7:00 查询 UTC下午。如果这是您的意图，它会根据用户选择总结一天的数据价值这一事实而成为修改后的开始和结束日期。我认为您在几分钟、几小时、几天、几个月内存储数据的设计没有任何问题。

这确实是您对一天数据价值的定义的问题。是指定时间之前的 24 小时，还是我上面讨论的那一天的 24 小时。

【讨论】：

我的意图是一天 24 小时。但是，如果我正在存储日存储桶并查看日存储桶，我将无法从 3/24 上午 7:00 到 3/24 下午 7:00 查询日存储桶是否只有当天的聚合数据，因为这需要下降到小时级别。