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