我本以为会有更多关于这方面的文献，但我很难找到。我有很多非代数聚合的时间序列数据（也就是说，没有函数可以用来将它们聚合到更高粒度的点——比如唯一的活跃用户、唯一的贡献者等等……知道我在某个小时的每分钟拥有的数量并不能告诉我这一小时总共拥有多少）。目前，我只是在UTC中存储和呈现所有这些数据。问题是，我的许多客户都觉得这很令人困惑，这是可以理解的。因为数据是非代数聚合的，所以无法从UTC午夜到午夜的1天数据，也就是说，从午夜到午夜，PST数据。需要根据原始数据进行重新计算。
因此：
- 对于一些复杂的分析图来说，从原始数据重新计算的成本高得令人望而却步
- 我们可以存储所有时区的所有数据，但这会增加我们存储的数据量x24
尽管如此，其他人是如何处理这个问题的？以下是谷歌分析的方法，但这似乎不足以满足我的用例，因为我知道如果我打开多个时区的蠕虫罐头，客户会要求不止一个。这也需要做很多看起来不值得付出的工作，因为仅仅增加时区支持并不是一件非常引人注目的事情，也不是一场巨大的胜利。我真正希望的是一些巧妙的设计解决方案，它以足够直观的方式呈现UTC数据，使其他时区的人不再感到困惑。有没有人处理过类似的问题，并找到了我缺少的解决方案？
首先，您应该认识到有超过24个时区。为了准确考虑全世界人实际使用时间的方式，您应该使用IANA时区，其中有500多个时区。另请参阅维基百科和时区标签维基。
如果您处理的是单个点（离散的时间戳），那么您当然可以在渲染图形时动态地从UTC转换到您想要的任何时区。您只需要记住，您查询的数据范围也需要转换到该时区。
但是，如果你谈论的是按特定时区的"天"聚合数据，那么就没有灵丹妙药了。您需要提前决定要支持哪些时区，并分别计算每个时区。当你这样做时，要认识到不仅仅是视图在改变。由于每个时区的日期边界不同，因此每个时区的数据可能具有非常不同的每日总数。
你还应该意识到，并不是每天都有24小时。如果当天恰好是夏令时转换的日期，则可能有23、23.5、24.5或25小时。这可能会影响绘制图形的方式。
您可能会考虑的一种方法是在聚合中忽略时区，而不是使用UTC或任何特定时区。当然，这在很大程度上取决于数据的上下文，但在某些情况下是合适的。例如，在发票上，您可能不太关心具体的时间戳，而更关心发票分配到哪个日历日期。在这种情况下，一旦分配了日期，您只会在该日期进行汇总。即使公司在多个时区运营，你也不会在意这些。
至于从用户那里抽象出来的一些巧妙的设计，恐怕我还没有看到太多。您真正拥有的两种选择是时区调整聚合（UTC或其他）和日历日期上下文的时区无关聚合。
我们在汇总可再生能源发电的数据时遇到了类似的问题。我们选择了三个选项User/Farm/UTC。
如果用户选择user，那么所有数据都将基于他的浏览器时区。在用户当地时间，昨天意味着24小时直到最后一个午夜。
同样，如果它是农场，那么我们将农场视为本地的，并得出相同的结果。
UTC是与您所实施的标准类似的标准。