我问题中的日期和时间是错误的

您正在对日期和时间进行计算，或在图表中显示它们，但

• 值似乎不正确，或者
• 汇总值不正确。

问题是时区引起的吗？

根本原因：日期和时间以不同的时区存储，但在进行计算时没有考虑某些或所有这些时区（即问题是不一致的数据）。

采取的步骤

要解决这个问题，您需要回答以下问题

1. 你认为正在显示错误的数据的正确时区是什么（即正确答案）？
2. 每个时间戳都有一个显式的时间区设置，还是某些或所有时间戳在没有时区的情况下存储？例如，Dec 1, 2019 00:00:00Z00 包含了时区（在 Z 之后显示），但 Dec 1, 2019 没有包含。
3. 数据库服务器使用什么时区？
4. Metabase使用什么时区？

一旦您有了这些答案，寻找以下情况

1. 您的问题或图表正在比较或排序具有不一致或缺失时区的值。例如，如果一架飞机的起飞和到达时间以当地时间报告，它可能看起来是在起飞之前到达。
2. 您的问题正在汇总具有不同时区的时戳：例如，您网站的流量“每日”总计包括来自东亚、欧洲和美洲的本地日期的超过24小时的数据。

一旦您认为您已经确定了一个问题，深入挖掘以了解底层问题的确切时区转换。例如，假设您正在查看具有每日值的时序图；如果您的错误发生在周总计中，您可以通过以下方式

1. 选择一个您知道数值不正确的具体日期。
2. 在图表中单击数据点，或选择结果表中的单元格，然后选择“查看这些X”。
3. 在浏览器中的另外两个选项卡中打开此问题。更改日期过滤器，使一个选项卡显示底层表中的上一天的行，而另一个选项卡显示底层表中的下一天的行。
4. 检查用于对底层显示中的结果进行分组的日期字段是否正确。如果它与您在数据库中存储的或您在另一个工具中拥有的不同，那么时间戳在整个转换过程中都是不正确的。这通常发生在您使用没有显式时区的日期或时间时。
5. 如果底层的时间戳是正确的（如果有明确时区，它们应该是正确的），则单个时间可能被分组成一个不同于您希望的时间区域的日子。
6. 要找出它们被转换成哪个时区，通过将您正在查看的问题中的日期过滤器上的时间向前调整一小时，直到您得到正确的时间数或您已经向前调整了12小时。 （如果您的任何时区包括印度、纽芬兰或其他半步时区的司法管辖区，您可能需要以半小时为增量进行此操作。）
7. 如果不起作用，尝试将开始时间和结束时间向前调整一小时，直到您得到正确的时间数或您已经向前调整了12小时。
8. 如果此时您得到了正确的时间值，这意味着您设置过滤器时手动设置的小时数已将时区转换。如果是这样，检查您计算出的偏差是否与数据仓库的时区或Metabase本身的时区相匹配。

报告时区设置错误吗？

根本原因：在Metabase使用的时间和数据仓库使用的时间区域不匹配可能会导致问题中的数字或图表不正确。

采取的步骤

1. 请检查从 管理员设置 > 设置 > 本地化 中的 报告时区设置。
2. 如果您使用的是不支持报告时区设置的数据库，请确保Metabase的时区与数据库的时区相匹配。Metabase的时区是Java虚拟机的时区，通常通过 -Duser.timezone<..> 参数或 JAVA_TIMEZONE 环境变量设置；它如何设置将取决于您如何启动Metabase。请注意，Metabase的时区不会影响使用报告时区的任何数据库。

SQL查询是否不尊重报告时区设置？

根本原因：我们目前没有将报告时区应用于SQL查询的结果。

采取的步骤

在SQL查询中显式设置报告时区。

例如，您可以使用PostgreSQL编写如下内容

SELECT column::TIMESTAMP AT TIME ZONE 'EST' AS column_est

此语句首先将列转换为 timestamp 数据类型，然后将 timestamp 转换为具有时区 'EST' 的 timestamptz 数据类型。

没有明确时区的时间是否被转换为另一天？

根本原因：您按日期（而不是按时间）分组，而这个日期没有时区。

采取的步骤

1. 查看您在 数据模型参考 中使用的每个时间字段，看看它们是否仅仅是“日期”字段。
2. 如果是这样，请确保服务器时区反映了报告时区，因为当在Metabase上运行查询时，服务器会将配置的时区应用于该日期。

您是否混合了显式和隐式时区？

根本原因：您正在比较或对两个日期进行算术运算，其中一个具有显式时区，另一个没有。

采取的步骤

1. 这种情况通常发生在使用了多个字段的问题中：例如，你正在按一个时间戳过滤并按另一个时间戳分组。请检查你在问题中使用日期或时间的时区。
2. 你需要显式设置任何缺少显式时区的值的时间区。这需要在SQL查询中完成，或者通过转换数据库中的数据来确保两个时间戳都有时区。