Änderungen der kanadischen Zeitzonen im Jahr 2026

Am 1. November 2026 stellen mehrere kanadische Provinzen und Territorien – Manitoba, Alberta, British Columbia und Teile der Nordwest-Territorien – auf die dauerhafte Sommerzeit um oder behalten ihre Sommer-UTC-Offsets bei, anstatt die Uhren um eine Stunde zurückzustellen.

In der IANA-Zeitzonendatenbank (tzdata 2026e) werden durch diese Änderungen die folgenden Zeitzonen und Aliase aktualisiert:

Region Ganzjähriger UTC-Versatz (ab 1. November 2026) Betroffene IANA-Zeitzonen
Manitoba UTC-5 (anstatt auf UTC-6 zurückzufallen) America - Winnipeg (America/Winnipeg), Canada - Central (Canada/Central), America - Rainy_River (America/Rainy_River)
Alberta UTC-6 (anstatt auf UTC-7 zurückzufallen) Amerika – Edmonton (America/Edmonton), Kanada – Mountain (Canada/Mountain)
British Columbia UTC-7 (anstatt auf UTC-8 zurückzufallen) America - Vancouver (America/Vancouver), Canada - Pacific (Canada/Pacific)
Nordwest-Territorien UTC-6 (anstatt auf UTC-7 zurückzufallen) Amerika – Inuvik (America/Inuvik)

In diesem Dokument wird erläutert, wie sich diese Zeitzonenänderungen auf Looker auswirken und wie Sie ab dem 1. November 2026 einen zeitlichen Versatz von einer Stunde verhindern können.

Auswirkungen der Zeitzonenänderungen auf Looker

Die Änderungen der kanadischen Zeitzonen im Jahr 2026 wirken sich unterschiedlich auf Looker-Funktionen aus, je nachdem, ob Ihre Datenbank oder Looker die Zeitzone auswertet:

  • SQL-Abfragen, Filter und benutzerdefinierte Dimensionen: Wenn Looker SQL für einen Explore, einen Look oder ein Dashboard generiert, übergibt Looker die konfigurierte IANA-Zeitzonenkennung an Ihre Datenbank. Verwaltete Cloud-Datenbanken wie BigQuery erhalten das tzdata 2026e-Update automatisch. Wenn Sie Ihre eigene Datenbank verwalten, prüfen Sie, ob die Zeitzonentabellen Ihrer Datenbank tzdata 2026e oder eine neuere Version enthalten.
  • Ausführungszeiten für geplante Lieferungen: Looker verwendet gebündelte Zeitzonendaten des Schedulers (Ruby), um Cron-Zeitpläne für Inhaltslieferungen auszuwerten. Auf nicht gepatchten Looker-Instanzen weichen die Ausführungszeiten für betroffene kanadische Zeitzonen ab dem 1. November 2026 um eine Stunde ab. Sowohl gepatchte Looker-Builds als auch die Problemumgehung für die Zeitzone für die geplante Lieferung beheben dieses Problem.
  • Tabellenkalkulationen in der Benutzeroberfläche: Wenn Sie sich ein Explore oder ein Dashboard in der Looker-Benutzeroberfläche ansehen, wertet Looker Tabellenkalkulationen, die now() verwenden, im Browser mit gebündelten Browser-Zeitzonendaten (JavaScript) aus. Auf nicht gepatchten Instanzen weichen diese Berechnungen ab dem 1. November 2026 um eine Stunde ab. In gepatchten Looker-Builds ist dieses Problem behoben.
  • Auf dem Server ausgewertete Tabellenkalkulationen: Wenn Looker Tabellenkalkulationen, die now() verwenden, auf dem Server auswertet – einschließlich in CSV- und XLSX-Downloads, Daten in geplanten Lieferungen, API-Abfragen und Benachrichtigungen –, wird Looker auf der JVM ausgeführt, deren gebündelte JDK-Zeitzonendatenbank weiterhin tzdb 2026b ist. Da der Patch das gebündelte JDK nicht aktualisiert, sind die vom Server ausgewerteten now()-Berechnungen für betroffene kanadische Zeitzonen ab dem 1. November 2026 auch bei gepatchten Looker-Builds um eine Stunde verschoben.

