MaxCompute:Configuration du fuseau horaire

Définition du fuseau horaire pour une session

Soumettez la commande SET odps.sql.timezone=<timezoneid>; conjointement avec votre requête SQL.

-- Set the time zone to Asia/Tokyo for this session.
SET odps.sql.timezone=Asia/Tokyo;

Pour vérifier le fuseau horaire actif, exécutez la commande SELECT getdate(); :

SELECT getdate();

Résultat attendu :

+---------------------+
| _c0                 |
+---------------------+
| 2018-10-30 23:49:50 |
+---------------------+

Définition du fuseau horaire pour un projet

Exécutez la commande suivante en tant que propriétaire du projet :

setProject odps.sql.timezone=<timezoneid>;

Format du fuseau horaire

Utilisez les noms de fuseaux horaires IANA, tels que Asia/Shanghai. N'utilisez pas le format de décalage GMT+9.

Le format GMT+N ne prend pas en charge l'heure d'été, ce qui peut entraîner des erreurs de calcul. Les noms de fuseaux horaires IANA gèrent automatiquement les changements d'heure et évitent toute ambiguïté.

Compatibilité SDK et clients

• Les fonctions natives de date SQL, les fonctions définies par l'utilisateur (UDF), les types définis par l'utilisateur (UDT), les jointures définies par l'utilisateur (UDJ) et l'instruction SELECT TRANSFORM peuvent tous lire l'attribut de fuseau horaire du projet.

• Si le fuseau horaire configuré dans le SDK pour Java diffère de celui du projet, définissez le fuseau GMT dans le SDK afin de convertir correctement les données DATETIME en STRING.

• Si votre fuseau horaire local n'est pas UTC+8 lors de la mise à jour de MaxCompute, mettez à jour le SDK pour Java et le client associé vers les versions portant le suffixe -oversea. Cela garantit l'exactitude et la cohérence des résultats SQL et des données transférées via les commandes Tunnel pour les dates postérieures au 1er janvier 1900.

Différences historiques pour les données datetime

Après configuration d'un fuseau horaire autre que UTC+8, des écarts peuvent apparaître entre l'heure réelle et le résultat des instructions SQL exécutées dans DataWorks :

Après mise à jour vers les versions avec le suffixe -oversea :

• Les données DATETIME antérieures au 1er janvier 1900 peuvent encore présenter un écart allant jusqu'à 343 secondes.

• Les données DATETIME antérieures au 1er janvier 1928, chargées avant la mise à jour, apparaîtront avec 352 secondes d'avance dans les nouvelles versions.

Sans mise à jour vers le suffixe -oversea :

• Les résultats SQL peuvent différer des données transférées par les commandes Tunnel.

• Avant le 1er janvier 1900 : écart de 9 secondes.

• Du 1er janvier 1900 au 1er janvier 1928 : écart de 352 secondes.

Fuseau horaire de DataWorks

La modification du fuseau horaire du SDK pour Java ou du client n'affecte pas le fuseau horaire du serveur DataWorks. Évaluez l'impact sur vos tâches planifiées DataWorks. Fuseaux horaires des serveurs DataWorks par région :

Clients JDBC tiers

Si vous vous connectez à MaxCompute via un client tiers utilisant JDBC (Java Database Connectivity), configurez le fuseau horaire correspondant sur le client afin de maintenir la cohérence avec le serveur.