2026 年加拿大时区调整

2026 年 11 月 1 日,加拿大多个省份和地区(马尼托巴省、阿尔伯塔省、不列颠哥伦比亚省和西北地区的部分区域)将永久实行夏令时 (DST),或保持其夏季世界协调时间 (UTC) 偏移量,而不再将时钟回拨一小时。

在 IANA 时区数据库 (tzdata 2026e) 中,这些更改会更新以下时区和别名:

区域 全年 UTC 偏移量(自 2026 年 11 月 1 日起) 受影响的 IANA 时区
马尼托巴 UTC-5(而不是回退到 UTC-6) America - Winnipeg (America/Winnipeg)、Canada - Central (Canada/Central)、America - Rainy_River (America/Rainy_River)
艾伯塔 UTC-6(而不是回退到 UTC-7) 美洲 - 埃德蒙顿 (America/Edmonton)、加拿大 - 山地时间 (Canada/Mountain)
不列颠哥伦比亚 UTC-7(而不是回退到 UTC-8) 美洲 - 温哥华 (America/Vancouver)、加拿大 - 太平洋 (Canada/Pacific)
西北地区 UTC-6(而不是回退到 UTC-7) 美洲 - 伊努维克 (America/Inuvik)

本文档介绍了这些时区变更对 Looker 的影响,以及如何防止在 2026 年 11 月 1 日及之后出现一小时的时间偏移值。

时区变更对 Looker 的影响

2026 年加拿大时区变更对 Looker 功能的影响因数据库或 Looker 是否评估时区而异:

  • SQL 查询、过滤条件和自定义维度:当 Looker 为探索、Look 或信息中心生成 SQL 时,Looker 会将配置的 IANA 时区标识符传递给您的数据库。BigQuery 等代管式云数据库会自动接收 tzdata 2026e 更新。如果您自行管理数据库,请验证数据库的时区表是否包含 tzdata 2026e 或更高版本。
  • 预定传送触发时间:Looker 使用捆绑的调度器 (Ruby) 时区数据来评估内容传送的 cron 调度。在未打补丁的 Looker 实例上,自 2026 年 11 月 1 日起,受影响的加拿大时区的计划触发时间会延迟一小时。已修补的 Looker build 和计划传送时区解决方法均可解决此问题。
  • 界面中的表计算:当您在 Looker 界面中查看探索或信息中心时,Looker 会使用捆绑的浏览器 (JavaScript) 时区数据,在浏览器中评估使用 now() 的表计算。在未修补的实例上,自 2026 年 11 月 1 日起,这些计算结果将出现一小时的偏差。已修补的 Looker build 修复了此问题。
  • 在服务器上评估的表计算:当 Looker 在服务器上评估使用 now() 的表计算(包括在 CSV 和 XLSX 下载、计划交付中的数据、API 查询和提醒中)时,Looker 会在 JVM 上运行,其捆绑的 JDK 时区数据库仍为 tzdb 2026b。由于该补丁不会更新捆绑的 JDK,因此自 2026 年 11 月 1 日起,即使在已应用补丁的 Looker build 上,受影响的加拿大时区的服务器评估 now() 计算仍会存在一小时的偏差。

下表总结了哪些 Looker 功能可通过补丁 build 修复,哪些功能可通过配置备用时区来解决:

功能 是否已通过打补丁的 build 修复? 是否已通过备用时区解决方法修复?
预定传送触发时间 是(更新调度器 Ruby 时区数据) 是(更新预定递送时区,这只会影响递送时间)
界面中的表计算 now()(探索和信息中心) 是(更新浏览器 JavaScript 时区数据) 不推荐(需要更改查询级时区,这会导致 SQL 结果中的历史冬季数据偏移一小时)
在服务器上评估的表计算 now()(CSV 和 XLSX 下载、定期传送的数据、API 和提醒) 在 Looker (Google Cloud Core) 和 Looker 托管的实例上,不支持(JVM 使用捆绑的 JDK tzdb 2026b) 不推荐(需要更改查询级时区,这会导致 SQL 结果中的历史冬季数据偏移一小时)

为防止预定传送和界面表计算出现一小时的偏差,请升级到已修补的 Looker 版本。如果您无法在 2026 年 11 月 1 日之前应用该补丁,请在时间表中配置备用传送时区。

升级到已修补的 Looker 版本

