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 dans 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 un look, 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.
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
- Fuseau horaire des requêtes
convert_tz
Paramètre LookMLsql
Paramètre LookML
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 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 dans l'application Looker. Pour les instances hébergées par Looker, le fuseau horaire système est toujours défini sur UTC. Les instances hébergées par le client peuvent se trouver dans un fuseau horaire différent. Il n'est pas simple de modifier le fuseau horaire du système, et nous vous le déconseillons. Si vous devez ajuster les codes temporels dans une exploration Activité du système, utilisez des calculs de tableau pour créer des colonnes ajustées en fonction du temps. Par exemple, pour convertir l'heure UTC en heure 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, vous définissez la valeur du fuseau horaire de la base de données sur la page Paramètres de connexion.
Ce paramètre représente le fuseau horaire de votre base de données, qui est généralement le temps universel coordonné (UTC). Si vous définissez 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 temporelles est l'option Fuseaux horaires spécifiques à l'utilisateur, qui se trouve sur la page Paramètres généraux de la section Admin de Looker.
Vous pouvez activer ou désactiver les fuseaux horaires spécifiques à l'utilisateur :
- Lorsqu'elle est activée, chaque utilisateur Looker est associé à un fuseau horaire, qui détermine l'apparence des résultats de ses requêtes.
- Lorsque cette option est désactivée, aucun fuseau horaire individuel n'est attribué aux comptes des utilisateurs. Toutes les requêtes sont exécutées à l'aide de la valeur Fuseau horaire de la requête.
Lorsque l'option Fuseaux horaires spécifiques aux utilisateurs est activée, un utilisateur peut définir son fuseau horaire sur la page Compte. Les administrateurs Looker peuvent également attribuer des fuseaux horaires aux utilisateurs sur la page Utilisateurs. Si aucun fuseau horaire n'est défini pour un utilisateur, son compte est défini par défaut sur le paramètre Fuseau horaire de l'application de Looker.
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 temporelles, Looker convertit les données du fuseau horaire de la base de données au fuseau horaire de l'utilisateur. Lorsqu'un utilisateur utilise des valeurs de filtre liées au temps dans une requête, Looker les convertit en fuseau horaire de la base de données.
De plus, lorsque vous activez cette option, Looker affiche un menu déroulant Fuseau horaire dans les explorations et les looks.
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.
- Liste de tous les fuseaux horaires individuels, que les utilisateurs peuvent choisir manuellement s'ils le souhaitent.
Par défaut, toutes les requêtes sont basées sur 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 son fuseau horaire est défini sur "America/New York". De même, l'analyse est toujours basée par défaut sur le fuseau horaire avec lequel la requête a été créée.
Lorsqu'ils consultent une requête, les utilisateurs peuvent utiliser le menu déroulant pour remplacer le fuseau horaire et choisir leur fuseau horaire du lecteur ou un autre fuseau horaire pour cette requête ou l'ensemble de requêtes de ce tableau de bord.
Éléments à prendre en compte avec les fuseaux horaires spécifiques à l'utilisateur
Lorsque vous activez l'option Fuseaux horaires spécifiques aux utilisateurs, les utilisateurs situés dans différents fuseaux horaires peuvent voir les données différemment.
Par exemple, les heures exactes qui composent la période last month
diffèrent selon les fuseaux horaires. Les utilisateurs peuvent donc voir des valeurs de données différentes s'ils se trouvent dans des fuseaux horaires différents, mais qu'ils 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 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 livraisons de contenu. Le fuseau horaire utilisé pour les envois de contenu n'a aucune incidence sur les données temporelles renvoyées par une requête. Il n'affecte que l'heure à laquelle un envoi de données est envoyé.
Si vous activez l'option Fuseaux horaires spécifiques à l'utilisateur, le fuseau horaire de l'application est le fuseau horaire par défaut pour les utilisateurs dont le compte n'est associé à aucun fuseau horaire.
Requête Fuseau horaire
L'option Fuseau horaire de la requête 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 des requêtes lorsque vous ajoutez une connexion à une base de données sur la page Paramètres de connexion.
Si vous désactivez les fuseaux horaires spécifiques à l'utilisateur,toutes les requêtes de données temporelles utilisent le fuseau horaire de la requête. Looker convertit toutes les données temporelles du fuseau horaire de la base de données en fuseau horaire de la requête.
Paramètre LookML convert_tz
Looker convertit les fuseaux horaires par défaut. 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 du dialecte de votre base de données dans le paramètre sql
d'une dimension LookML. Par exemple, pour définir manuellement la conversion du fuseau horaire dans MySQL, vous pouvez utiliser le LookML suivant :
dimension_group: created {
type: time
timeframes: [time, date]
sql: CONVERT_TZ(${TABLE}.created_at,'UTC','PST') ;;
}
Remarques sur le dialecte MySQL
MySQL nécessite une table de fuseaux horaires pour que sa fonction de conversion de fuseaux horaires fonctionne. Cette opération peut être effectuée par un administrateur. Pour en savoir plus, consultez la documentation MySQL.
Remarques sur le dialecte Postgres
Looker utilise le paramètre 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é.
Compatibilité des dialectes de base de données pour la conversion du fuseau horaire
Pour que Looker convertisse les fuseaux horaires dans votre projet, votre dialecte de base de données doit prendre en charge la conversion des fuseaux horaires. Le tableau suivant indique les dialectes qui prennent en charge la conversion du fuseau horaire dans la dernière version de Looker :
Dialecte | Compatibilité |
---|---|
Actian Avalanche | Non |
Amazon Athena | Oui |
Amazon Aurora MySQL | Oui |
Amazon Redshift | Oui |
Amazon Redshift 2.1+ | Oui |
Amazon Redshift Serverless 2.1+ | Oui |
Apache Druid | Non |
Apache Druid 0.13+ | Oui |
Apache Druid 0.18+ | Oui |
Apache Hive 2.3+ | Oui |
Apache Hive 3.1.2+ | Oui |
Apache Spark 3+ | Oui |
ClickHouse | Non |
Cloudera Impala 3.1+ | Oui |
Cloudera Impala 3.1+ with Native Driver | Oui |
Cloudera Impala with Native Driver | Oui |
DataVirtuality | Non |
Databricks | Oui |
Denodo 7 | Non |
Denodo 8 & 9 | Non |
Dremio | Oui |
Dremio 11+ | Oui |
Exasol | Non |
Firebolt | Non |
Google BigQuery Legacy SQL | Non |
Google BigQuery Standard SQL | 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+ | Non |
Microsoft SQL Server 2012+ | Non |
Microsoft SQL Server 2016 | Oui |
Microsoft SQL Server 2017+ | Oui |
MongoBI | Non |
MySQL | Oui |
MySQL 8.0.12+ | Oui |
Oracle | Oui |
Oracle ADWC | Oui |
PostgreSQL 9.5+ | Oui |
PostgreSQL pre-9.5 | Oui |
PrestoDB | Oui |
PrestoSQL | Oui |
SAP HANA | Non |
SAP HANA 2+ | Non |
SingleStore | Oui |
SingleStore 7+ | Oui |
Snowflake | Oui |
Teradata | Non |
Trino | Oui |
Vector | Non |
Vertica | Oui |