我想象会有更多关于此的文献，但我找不到任何文献。我有很多非代数可聚合的时间序列数据（也就是说，没有函数存在的点，我可以用它们将它们聚合到更高的粒度 - 像独特的活跃用户，独特的贡献者等等。知道我每小时一小时的金额并不能告诉我一小时内我的总数是多少。目前，我只是以UTC格式存储和呈现所有这些数据。问题是我的很多客户都觉得这很混乱 - 这是可以理解的。由于数据是非代数可聚合的，因此无法从午夜到午夜的1天午间到午夜到午夜的UTC数据中获取UTC数据。需要从原始数据进行重新计算。
所以：
所有这些都说，其他人如何处理这个问题呢？ Here's how Google Analytics does it，但这似乎不足以用于我的用例，因为我知道如果我打开多个时区可以蠕虫，客户会要求不止一个。这也需要大量的工作，似乎不值得努力，因为只是添加时区支持不会非常明显或是一个巨大的胜利。我真正希望的是一些聪明的设计解决方案，它只是以一种直观的方式呈现UTC数据，以至于它不再让其他时区的人感到困惑。有没有人处理类似的问题，并找到我错过的解决方案？
首先，你应该认识到有超过24个时区。为了准确地考虑人们如何在世界范围内实际使用时间，你应该使用IANA time zones，其中有500多个。另见Wikipedia和timezone tag wiki。
如果您正在处理各个点（谨慎的时间戳），那么您可以在渲染图形时随时将UTC转换为您希望的任何时区。您还需要记住，您查询的数据范围也需要转换为该时区。
但是，如果您正在讨论在特定时区的“日期”聚合数据，那么就没有灵丹妙药。您需要提前决定要支持的时区，并分别计算每个时区。执行此操作时，请认识到不仅仅是视图正在发生变化。由于每个时区的日边界不同，因此每个时区的数据可能具有非常不同的每日总数。
您还应该意识到并非每天都有24小时。如果日期恰好是夏令时转换的日期，那么它可能有23,23.5,24.5或25小时。这可能会影响您绘制图表的方式。
您可能考虑的一种方法是在聚合中忽略时区，而不是使用UTC或任何特定时区。当然，这在很大程度上取决于数据的上下文，但在某些情况下它是合适的。例如，在发票上，您可能不太关心具体的时间戳，而是更多地关注发票分配到的日历日期。在这种情况下，一旦指定了日期，您只需在该日期汇总。即使公司在多个时区运营，您也不会总是关心这个问题。
至于一些从用户那里抽象出来的巧妙设计，我恐怕没见多少。您真正拥有的唯一两个选择是时区调整聚合（UTC或其他），以及日历日期上下文的时区无知聚合。
我们有类似的问题来汇总可再生发电的数据。我们选择了三个选项User / Farm / UTC。
如果用户选择USER，那么所有数据都将基于他的浏览器时区。昨天是用户当地时间24小时至深夜。
同样，如果它是农场，那么我们将农场本地化并衍生出来。
UTC与您实施的标准类似。