Fonctions de date SQL SFMC : DATEADD, DATEDIFF et fuseaux

Les dates sont l'endroit où beaucoup de requêtes d'audience SFMC dérapent sans bruit. Un filtre « 30 derniers jours » décalé de quelques heures, ou une règle « inactifs depuis 90 jours » qui compte le mauvais jour, envoie les mauvais contacts dans une campagne, sans la moindre erreur.

La réponse courte : les fonctions de date SQL SFMC suivent la syntaxe de SQL Server. GETDATE() donne l'instant présent, DATEADD() décale une date vers l'avant ou l'arrière, DATEDIFF() compte l'écart entre deux dates, et AT TIME ZONE sert quand vos dates stockées ne sont pas dans le même fuseau horaire que le serveur.

Ce guide présente les schémas les plus utilisés, avec du SQL prêt à copier, le piège du fuseau horaire et un tableau de référence. Si vous préférez éviter la syntaxe, vous pouvez aussi générer vos requêtes SQL SFMC en langage naturel.

‍

Comment fonctionnent les fonctions de date SQL dans SFMC

‍

GETDATE, DATEADD et DATEDIFF en une minute

Les query activities d'Automation Studio exécutent des requêtes SELECT en syntaxe SQL Server. La boîte à outils T-SQL pour les dates s'applique donc telle quelle, et trois fonctions couvrent l'essentiel des besoins de segmentation.

• GETDATE() renvoie la date et l'heure au moment où la requête s'exécute.
• DATEADD(unité, nombre, date) renvoie une date décalée d'un certain nombre d'unités. Un nombre négatif remonte dans le temps, par exemple DATEADD(DAY, -30, GETDATE()).
• DATEDIFF(unité, début, fin) renvoie le nombre de frontières d'unité entre deux dates, par exemple le nombre de jours entre un achat et aujourd'hui.

‍

Les unités courantes sont DAY, HOUR, MONTH et YEAR. Rappel : les requêtes SFMC sont en SELECT uniquement, sans variables. Toute expression de date doit donc figurer dans la requête elle-même.

‍

Quel fuseau horaire utilise GETDATE ?

C'est la question derrière la plupart des bugs de dates. Les praticiens SFMC indiquent que GETDATE() renvoie l'heure du serveur en Central America Standard Time, soit UTC-6 toute l'année, car ce fuseau n'applique pas l'heure d'été.

Les dates des data views comme _Open et _Click sont généralement décrites comme suivant la même convention. En revanche, les dates que vous importez peuvent être stockées dans votre fuseau local. Avant de vous y fier, lancez une requête de test sur votre propre compte et comparez le résultat à l'heure UTC actuelle.

‍

Schéma 1 : contacts actifs sur les 30 derniers jours avec DATEADD

‍

La demande la plus fréquente est une fenêtre glissante : tous ceux qui ont fait une action au cours des N derniers jours. Voici une version propre pour les ouvertures, construite sur la data view _Open.

SELECT
  o.SubscriberKey,
  MAX(o.EventDate) AS LastOpenDate
FROM _Open o
WHERE o.EventDate >= DATEADD(DAY, -30, GETDATE())
GROUP BY o.SubscriberKey

Voici le rôle de chaque partie.

• FROM _Open o lit tous les événements d'ouverture enregistrés sur votre compte, dans la limite de la rétention des data views.
• La clause WHERE ne garde que les événements des 30 derniers jours, comptés à rebours depuis l'exécution de la requête.
• MAX(o.EventDate) renvoie l'ouverture la plus récente de chaque abonné, ce qui donne une ligne par personne.
• GROUP BY o.SubscriberKey rend possible ce résultat à une ligne par personne.

‍

Data extension cible : Opened_Last_30_Days, clé primaire SubscriberKey. Type de mise à jour : Overwrite, pour reconstruire l'audience à chaque exécution. Pour la liste complète des colonnes disponibles, consultez notre guide pour interroger les data views SFMC.

‍

Gardez la fonction du bon côté de la comparaison

