Looker peut faciliter la compréhension des données temporelles en les convertissant en différents fuseaux horaires. Les utilisateurs peuvent consulter les résultats des requêtes et créer des filtres avec des données temporelles qui sont converties dans leur fuseau horaire local. Par exemple, un utilisateur basé à New York qui consulte des données créées en Californie n'a pas besoin de soustraire manuellement trois heures pour filtrer ou interpréter ses requêtes.
Looker convertit les données temporelles lorsqu'il génère du code SQL lors d'une requête pour une présentation, une exploration ou un tableau de bord. Les données sous-jacentes ne sont pas affectées ; les résultats de la requête sont convertis à l'aide des paramètres de fuseau horaire de Looker. Cela signifie également que les requêtes exécutées à l'aide de SQL Runner ne convertissent pas les données temporelles.
Dans Looker, plusieurs paramètres spécifient comment convertir les données temporelles:
- Fuseau horaire du système
- Fuseau horaire de la base de données
- Fuseaux horaires spécifiques à l'utilisateur
- Fuseau horaire de l'application
- Interroger le fuseau horaire
- Paramètre LookML
convert_tz - Paramètre LookML
sql
Fuseau horaire du système
Le fuseau horaire du système est celui pour lequel le serveur qui exécute Looker est configuré. La base de données interne de Looker, qui stocke les informations disponibles dans les explorations i__looker et Activité du système, stocke les données temporelles dans le fuseau horaire du système.
Le fuseau horaire du système n'est pas configurable via l'application Looker. Pour les instances hébergées par Looker, le fuseau horaire du système est toujours défini sur UTC. Les instances hébergées par le client peuvent se trouver dans un fuseau horaire système différent. Le changement de fuseau horaire du système n'est pas simple et n'est pas recommandé. Si vous devez ajuster les codes temporels dans une i__looker ou une exploration de l'activité du système, Looker vous recommande d'utiliser des calculs de table pour créer des colonnes ajustées dans le temps. Par exemple, pour convertir une valeur UTC en EST, vous pouvez créer une colonne avec le calcul de table add_hours(-5, ${time}).
Fuseau horaire de la base de données
Lorsque vous ajoutez une connexion à une base de données, définissez la valeur du paramètre Database Time Zone (Fuseau horaire de la base de données) sur la page Connection Settings (Paramètres de connexion).
Ce paramètre représente le fuseau horaire dans lequel se trouve votre base de données, qui correspond généralement au temps universel coordonné (UTC). Si vous définissez cette valeur sur une valeur autre que le fuseau horaire de votre base de données, vous risquez d'obtenir des résultats inattendus.
Fuseaux horaires spécifiques à l'utilisateur
Le paramètre le plus important pour la conversion des données en fonction de l'heure est l'option User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur), qui se trouve sur la page General Settings (Paramètres généraux) de la section Admin de Looker.
Vous pouvez activer ou désactiver User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur) :
- Lorsque cette option est activée, chaque utilisateur Looker est associé à un fuseau horaire qui spécifie l'apparence des résultats de la requête.
- Lorsque cette option est désactivée, aucun fuseau horaire n'est attribué aux utilisateurs dans leur compte. Toutes les requêtes s'exécutent plutôt à l'aide de la valeur Query Time Zone (Fuseau horaire de la requête).
Lorsque l'option Fuseaux horaires spécifiques à l'utilisateur est activée, un utilisateur peut définir son fuseau horaire sur la page Compte de son compte, ou les administrateurs Looker peuvent attribuer des fuseaux horaires aux utilisateurs sur la page Utilisateurs. Si aucun fuseau horaire n'est défini pour un utilisateur, son compte utilise par défaut le paramètre Looker Fuseau horaire de l'application.
Chaque fois qu'un utilisateur crée une requête, cette requête est créée dans le fuseau horaire de l'utilisateur. Par conséquent, lorsqu'une requête renvoie des données temporelles, Looker convertit les données du fuseau horaire de la base de données vers le fuseau horaire de l'utilisateur. Lorsqu'un utilisateur utilise des valeurs de filtre temporelles dans une requête, Looker convertit les valeurs de filtre dans le fuseau horaire de la base de données.
De plus, lorsque vous activez cette option, Looker affiche un menu déroulant Fuseau horaire dans Explorations et Présentations.
Les options de ce menu déroulant sont les suivantes:
- Fuseau horaire de chaque vignette (tableaux de bord uniquement) : toutes les requêtes sont exécutées dans le fuseau horaire dans lequel elles ont été enregistrées.
- Fuseau horaire du lecteur: toutes les requêtes sont exécutées dans le fuseau horaire actuel de l'utilisateur.
- Une liste de tous les fuseaux horaires, que les utilisateurs peuvent choisir manuellement s'ils le souhaitent.
Toutes les requêtes utilisent par défaut le fuseau horaire avec lequel la requête a été créée. En d'autres termes, si Alice crée une requête avec le fuseau horaire "America/Los Angeles" et l'envoie à Bob, Bob verra la requête avec le fuseau horaire "America/Los Angeles", même si le fuseau horaire de Bob est défini sur "America/New York". De même, l'analyse détaillée utilise toujours par défaut le fuseau horaire dans lequel la requête a été créée.
Lorsqu'ils consultent une requête, les utilisateurs peuvent utiliser la liste déroulante pour remplacer le fuseau horaire, en sélectionnant leur Fuseau horaire du lecteur ou tout autre fuseau horaire pour cette requête ou l'ensemble de requêtes du tableau de bord.
Éléments à prendre en compte concernant les fuseaux horaires spécifiques à l'utilisateur
Lorsque vous activez l'option User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur), les utilisateurs peuvent voir les données différemment selon les fuseaux horaires.
Par exemple, les heures exactes correspondant à la période last month peuvent différer selon les fuseaux horaires. Par conséquent, les utilisateurs peuvent voir des valeurs de données différentes s'ils se trouvent dans des fuseaux horaires différents, mais filtrent tous les deux sur last month.
Fuseau horaire de l'application
Vous pouvez configurer le paramètre Fuseau horaire de l'application sur la page Paramètres généraux de la section Admin de Looker.
Le fuseau horaire de l'application est le fuseau horaire par défaut pour les diffusions de contenu. Le fuseau horaire utilisé pour les diffusions de contenu n'affecte pas les données temporelles renvoyées par une requête. Il affecte uniquement l'heure d'envoi des données.
Si vous activez l'option User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur), Application Time Zone (Fuseau horaire de l'application) est le fuseau horaire par défaut pour les utilisateurs dont la valeur de fuseau horaire n'est pas définie pour leur compte.
Requête Fuseau horaire
L'option Requête de fuseau horaire ne s'affiche que si vous avez désactivé Fuseaux horaires spécifiques à l'utilisateur. Dans ce cas, définissez la valeur Query Time Zone (Fuseau horaire de la requête) lorsque vous ajoutez une connexion à une base de données sur la page Connection Settings (Paramètres de connexion).
Si vous désactivez l'option User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur), toutes les requêtes de données basées sur l'heure utilisent le fuseau horaire de requête et Looker convertit toutes les données basées sur l'heure du fuseau horaire de la base de données dans le fuseau horaire de la requête.
Paramètre LookML convert_tz
Par défaut, Looker effectue la conversion du fuseau horaire. Pour désactiver la conversion du fuseau horaire pour un champ individuel, vous pouvez utiliser le paramètre LookML convert_tz. Exemple :
dimension_group: created {
type: time
timeframes: [time, date]
convert_tz: no
}
Pour en savoir plus, consultez la page de documentation sur le paramètre convert_tz.
Paramètre LookML sql
Vous pouvez également définir manuellement la conversion du fuseau horaire à l'aide des fonctions de votre dialecte de base de données dans le paramètre sql d'une dimension LookML. Par exemple, pour définir manuellement la conversion de fuseau horaire dans MySQL, vous pouvez utiliser le code LookML suivant:
dimension_group: created {
type: time
timeframes: [time, date]
sql: CONVERT_TZ(${TABLE}.created_at,'UTC','PST') ;;
}
Notes de dialecte MySQL
MySQL nécessite une table des fuseaux horaires pour que sa fonction de conversion de fuseau horaire fonctionne. Elle peut être exécutée par un administrateur. Pour en savoir plus, consultez la documentation MySQL.
Notes de dialecte Postgres
Looker utilise les paramètres du pilote pour sélectionner le fuseau horaire cible. Cela peut affecter le traitement des requêtes dans SQL Runner par rapport à pgAdmin, car Looker utilisera la date et l'heure actuelles dans le fuseau horaire sélectionné.
Prise en charge des dialectes de base de données pour la conversion du fuseau horaire
Pour que Looker puisse convertir les fuseaux horaires de votre projet, votre dialecte de base de données doit prendre en charge la conversion des fuseaux horaires. Le tableau suivant présente les dialectes compatibles avec la conversion de fuseau horaire dans la dernière version de Looker:
| Dialecte | Compatible ? |
|---|---|
| Avalanche d'Actian | Non |
| Amazon Athena | Oui |
| Amazon Aurora MySQL | Oui |
| Amazon Redshift | Oui |
| Apache Druid | Non |
| Apache Druid 0.13 et versions ultérieures | Oui |
| Apache Druid 0.18 et versions ultérieures | Oui |
| Apache Hive 2.3 et versions ultérieures | Oui |
| Apache Hive 3.1.2 et versions ultérieures | Oui |
| Apache Spark 3 et versions ultérieures | Oui |
| ClickHouse | Non |
| Cloudera Impala 3.1+ | Oui |
| Cloudera Impala 3.1+ avec pilote natif | Oui |
| Cloudera Impala avec Native Driver | Oui |
| DataVirtuality | Non |
| Databricks | Oui |
| Denodo 7 | Non |
| Denodo 8 | Non |
| Dremio | Oui |
| Dremio 11 et versions ultérieures | Oui |
| Exasol | Non |
| Feu | Non |
| Ancien SQL de Google BigQuery | Non |
| SQL standard Google BigQuery | Oui |
| Google Cloud PostgreSQL | Oui |
| Google Cloud SQL | Oui |
| Google Spanner | Oui |
| Greenplum | Oui |
| HyperSQL | Non |
| IBM Netezza | Oui |
| MariaDB | Oui |
| Microsoft Azure PostgreSQL | Oui |
| Base de données Microsoft Azure SQL | Oui |
| Microsoft Azure Synapse Analytics | Oui |
| Microsoft SQL Server 2008 et versions ultérieures | Non |
| Microsoft SQL Server 2012 et versions ultérieures | Non |
| Microsoft SQL Server 2016 | Oui |
| Microsoft SQL Server 2017 et versions ultérieures | Oui |
| MongoBI | Non |
| MySQL | Oui |
| MySQL 8.0.12 et versions ultérieures | Oui |
| Oracle | Oui |
| Oracle ADWC | Oui |
| PostgreSQL 9.5 et versions ultérieures | Oui |
| PostgreSQL version antérieure à 9.5 | Oui |
| PrestoDB | Oui |
| PrestoSQL | Oui |
| SAP HANA 2 et versions ultérieures | Non |
| SingleStore | Oui |
| SingleStore 7 et versions ultérieures | Oui |
| Snowflake | Oui |
| Teradata | Non |
| Trino | Oui |
| Vecteur | Non |
| Vertica | Oui |