En SQL, il existe un large éventail de fonctions pour travailler avec les dates et les intervalles : DATEDIFF, DATEADD (T-SQL), gestion du type INTERVAL (PostgreSQL), fonctionnalité de conversion des heures dans différents fuseaux horaires (AT TIME ZONE). Pour un fonctionnement correct avec les dates, il est essentiel d'utiliser des types de données prenant en compte le fuseau horaire (TIMESTAMP WITH TIME ZONE, timestamptz), et non seulement DATE ou DATETIME, surtout pour des services globaux.
Dans différentes SGBD, la syntaxe et les spécificités varient :
DATEDIFF, DATEADD, FORMAT, mais pas de véritable INTERVAL. Les fuseaux horaires sont gérés explicitement.Des erreurs surviennent souvent à cause d'incohérences de stockage en UTC/heure locale et du mélange d'opérations ne tenant pas compte de la différence.
SELECT EXTRACT(EPOCH FROM (event_end AT TIME ZONE 'UTC' - event_start AT TIME ZONE 'UTC')) / 3600 AS hours FROM events
La différence de dates dans DATEDIFF peut-elle donner un nombre négatif, et que signifie leur ordre ?
Réponse : Oui, DATEDIFF (DATEDIFF(day, d1, d2)) retourne un nombre négatif si d2 < d1. Il est important de ne pas confondre l'ordre des paramètres : d'abord l'unité de mesure, ensuite la date de début, puis la date de fin.
Exemple :
SELECT DATEDIFF(day, '2024-05-01', '2024-04-25') -- renverra -6
Histoire
Dans un projet avec des utilisateurs globaux, les rapports étaient construits selon l'heure locale des serveurs dans chaque région. Résultat — des agrégats décalés par date et des "trous" à la frontière des jours pour les utilisateurs d'autres fuseaux horaires. Corrigé en convertissant toutes les données temporelles en UTC et en recalculant uniquement pour l'affichage.
Histoire
Lors du calcul de la durée d'abonnement via DATEDIFF, l'ordre des dates a été inversé. En conséquence, certains utilisateurs ont été à tort identifiés comme "super-utilisateurs" avec une ancienneté préalablement négative. Corrigé par l'introduction d'une vérification de l'ordre des dates.
Histoire
Un développeur a stocké un DATETIME sans considérer le fuseau horaire, lors de la migration vers PostgreSQL, les valeurs ont été interprétées comme UTC, alors qu'initialement elles étaient en GMT+3, ce qui a conduit à un décalage des événements dans les rapports de 3 heures en arrière. Conclusion — toujours stocker et convertir les dates en tenant compte de la zone !