Remarquez que DATEADD() s'applique à GETDATE() et non à la colonne. Écrire EventDate >= DATEADD(...) garde la logique lisible et évite de transformer chaque ligne d'une grosse data view. Encapsuler la colonne dans une fonction est une habitude à perdre.

‍

Schéma 2 : jours depuis le dernier achat avec DATEDIFF

‍

Pour les audiences de réactivation, on part souvent d'une table clients qui contient la date du dernier achat. DATEDIFF fournit une colonne réutilisable pour prioriser les contacts ensuite.

SELECT
  c.SubscriberKey,
  c.EmailAddress,
  DATEDIFF(DAY, c.LastPurchaseDate, GETDATE()) AS DaysSincePurchase
FROM Customers_Master c
WHERE c.LastPurchaseDate < DATEADD(DAY, -90, GETDATE())

Ligne par ligne, la requête fonctionne ainsi.

• FROM Customers_Master c utilise une data extension clients générique, avec une ligne par personne.
• DATEDIFF(DAY, ...) AS DaysSincePurchase ajoute un nombre réutilisable dans la data extension, par exemple pour séparer les 90 à 180 jours des plus de 180 jours.
• La clause WHERE garde les clients dont le dernier achat date de plus de 90 jours.

‍

Data extension cible : Lapsed_90_Days, clé primaire SubscriberKey, type de mise à jour Overwrite. Pour la stratégie complète derrière cette audience, lisez comment construire une audience de réactivation dans SFMC.

‍

DATEDIFF compte des frontières, pas du temps écoulé

DATEDIFF(DAY, '2026-10-15 23:59', '2026-10-16 00:01') renvoie 1, alors que deux minutes seulement se sont écoulées, car une frontière de minuit a été franchie. C'est pourquoi la clause WHERE ci-dessus compare avec DATEADD() plutôt que de tester DATEDIFF directement : la fenêtre glissante reste exacte à l'heure près.

Utilisez DATEDIFF pour les colonnes d'affichage et la logique en jours calendaires. Utilisez DATEADD pour les fenêtres glissantes.

‍

Corriger les écarts de fuseau horaire dans vos requêtes SFMC

‍

L'écart qui renvoie de mauvaises lignes sans erreur

Imaginons une table de commandes dont les horodatages sont stockés à l'heure de Paris, parce que votre processus d'import les a écrits ainsi. Si vous les comparez à GETDATE(), vous comparez deux horloges différentes. La requête s'exécute, renvoie des lignes et n'affiche aucune erreur, mais la fenêtre est décalée de plusieurs heures.

La solution est de convertir l'heure du serveur dans le fuseau de vos données avant de comparer. La clause AT TIME ZONE de SQL Server le fait, et Microsoft en documente la syntaxe et les noms de fuseaux dans sa référence AT TIME ZONE.

SELECT
  o.OrderID,
  o.SubscriberKey,
  o.OrderDate
FROM Orders_Paris o
WHERE o.OrderDate >= CONVERT(DATETIME,
  DATEADD(HOUR, -2, GETDATE())
  AT TIME ZONE 'Central America Standard Time'
  AT TIME ZONE 'Romance Standard Time')

Voici comment la lire.

• DATEADD(HOUR, -2, GETDATE()) est le début de la fenêtre : il y a deux heures sur l'horloge du serveur.
• Le premier AT TIME ZONE indique à SQL Server dans quel fuseau cette valeur se trouve réellement.
• Le second AT TIME ZONE la convertit en Romance Standard Time, le nom Windows du fuseau qui couvre Paris, Bruxelles et Madrid.
• CONVERT(DATETIME, ...) retire le décalage pour que le résultat se compare proprement à une colonne datetime classique.

‍

Data extension cible : Recent_Orders_Paris, clé primaire OrderID, type de mise à jour Overwrite. Testez d'abord sur une petite fenêtre et vérifiez que la limite correspond à une ligne que vous pouvez contrôler à la main.

‍

Laissez le nom du fuseau gérer l'heure d'été