Looker 提供了补丁 build,可将所有受支持的 Looker 版本(Looker 26.0 除外)的调度器 (Ruby) 和浏览器 (JavaScript) 时区数据更新为 tzdata 2026e。Looker 25.18、26.0、26.6、26.12、26.16、26.18、26.20 和 26.22 以及更高版本均提供已修补 build。在 Looker (Google Cloud Core) 和 Looker 托管的实例上,修补后的 build 不会更新 JVM 上的捆绑 JDK 时区数据库 (tzdb 2026b),因此服务器评估的 now() 表计算仍会相差一小时。

在 2026 年 11 月 1 日之前,Looker 不会自动在所有实例中部署此补丁。您可以为受支持的 Looker 版本请求或下载补丁 build:

  • Looker (Google Cloud Core) 和 Looker 托管的实例:如需为您的实例申请升级到已修补 build,请与 Cloud Customer Care 联系。
  • 客户托管的实例:如需获取受支持 Looker 版本的已修补 JAR 文件,请从 Looker 下载页面下载更新后的版本,或与 Cloud Customer Care 联系。
    • 服务器评估的表计算:服务器评估的表计算使用 Java 运行时的时区数据,而不是捆绑的 JDK。更新 Java 运行时的时区数据(例如,使用 Oracle tzupdater 工具),以便正确评估受影响的加拿大时区(例如 America/Winnipeg)。
    • 系统活动时间戳:如果服务器的系统时区设置为受影响的加拿大时区(例如 America/Winnipeg),则自 2026 年 11 月 1 日起,系统活动时间戳也会出现一小时的偏差。

配置备用时区

如果您未在 2026 年 11 月 1 日之前升级到已修补的版本,或者您的实例运行的是 Looker 26.0,则可以配置与您所在区域的 UTC 偏移量匹配的替代时区:

  • 曼尼托巴(America/Winnipeg、Canada/Central、America/Rainy_River - UTC-5):选择全年保持 UTC-5 且不实行夏令时的时区,例如美洲 - 阿蒂科肯 (America/Atikokan)、美洲 - 坎昆 (America/Cancun)、美洲 - 巴拿马 (America/Panama)、美洲 - 波哥大 (America/Bogota)、美洲 - 利马 (America/Lima) 或美洲 - 牙买加 (America/Jamaica)。
  • 阿尔伯塔省(America/Edmonton、Canada/Mountain)和西北地区(America/Inuvik - UTC-6):选择全年保持 UTC-6 且不实行夏令时的时区,例如美洲 - 里贾纳 (America/Regina)、加拿大 - 萨斯喀彻温 (Canada/Saskatchewan)、美洲 - 危地马拉 (America/Guatemala)、美洲 - 哥斯达黎加 (America/Costa_Rica) 或美洲 - 伯利兹 (America/Belize)。
  • 不列颠哥伦比亚省(America/Vancouver、Canada/Pacific - UTC-7):选择全年保持 UTC-7 且不实行夏令时的时区,例如美洲 - 菲尼克斯 (America/Phoenix)、美洲 - 道森克里克 (America/Dawson_Creek)、美洲 - 纳尔逊堡 (America/Fort_Nelson)、美洲 - 克雷斯顿 (America/Creston)、美洲 - 怀特霍斯 (America/Whitehorse) 或美洲 - 道森 (America/Dawson)。

在 Looker 中更新时区设置

为防止预定传送时间出现一小时的偏差,请将受影响时间表的传送时区更新为备用时区。更改时间表的传送时区是安全的,因为它仅控制传送时间,而不控制查询返回的基于时间的数据(请参阅使用时区设置):

  • 应用时区:在管理面板的常规设置页面上更新应用时区设置,为新时间表设置默认时区。由于每个现有时间表都会存储自己的时区,因此您仍必须单独更新现有时间表。
  • 预定的内容传送:打开每个受影响的信息中心、Look 或探索时间表,然后更新传送时区设置。如需查看相关说明,请参阅安排和发送信息中心以及传送 Look 和探索。

如果您仍选择更新查询级时区设置,以解决表计算中的 now() 问题,并接受历史冬季 SQL 结果中一小时的偏移,则可以在配置了受影响的加拿大时区的位置更改以下设置:

  • 用户账号时区:如果用户自选时区已启用,请在管理面板中的用户页面上更新用户时区。个人用户还可以在其账号页面上更新时区设置。
  • 数据库连接查询时区:如果用户自选时区处于停用状态,请在管理面板的连接页面上更新查询时区设置。