您如何处理时间序列图中的时区？

Question

我想会有更多关于这方面的文献，但我找不到任何文献。我有很多非代数聚合的时间序列数据（也就是说，不存在可用于将它们聚合到更高粒度的函数的点——比如独特的活跃用户、独特的贡献者等。 . 知道我在某个小时的每分钟拥有的数量并不能告诉我在这一小时内我拥有的总量）。目前，我只是在 UTC 中存储和呈现所有这些数据。问题是我的许多客户都觉得这很令人困惑——这是可以理解的。由于数据是不可代数聚合的，因此无法从 1 天午夜至午夜的 UTC 数据中获取例如午夜至午夜的 PST 数据。需要根据原始数据进行重新计算。

所以：

1. 对于一些复杂的分析图，从原始数据重新计算的成本高得令人望而却步
2. 我们可以存储所有时区的所有数据，但这会增加我们存储 x24 的数据量。

说了这么多，其他人是怎么处理这个问题的？以下是 Google Analytics 的工作方式，但这对我的用例来说似乎不够，因为我知道如果我打开多个时区的蠕虫罐头，客户会要求不止一个。这也需要做很多看起来不值得付出努力的工作，因为仅仅添加时区支持不会非常明显或巨大的胜利。我真正希望的是一些巧妙的设计解决方案，它以某种足够直观的方式呈现 UTC 数据，不再让其他时区的人感到困惑。有没有人处理过类似的问题并找到我缺少的解决方案？

Answer 1

首先，您应该认识到有超过 24 个时区。为了准确地考虑到人们在全球范围内实际使用时间的方式，您应该使用IANA 时区，其中有 500 多个。另请参阅维基百科和时区标签 wiki。

如果您正在处理单个点（谨慎的时间戳），那么您当然可以在渲染图形时从 UTC 转换为您希望的任何时区。您只需要记住，您查询的数据范围也需要转换为该时区。

但是，如果您正在谈论按特定时区的“天”聚合数据，则没有灵丹妙药。您需要提前决定要支持的时区并分别计算每个时区。当你这样做时，要认识到改变的不仅仅是视图。由于每个时区的日期边界不同，因此每个时区的数据可能具有非常不同的每日总数。

您还应该知道，并非每天都有 24 小时。如果这一天恰好是夏令时转换的日期，则它可能有 23、23.5、24.5 或 25 小时。这可能会影响您绘制图形的方式。

您可能考虑的一种方法是在聚合中不考虑时区，而不是使用 UTC 或任何特定时区。当然，这在很大程度上取决于数据的上下文，但在某些情况下是合适的。例如，在发票上，您可能不太关心特定的时间戳，而更关心发票分配到的日历日期。在这种情况下，一旦分配了日期，您只需在该日期进行汇总。即使公司在多个时区运营，您也不会关心总体上的情况。

至于一些从用户那里抽象出来的巧妙设计，恐怕我还没有看到太多。您真正拥有的唯一两个选择是时区调整聚合（UTC 或其他），以及日历日期上下文的时区无知聚合。