Metabase 怎么修改实例的默认时区与报表时区设置【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase如果你的 Metabase 报表里日期、时间显示得不对或者团队希望报表统一按某个时区比如 UTC 存储、本地时区展示呈现需要调整的不是一个开关而是三个位置数据库层、运行 Metabase 的 JVM/操作系统层、以及 Metabase 实例自身的Report Timezone设置。官方文档建议这三层时区保持一致才能保证报表显示正确。本文按 Metabase 官方文档Timezones、Languages and localization给出设置路径、对齐方式和验证方法。时区会影响报表的四个位置Metabase 文档列出了以下会直接影响你所见数据的时区来源Database—— 数据库的全局时区设置、具体列类型甚至个别数据值OS JVM—— 运行 Metabase 的系统及其 Java 虚拟机的时区设置会影响报表Metabase—— 实例内的Report Timezone设置如果已设置决定数据如何展示Metabase Cloud—— 托管 Metabase Cloud 实例的服务器时区。官方推荐的一致性配置数据库列使用带时区信息的类型见下文“数据类型”除非有特殊需求数据库的报表时区设为 UTC日期/时间值统一以 UTC 存储JVM 使用你希望用于报表的时区理想情况下与数据库时区一致Metabase 的Report Timezone设为你希望报表展示的时区并与其他设置保持一致。设置实例的 Report Timezone操作路径Admin Settings Localization Instance settings Report timezone详见 Set default instance report timezone。进入Admin Settings Localization。在Report timezone项选择默认的报表时区。这个设置的关键属性来自文档原文它是纯展示设置修改 Report Timezone 不会改变数据库中任何数据的时区它只作用于带时区信息的列类型对timestamp without time zone类型不生效包括convertTimezone表达式的输出只有以下数据库支持 Report TimezoneBigQuery、Druid、MySQL、Oracle、PostgreSQL、Presto、Redshift、Vertica。使用其他数据库时实例层面没有这个设置可开需要用下面一节的 JVM 时区与数据库对齐。对齐 JVM 时区Metabase 的时区就是 Java 虚拟机的时区通常在启动时通过-Duser.timezonetimezone参数设置或使用JAVA_TIMEZONE环境变量具体取决于你的启动方式。文档明确指出JVM 时区与 MetabaseReport Timezone不一致是时区问题的常见来源应让-Duser.timezone的值与报表时区一致。以 Docker 部署为例JAVA_TIMEZONE环境变量会被 Metabase 启动脚本读取官方示例如下docker run -d -p 3000:3000 \ -e JAVA_TIMEZONEUS/Pacific \ --name metabase metabase/metabasePodman 部署的方式相同见 Running Metabase on Podman。这里有一条边界说明MetabaseJVM的时区不影响使用 Report Timezone 的那些数据库只有在使用不支持 Report Timezone 的数据库时Metabase 时区才直接决定无时区信息的日期如何解释——此时要确保它与数据库时区一致见 时区排查指南。检查数据库层的数据类型数据库列可以通过特定数据类型获得时区信息具体类型写法取决于你的数据库数据类型说明文档示例timestamp with time zone知道所在位置2022-12-28T12:00:00 AT TIME ZONE America/Torontotimestamp with offset知道与 UTC 的时差2022-12-28T12:00:00-04:00timestamp without time zone无时区信息2022-12-28T12:00:00按官方建议日期/时间列应存为带时区信息的类型并且值尽量以 UTC 存储。如果列是timestamp without time zoneReport Timezone 对它不生效这类数据的解释会落到数据库自身时区上——这是时区问题的高发点。验证设置是否生效验证方式就是打开一个包含时间戳字段的问题或图表对照下面的预期timestamp with time zone/timestamp with offset列的显示值会随 Report Timezone 转换timestamp without time zone列的显示值不随Report Timezone 变化。文档给出的示例示例结果仅用于说明展示规则不代表你数据必须得到的值数据库中的原始时间戳数据类型Report time zone显示为2022-12-28T12:00:00timestamp without time zoneCanada/EasternDec 28, 2022, 12:00 AM即无时区信息的值按原样展示带时区信息的值按报表时区重新显示。如果你的问题使用了convertTimezone表达式注意其输出永远是timestamp without time zoneReport Timezone 同样不会作用于该输出。常见问题与限制数值仍然不对按 时区排查指南 逐项检查Report Timezone 是否设错、数据是否混用带时区与不带时区的值、日期过滤是否落在错误的时区边界上。原生 SQL 不遵守报表时区Metabase 会设置会话时区但部分数据库会忽略它。文档给出的处理方式是联系数据库管理员允许设置会话时区或在 SQL 中显式转换PostgreSQL 示例SELECT column::TIMESTAMP AT TIME ZONE EST AS column_estMetabase CloudCloud 实例的服务器时区不能自行修改文档建议联系官方支持处理。如果个别问题里需要把某个时间戳显式转换到目标时区例如给 EST 的团队生成自定义报表日期可以在查询构建器中使用convertTimezone表达式注意它对 Amazon Athena、Databricks、Druid、MongoDB、Presto、SparkSQL、SQLite 和 Metabase Sample Database 不可用详见 ConvertTimezone。【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考