Discussion :

[pwrdwnsys]

Bonjour à tous.

Lorsque j'utilise la fonction JSON_TABLE pour parser un flux JSON qui contient des timestamp en format ISO-8601 ("yyyy-mm-ddThh:mm:ss.nnnnnn<+/-Offset>"), la valeur du timestamp qui est renvoyée est systématiquement remise à la valeur UTC et non ma valeur locale (UTC + time zone).

Par exemple, cette instruction SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select * from json_table('{"root": {"ts1": "2023-05-31T12:21:57.123456+02:00"}}', 'lax $.root[*]' columns(ts1 timestamp PATH 'lax $.ts1'));

Résultat : ts1 = 2023-05-31 10:21:57.123456

Ce qui signifie que le timestamp produit est UTC ("10:21:57.123456" : il prend la valeur transmise et lui enlève les 2 heures indiquées par "+02:00") au lieu de d'être local à UTC +2 ("12:21:57.123456")

Alors que si on exécute cette instruction SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select * from json_table('{"root": {"ts1": "2023-05-31T12:21:57.123456"}}', 'lax $.root[*]' columns(ts1 timestamp PATH 'lax $.ts1'));

Résultat : ts1 = 2023-05-31 12:21:57.123456

Le timestamp produit ("12:21:57.123456") correspond à celui transmis ("12:21:57.123456").

Quelqu'un connait-il un moyen d'indiquer à SQL de ne pas tenir compte du time zone (le +02:00) pour renvoyer la valeur du timestamp ?

[pwrdwnsys]

Si on pousse un peu plus loin les tests sur cette fonction, on s'aperçoit que le comportement du traitement de la time zone n'est pas le même sur un champ timestamp que sur un champ time. cette instruction SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from json_table('{"root": {"ts1": "2023-05-31T12:21:57.123456+02:00", "t1": "12:21:57+02:00"}}', 'lax $.root[*]' columns(ts1 timestamp PATH 'lax $.ts1', t1 time PATH 'lax $.t1'));

renvoie ce résultat :

Pour le champ timestamp, SQL considère qu'il doit produire un résultat UTC+0, donc retrancher le timezone, alors que pour le champ time, SQL considère qu'il doit produire l'heure telle que transmise, donc dans mon exemple en UTC+2.
Le point service IBM se rapproche des lab IBM pour connaitre la raison de cette différence.