Changements de fuseau horaire au Canada en 2026

Le 1er novembre 2026, plusieurs provinces et territoires canadiens (le Manitoba, l'Alberta, la Colombie-Britannique et certaines parties des Territoires du Nord-Ouest) passeront à l'heure d'été permanente ou conserveront leur décalage UTC d'été au lieu de reculer d'une heure.

Dans la base de données de fuseaux horaires IANA (tzdata 2026e), ces modifications mettent à jour les fuseaux horaires et alias suivants :

Région	Décalage UTC toute l'année (à partir du 1er novembre 2026)	Fuseaux horaires IANA concernés
Manitoba	UTC-5 (au lieu de revenir à UTC-6)	Amérique - Winnipeg (America/Winnipeg), Canada - Centre (Canada/Central), Amérique - Rainy_River (America/Rainy_River)
Alberta	UTC-6 (au lieu de revenir à UTC-7)	Amérique - Edmonton (America/Edmonton), Canada - Rocheuses (Canada/Mountain)
Colombie-Britannique	UTC-7 (au lieu de revenir à UTC-8)	Amérique - Vancouver (America/Vancouver), Canada - Pacifique (Canada/Pacific)
Territoires du Nord-Ouest	UTC-6 (au lieu de revenir à UTC-7)	Amérique – Inuvik (America/Inuvik)

Ce document explique l'impact de ces changements de fuseau horaire sur Looker et comment éviter un horodatage d'une heure à partir du 1er novembre 2026.

Impact des changements de fuseau horaire sur Looker

Les changements de fuseau horaire au Canada en 2026 affectent les fonctionnalités de Looker différemment selon que votre base de données ou Looker évalue le fuseau horaire :

• Requêtes SQL, filtres et dimensions personnalisées : lorsque Looker génère du code SQL pour une exploration, un Look ou un tableau de bord, il transmet l'identifiant de fuseau horaire IANA configuré à votre base de données. Les bases de données cloud gérées telles que BigQuery reçoivent automatiquement la mise à jour tzdata 2026e. Si vous gérez votre propre base de données, vérifiez que ses tables de fuseaux horaires incluent tzdata 2026e ou une version ultérieure.
• Heures de déclenchement des envois planifiés : Looker utilise les données de fuseau horaire du planificateur groupé (Ruby) pour évaluer les planifications cron des envois de contenu. Sur les instances Looker non corrigées, les heures de déclenchement des planifications pour les fuseaux horaires canadiens concernés sont décalées d'une heure à partir du 1er novembre 2026. Les builds Looker corrigés et la solution de contournement du fuseau horaire de livraison planifiée permettent de résoudre ce problème.
• Calculs de table dans l'interface utilisateur : lorsque vous affichez une exploration ou un tableau de bord dans l'interface utilisateur Looker, Looker évalue les calculs de table qui utilisent now() dans le navigateur à l'aide des données de fuseau horaire du navigateur (JavaScript) groupées. Sur les instances non corrigées, ces calculs seront décalés d'une heure à partir du 1er novembre 2026. Les builds Looker corrigés résolvent ce problème.
• Calculs de table évalués sur le serveur : lorsque Looker évalue sur le serveur des calculs de table qui utilisent now() (y compris dans les téléchargements CSV et XLSX, les données des envois planifiés, les requêtes API et les alertes), Looker s'exécute sur la JVM, dont la base de données de fuseaux horaires JDK groupée est toujours tzdb 2026b. Étant donné que le correctif ne met pas à jour le JDK groupé, les calculs now() évalués par le serveur pour les fuseaux horaires canadiens concernés restent décalés d'une heure à partir du 1er novembre 2026, même sur les builds Looker corrigés.

Le tableau suivant récapitule les fonctionnalités Looker qui sont corrigées par un build corrigé et celles qui peuvent être contournées en configurant un autre fuseau horaire :

Fonctionnalité	Corrigé par une compilation corrigée ?	Résolu par une solution de contournement avec un autre fuseau horaire ?
Heures de déclenchement de la livraison planifiée	Oui (met à jour les données de fuseau horaire Ruby du planificateur)	Oui (mettez à jour le fuseau horaire de la planification de l'envoi, qui n'affecte que l'heure d'envoi)
Calcul de table now() dans l'UI (explorations et tableaux de bord)	Oui (met à jour les données de fuseau horaire JavaScript du navigateur)	Non recommandé (nécessite de modifier les fuseaux horaires au niveau de la requête, ce qui décale d'une heure les données d'hiver historiques dans les résultats SQL)
Calcul de table now() évalué sur le serveur (téléchargements CSV et XLSX, données dans les envois planifiés, l'API et les alertes)	Non sur les instances Looker (Google Cloud Core) et hébergées par Looker (la JVM utilise le JDK tzdb 2026b groupé)	Non recommandé (nécessite de modifier les fuseaux horaires au niveau de la requête, ce qui décale d'une heure les données d'hiver historiques dans les résultats SQL)

Pour éviter un décalage d'une heure sur les envois planifiés et les calculs de tables de l'interface utilisateur, passez à une version corrigée de Looker. Si vous ne pouvez pas appliquer le correctif avant le 1er novembre 2026, configurez un autre fuseau horaire de diffusion dans vos planifications.

Passer à une version corrigée de Looker

Looker fournit des builds corrigés qui mettent à jour les données de fuseau horaire du planificateur (Ruby) et du navigateur (JavaScript) vers tzdata 2026e pour toutes les versions de Looker compatibles, à l'exception de Looker 26.0. Des builds corrigés sont disponibles pour Looker 25.18, 26.0, 26.6, 26.12, 26.16, 26.18, 26.20 et 26.22, ainsi que pour les versions ultérieures. Sur les instances Looker (Google Cloud Core) et hébergées par Looker, les builds corrigés ne mettent pas à jour la base de données de fuseaux horaires du JDK groupé (tzdb 2026b) sur la JVM. Par conséquent, les calculs de table now() évalués par le serveur restent décalés d'une heure.

Looker ne déploiera pas automatiquement ce correctif sur toutes les instances avant le 1er novembre 2026. Vous pouvez demander ou télécharger un build corrigé pour votre version de Looker compatible :

• Instances Looker (Google Cloud Core) et hébergées par Looker : pour demander une mise à niveau vers une version corrigée de votre instance, contactez Cloud Customer Care.
• Instances hébergées par le client : pour obtenir les fichiers JAR corrigés pour votre version de Looker compatible, téléchargez la version mise à jour depuis la page de téléchargement de Looker ou contactez Cloud Customer Care.
  • Calculs de table évalués par le serveur : les calculs de table évalués par le serveur utilisent les données de fuseau horaire de votre environnement d'exécution Java plutôt qu'un JDK groupé. Mettez à jour les données de fuseau horaire de votre environnement d'exécution Java, par exemple à l'aide de l'outil Oracle tzupdater, afin que les fuseaux horaires canadiens concernés, tels que America/Winnipeg, soient correctement évalués.
  • Codes temporels de l'activité du système : si le fuseau horaire du système de votre serveur est défini sur un fuseau horaire canadien concerné, tel que America/Winnipeg, les codes temporels de l'activité du système seront également décalés d'une heure à partir du 1er novembre 2026.

Configurer un autre fuseau horaire

Si vous ne passez pas à une version corrigée avant le 1er novembre 2026 ou si votre instance exécute Looker 26.0, vous pouvez configurer un autre fuseau horaire correspondant au décalage UTC de votre région :

• Manitoba (America/Winnipeg, Canada/Central, America/Rainy_River – UTC-5) : sélectionnez un fuseau horaire qui reste sur UTC-5 tout au long de l'année sans observer l'heure d'été, par exemple Amérique – Atikokan (America/Atikokan), Amérique – Cancun (America/Cancun), Amérique – Panama (America/Panama), Amérique – Bogota (America/Bogota), Amérique – Lima (America/Lima) ou Amérique – Jamaïque (America/Jamaica).
• Alberta (America/Edmonton, Canada/Mountain) et Territoires du Nord-Ouest (America/Inuvik – UTC-6) : sélectionnez un fuseau horaire qui reste sur UTC-6 tout au long de l'année sans observer l'heure d'été, par exemple Amérique – Regina (America/Regina), Canada – Saskatchewan (Canada/Saskatchewan), Amérique – Guatemala (America/Guatemala), Amérique – Costa_Rica (America/Costa_Rica) ou Amérique – Belize (America/Belize).
• Colombie-Britannique (America/Vancouver, Canada/Pacific – UTC-7) : sélectionnez un fuseau horaire qui reste sur UTC-7 tout au long de l'année sans observer l'heure d'été, par exemple America - Phoenix (America/Phoenix), America - Dawson_Creek (America/Dawson_Creek), America - Fort_Nelson (America/Fort_Nelson), America - Creston (America/Creston), America - Whitehorse (America/Whitehorse) ou America - Dawson (America/Dawson).

Mettre à jour les paramètres de fuseau horaire dans Looker

Pour éviter que les livraisons planifiées ne soient déclenchées avec une heure de décalage, remplacez le fuseau horaire de livraison des planifications concernées par un autre fuseau horaire. La modification du fuseau horaire d'envoi d'une planification est sans risque, car elle ne contrôle que le moment où un envoi est effectué, et non les données temporelles renvoyées par la requête (voir Utiliser les paramètres de fuseau horaire) :

• Fuseau horaire de l'application : modifiez le paramètre Fuseau horaire de l'application sur la page Paramètres généraux du panneau Admin pour définir le fuseau horaire par défaut des nouvelles planifications. Comme chaque programmation existante stocke son propre fuseau horaire, vous devez toujours mettre à jour les programmations existantes individuellement.
• Diffusions de contenu planifiées : ouvrez chaque planification de tableau de bord, de Look ou d'exploration concernée, puis mettez à jour le paramètre de fuseau horaire de livraison. Pour obtenir des instructions, consultez Planifier et envoyer des tableaux de bord et Envoyer des Looks et des explorations.

Avertissement : Évitez de remplacer les paramètres de fuseau horaire au niveau de la requête (y compris les fuseaux horaires des utilisateurs, les fuseaux horaires des requêtes de connexion à la base de données, et les valeurs timezone et query_timezone des requêtes enregistrées ou de LookML) par un fuseau horaire sans heure d'été, sauf si vous devez spécifiquement contourner now() dans les calculs de table et que vous acceptez l'impact sur les données historiques. Votre base de données gère directement les requêtes SQL. Il n'est donc pas nécessaire de modifier les paramètres de fuseau horaire au niveau de la requête dans Looker pour les requêtes SQL. Ces paramètres déterminent la conversion SQL de chaque code temporel. Or, un fuseau horaire sans heure d'été ne comporte pas de transitions historiques vers l'heure d'été. Par conséquent, les données d'hiver historiques sont décalées d'une heure dans les résultats SQL (par exemple, les codes temporels de janvier 2025 sont convertis au format UTC-5 au lieu de UTC-6), ce qui déplace les rapports horaires, les limites de jour et les filtres de date relative tels que last month.

Si vous choisissez tout de même de modifier les paramètres de fuseau horaire au niveau de la requête pour contourner now() dans les calculs de table (et que vous acceptez le décalage d'une heure dans les résultats SQL historiques d'hiver), vous pouvez modifier les paramètres suivants lorsqu'un fuseau horaire canadien concerné est configuré :

• Fuseaux horaires des comptes utilisateur : si l'option Fuseaux horaires spécifiques à l'utilisateur est activée, mettez à jour les fuseaux horaires des utilisateurs sur la page Utilisateurs du panneau Admin. Les utilisateurs individuels peuvent également modifier le paramètre Fuseau horaire sur la page Compte.
• Fuseau horaire de la requête de connexion à la base de données : si l'option Fuseaux horaires spécifiques à l'utilisateur est désactivée, mettez à jour le paramètre Fuseau horaire de la requête sur la page Connexions du panneau Admin.