In der folgenden Tabelle ist zusammengefasst, welche Looker-Funktionen durch einen gepatchten Build korrigiert werden und welche durch die Konfiguration einer alternativen Zeitzone umgangen werden können:

Funktion Durch gepatchten Build behoben? Durch Problemumgehung mit alternativer Zeitzone behoben?
Ausführungszeiten für geplante Lieferungen Ja (aktualisiert die Ruby-Zeitzonendaten des Schedulers) Ja (Aktualisieren Sie die Zeitzone für die geplante Zustellung. Dies wirkt sich nur darauf aus, wann eine Zustellung gesendet wird.)
Tabellenkalkulation now() in der Benutzeroberfläche (Explores und Dashboards) Ja (aktualisiert die JavaScript-Zeitzonendaten des Browsers) Nicht empfohlen (erfordert das Ändern von Zeitzonen auf Abfrageebene, wodurch historische Winterdaten in SQL-Ergebnissen um eine Stunde verschoben werden)
Tabellenkalkulation now() auf dem Server ausgewertet (CSV- und XLSX-Downloads, Daten in geplanten Lieferungen, API und Benachrichtigungen) Nein bei Looker (Google Cloud Core)- und von Looker gehosteten Instanzen (JVM verwendet gebündeltes JDK tzdb 2026b) Nicht empfohlen (erfordert das Ändern von Zeitzonen auf Abfrageebene, wodurch historische Winterdaten in SQL-Ergebnissen um eine Stunde verschoben werden)

Um eine einstündige Abweichung bei geplanten Lieferungen und Tabellenkalkulationen in der Benutzeroberfläche zu vermeiden, führen Sie ein Upgrade auf eine gepatchte Looker-Version durch. Wenn Sie den Patch nicht vor dem 1. November 2026 anwenden können, konfigurieren Sie eine alternative Lieferzeitzone für Ihre Zeitpläne.

Upgrade auf eine gepatchte Looker-Version durchführen

Looker bietet gepatchte Builds, die die Zeitzonendaten des Schedulers (Ruby) und des Browsers (JavaScript) für alle unterstützten Looker-Versionen außer Looker 26.0 auf tzdata 2026e aktualisieren. Gepatchte Builds sind für Looker 25.18, 26.0, 26.6, 26.12, 26.16, 26.18, 26.20 und 26.22 sowie für spätere Releases verfügbar. Auf Looker (Google Cloud Core)- und von Looker gehosteten Instanzen wird die gebündelte JDK-Zeitzonendatenbank (tzdb 2026b) auf der JVM durch gepatchte Builds nicht aktualisiert. Daher weichen vom Server ausgewertete now()-Tabellenkalkulationen weiterhin um eine Stunde ab.

Looker stellt diesen Patch nicht automatisch vor dem 1. November 2026 auf allen Instanzen bereit. Sie können einen gepatchten Build für Ihre unterstützte Looker-Version anfordern oder herunterladen:

  • Looker (Google Cloud Core)- und von Looker gehostete Instanzen: Wenn Sie ein Upgrade auf einen gepatchten Build für Ihre Instanz anfordern möchten, wenden Sie sich an Cloud Customer Care.
  • Vom Kunden gehostete Instanzen: Wenn Sie die gepatchten JAR-Dateien für Ihre unterstützte Looker-Version erhalten möchten, laden Sie den aktualisierten Release von der Looker-Downloadseite herunter oder wenden Sie sich an Cloud Customer Care.
    • Vom Server ausgewertete Tabellenkalkulationen: Vom Server ausgewertete Tabellenkalkulationen verwenden die Zeitzonendaten Ihrer Java-Laufzeit anstelle eines gebündelten JDK. Aktualisieren Sie die Zeitzonendaten Ihrer Java-Laufzeit, z. B. mit dem Oracle-Tool tzupdater, damit betroffene kanadische Zeitzonen wie America/Winnipeg korrekt ausgewertet werden.
    • Zeitstempel für Systemaktivitäten: Wenn die Systemzeitzone Ihres Servers auf eine betroffene kanadische Zeitzone wie America/Winnipeg eingestellt ist, weichen die Zeitstempel für Systemaktivitäten ab dem 1. November 2026 ebenfalls um eine Stunde ab.

Alternative Zeitzone konfigurieren

