Looker peut faciliter la compréhension des données temporelles en les convertissant dans différents fuseaux horaires. Les utilisateurs peuvent consulter les résultats des requêtes et créer des filtres avec des données temporelles converties en fonction de leur fuseau horaire local. Par exemple, un utilisateur à 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. Au lieu de cela, 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.
Plusieurs paramètres de Looker 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
- Requête 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 exécutant 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 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 des 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 les fuseaux horaires spécifiques à l'utilisateur :
- Lorsque cette option est activée, un fuseau horaire est attribué à chaque utilisateur Looker. Ce fuseau horaire spécifie l'apparence des résultats de ses requêtes.
- Lorsque cette option est désactivée, aucun fuseau horaire n'est attribué aux comptes des utilisateurs. Toutes les requêtes s'exécutent plutôt à l'aide de la valeur Query Time Zone (Fuseau horaire de la requête).
Lorsque les fuseaux horaires spécifiques aux utilisateurs sont activés, un utilisateur peut définir son fuseau horaire sur la page 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, celle-ci est créée dans son fuseau horaire. Par conséquent, lorsqu'une requête renvoie des données basées sur le temps, Looker convertit les données du fuseau horaire de la base de données en fonction du fuseau horaire de l'utilisateur. Lorsqu'un utilisateur utilise des valeurs de filtre liées au temps 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 Explorers et Recherches.
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 sont par défaut basées dans le fuseau horaire dans lequel elles ont été créées. 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 « Amérique/New York ». De même, l'analyse transversale utilise toujours le fuseau horaire par défaut de la requête.
Chaque fois qu'ils consultent une requête, les utilisateurs peuvent utiliser le menu déroulant pour remplacer le fuseau horaire en sélectionnant leur fuseau horaire du lecteur ou un autre fuseau horaire pour cette requête ou l'ensemble de requêtes du tableau de bord.
Éléments à prendre en compte avec 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
Le paramètre Fuseau horaire de l'application peut être configuré sur la page General Settings (Paramètres généraux) de la section Admin (Administration) 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. cela affecte uniquement le moment où une livraison de données est envoyée.
Si vous activez l'option User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur), le fuseau horaire de l'application est le fuseau horaire par défaut pour les utilisateurs qui n'ont pas défini de fuseau horaire 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, vous définissez la valeur Fuseau horaire de la requête lorsque vous ajoutez une connexion à une base de données sur la page 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 du 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 de 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 utilise 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 | Compatibilité |
|---|---|
| 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 ou version ultérieure | Oui |
| Apache Hive 3.1.2 et versions ultérieures | Oui |
| Apache Spark 3 ou version ultérieure | Oui |
| ClickHouse | Non |
| Cloudera Impala 3.1+ | Oui |
| Cloudera Impala 3.1 et versions ultérieures avec pilote natif | Oui |
| Cloudera Impala avec pilote natif | Oui |
| DataVirtuality | Non |
| Databricks | Oui |
| Denodo 7 | Non |
| Denodo 8 | Non |
| Dremio | Oui |
| Dremio 11 ou version ultérieure | Oui |
| Exasol | Non |
| Feu | Non |
| Google BigQuery Legacy SQL | 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 |
| Microsoft Azure SQL Database | Oui |
| Microsoft Azure Synapse Analytics | Oui |
| Microsoft SQL Server 2008 et versions ultérieures | Non |
| Microsoft SQL Server 2012 ou version ultérieure | Non |
| Microsoft SQL Server 2016 | Oui |
| Microsoft SQL Server 2017 ou version ultérieure | Oui |
| MongoBI | Non |
| MySQL | Oui |
| MySQL 8.0.12 ou version ultérieure | Oui |
| Oracle | Oui |
| Oracle ADWC | Oui |
| PostgreSQL 9.5 ou version ultérieure | Oui |
| PostgreSQL version antérieure à 9.5 | Oui |
| PrestoDB | Oui |
| PrestoSQL | Oui |
| SAP HANA 2 ou version ultérieure | Non |
| SingleStore | Oui |
| SingleStore 7 et versions ultérieures | Oui |
| Snowflake | Oui |
| Teradata | Non |
| Trino | Oui |
| Vecteur | Non |
| Vertica | Oui |