Ne codez jamais en dur « moins 1 heure » ou « moins 2 heures » pour passer d'un fuseau à l'autre. L'écart entre UTC-6 (sans heure d'été) et un fuseau européen change deux fois par an. Avec un fuseau nommé, SQL Server applique le bon décalage pour la date concernée.

‍

Référence rapide : les schémas de date à copier

‍

Objectif	Schéma
30 derniers jours	col >= DATEADD(DAY, -30, GETDATE())
Plus de 90 jours	col < DATEADD(DAY, -90, GETDATE())
Jours depuis un événement	DATEDIFF(DAY, col, GETDATE())
Début de la journée (horloge serveur)	DATEADD(DAY, DATEDIFF(DAY, 0, GETDATE()), 0)
Hier uniquement	col >= DATEADD(DAY, -1, DATEADD(DAY, DATEDIFF(DAY, 0, GETDATE()), 0)) AND col < DATEADD(DAY, DATEDIFF(DAY, 0, GETDATE()), 0)
7 prochains jours (par exemple anniversaires)	col >= GETDATE() AND col < DATEADD(DAY, 7, GETDATE())

‍

Une courte liste de contrôle avant de planifier une requête basée sur des dates :

1. Vérifiez dans quel fuseau horaire votre colonne de date est stockée.
2. Décidez si vous avez besoin d'une fenêtre glissante (DATEADD) ou de jours calendaires (DATEDIFF).
3. Exécutez-la une fois sur une petite période et contrôlez à la main la première et la dernière ligne.
4. Définissez la clé primaire de la data extension cible et choisissez Overwrite, Update ou Append en connaissance de cause.

‍

Erreurs fréquentes avec les dates en SQL SFMC

‍

• Dates en texte : si une date arrive sous forme de texte lors d'un import, convertissez-la avec CONVERT(DATETIME, champ) avant de comparer, et vérifiez les valeurs vides qui feraient échouer la conversion.
• Limites de minuit : une règle comme « hier » exige une borne de début et une borne de fin, sinon vous incluez aussi aujourd'hui.
• Heure d'exécution et heure de conception : GETDATE() est évaluée à l'exécution, pas à l'écriture. Une requête planifiée la nuit peut donc voir un autre jour calendaire que prévu.
• Fenêtres d'engagement : la même logique alimente les règles d'exclusion, comme dans notre article sur la recherche des contacts inactifs dans SFMC.

‍

Questions fréquentes

‍

Quel fuseau horaire renvoie GETDATE() dans SFMC ?

Les praticiens indiquent qu'elle renvoie l'heure du serveur en Central America Standard Time, soit UTC-6 sans heure d'été. Vérifiez toujours sur votre propre compte en comparant le résultat à l'heure UTC.

‍

Comment obtenir les 30 derniers jours en SQL SFMC ?

Comparez votre colonne de date à DATEADD(DAY, -30, GETDATE()) avec un « supérieur ou égal ». Vous obtenez une fenêtre glissante ancrée sur l'instant d'exécution de la requête.

‍

Quelle différence entre DATEADD et DATEDIFF ?

DATEADD renvoie une nouvelle date en décalant une date existante. DATEDIFF renvoie un nombre : combien de frontières d'unité séparent deux dates. Utilisez DATEADD pour les fenêtres et DATEDIFF pour les comptages.

‍

Pourquoi ma requête de dates renvoie-t-elle les mauvaises personnes sans erreur ?

La cause habituelle est la comparaison de dates stockées dans un fuseau avec GETDATE() dans un autre. Convertissez avec AT TIME ZONE pour que les deux côtés utilisent la même horloge.

‍

Construisez vos audiences par date en quelques secondes avec QAiry

‍

Les fenêtres de dates sont typiquement le genre de détail facile à rater d'un cran quand on écrit le SQL à la main. QAiry transforme une demande en langage naturel comme abonnés qui ont ouvert au cours des 30 derniers jours mais pas des 7 derniers en SQL SFMC et en data extension, installé comme une application dans votre propre SFMC.

Vous pouvez essayer QAiry gratuitement ou regarder une démo produit pour voir comment il gère les dates et les data views.