Wenn Sie vor dem 1. November 2026 kein Upgrade auf einen gepatchten Build durchführen oder wenn auf Ihrer Instanz Looker 26.0 ausgeführt wird, können Sie eine alternative Zeitzone konfigurieren, die der UTC-Abweichung Ihrer Region entspricht:

  • Manitoba (America/Winnipeg, Canada/Central, America/Rainy_River – UTC-5): Wählen Sie eine Zeitzone aus, die das ganze Jahr über UTC-5 bleibt, ohne die Sommerzeit zu berücksichtigen, z. B. Amerika – Atikokan (America/Atikokan), Amerika – Cancun (America/Cancun), Amerika – Panama (America/Panama), Amerika – Bogota (America/Bogota), Amerika – Lima (America/Lima) oder Amerika – Jamaika (America/Jamaica).
  • Alberta (America/Edmonton, Canada/Mountain) und Nordwest-Territorien (America/Inuvik – UTC-6): Wählen Sie eine Zeitzone aus, die das ganze Jahr über UTC-6 bleibt, ohne dass die Sommerzeit berücksichtigt wird, z. B. Amerika – Regina (America/Regina), Kanada – Saskatchewan (Canada/Saskatchewan), Amerika – Guatemala (America/Guatemala), Amerika – Costa_Rica (America/Costa_Rica) oder Amerika – Belize (America/Belize).
  • British Columbia (America/Vancouver, Canada/Pacific – UTC-7): Wählen Sie eine Zeitzone aus, die das ganze Jahr über UTC-7 bleibt, ohne dass die Sommerzeit gilt, z. B. Amerika – Phoenix (America/Phoenix), Amerika – Dawson_Creek (America/Dawson_Creek), Amerika – Fort_Nelson (America/Fort_Nelson), Amerika – Creston (America/Creston), Amerika – Whitehorse (America/Whitehorse) oder Amerika – Dawson (America/Dawson).

Zeitzoneneinstellungen in Looker aktualisieren

Damit geplante Lieferungen nicht eine Stunde zu früh oder zu spät erfolgen, aktualisieren Sie die Zeitzone für die Lieferung in den betroffenen Zeitplänen auf eine alternative Zeitzone. Das Ändern der Zustellzeit für einen Zeitplan ist sicher, da dadurch nur gesteuert wird, wann eine Zustellung gesendet wird, nicht die zeitbasierten Daten, die von der Abfrage zurückgegeben werden (siehe Zeitzoneneinstellungen verwenden):

  • Zeitzone der Anwendung: Aktualisieren Sie die Einstellung Zeitzone der Anwendung auf der Seite Allgemeine Einstellungen im Bereich Admin, um die Standardzeitzone für neue Zeitpläne festzulegen. Da für jeden vorhandenen Zeitplan eine eigene Zeitzone gespeichert wird, müssen Sie vorhandene Zeitpläne weiterhin einzeln aktualisieren.
  • Geplante Inhaltsübermittlungen: Öffnen Sie jeden betroffenen Zeitplan für Dashboards, Looks oder Explores und aktualisieren Sie die Zeitzoneneinstellung für die Übermittlung. Eine Anleitung finden Sie unter Dashboards planen und senden und Looks und Explores bereitstellen.

Wenn Sie die Zeitzoneneinstellungen auf Abfrageebene dennoch aktualisieren möchten, um now() in Tabellenkalkulationen zu umgehen, und die einstündige Verschiebung der historischen SQL-Ergebnisse für die Winterzeit akzeptieren, können Sie die folgenden Einstellungen ändern, wenn eine betroffene kanadische Zeitzone konfiguriert ist:

  • Zeitzonen für Nutzerkonten: Wenn Nutzerspezifische Zeitzonen aktiviert ist, aktualisieren Sie die Zeitzonen für Nutzer auf der Seite Nutzer im Admin-Bereich. Einzelne Nutzer können die Einstellung Zeitzone auch auf ihrer Seite Konto aktualisieren.
  • Zeitzone der Datenbankverbindungsabfrage: Wenn nutzerspezifische Zeitzone deaktiviert ist, aktualisieren Sie die Einstellung Zeitzone der Abfrage auf der Seite Verbindungen im Admin-Bereich.