convert_tz

Utilisation

view: view_name {
  dimension: field_name {
    convert_tz: yes | no
  }
}
Hiérarchie
convert_tz
Types de champs possibles
Dimension, groupe de dimensions, mesure, filtre, paramètre

Acceptation
Booléen (oui ou non)

Définition

Looker propose différents paramètres de fuseau horaire qui convertissent les données temporelles entre différents fuseaux horaires. Looker effectue la conversion du fuseau horaire par défaut. Si vous ne souhaitez pas que Looker effectue une conversion de fuseau horaire pour un dimension, un dimension_group (avec type: time) ou un filter spécifique, vous pouvez utiliser le paramètre convert_tz. Cela peut être utile pour les champs qui sont déjà convertis dans le fuseau horaire approprié ou dans certaines situations avancées où vous devez éviter une double conversion de fuseau horaire.

En général, les calculs de temps (différences, durées, etc.) ne fonctionnent correctement que si vous utilisez des valeurs temporelles qui sont toutes converties dans le même fuseau horaire. Il est important de tenir compte des fuseaux horaires lorsque vous écrivez du code LookML.

Exemples

Ne pas effectuer de conversion du fuseau horaire pour le groupe de dimensions local_created :

dimension_group: local_created {
  type: time
  timeframes: [time, date, week, month]
  sql: ${TABLE}.local_created_at ;;
  convert_tz: no
}

Éléments à prendre en compte

convert_tz: no ne s'applique qu'à une dimension, et non à un filtre qui l'utilise. En d'autres termes, les filtres effectuent toujours la conversion du fuseau horaire. Lorsque vous spécifiez convert_tz: no, les valeurs de données basées sur l'heure s'affichent dans le fuseau horaire de la base de données, mais sont filtrées à l'aide du fuseau horaire de la requête.

Étant donné que les filtres effectuent toujours une conversion du fuseau horaire, une différence entre le fuseau horaire de la base de données et celui de la requête peut entraîner l'inclusion ou l'exclusion inattendue de données d'un ensemble de données. Pour éviter cela, assurez-vous que le fuseau horaire de la requête est défini sur la même valeur que celui de la base de données.

Si l'option Fuseaux horaires spécifiques à l'utilisateur est activée, définissez le menu déroulant du fuseau horaire (situé à côté du bouton Exécuter sur les explorations, les Looks et les tableaux de bord) sur la même valeur que le fuseau horaire de la base de données. Si l'option Fuseaux horaires spécifiques à l'utilisateur est désactivée, définissez le fuseau horaire de la requête sur la même valeur que le fuseau horaire de la base de données.

Si vous utilisez des filtres personnalisés, laissez la conversion du fuseau horaire activée pour garantir des comparaisons de dates valides. Si vous désactivez la conversion du fuseau horaire avec convert_tz: no et que vous incluez le champ dans un filtre personnalisé, vos comparaisons de dates peuvent être non valides.

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
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica