Le node Date & Time dans n8n : formater, calculer et comparer des dates sans code

Formater une date en DD/MM/YYYY, calculer une relance à J+7, mesurer l'âge d'un ticket : ces manipulations reviennent dans presque tous les workflows, et elles finissent trop souvent en expressions JavaScript bricolées ou en décalages de fuseau incompréhensibles. Le node Date & Time de n8n couvre justement ces cas sans écrire une ligne de code : il expose les opérations de date les plus courantes dans une interface visuelle, avec la même bibliothèque Luxon que les expressions en coulisses. Ce guide passe en revue ses opérations avec des exemples concrets, les pièges de fuseaux horaires à connaître, et les cas où une expression ou un node Code reste préférable.

Node Date & Time ou expression Luxon : lequel choisir ?

n8n offre deux voies pour manipuler des dates, et elles reposent sur le même moteur (Luxon) :

• le node Date & Time, une étape visible dans le canvas, configurée par menus déroulants ;
• les expressions Luxon directement dans un champ de n'importe quel node : {{ $now.setZone('Europe/Paris').toFormat('dd/MM/yyyy') }}.

La règle pratique : si la manipulation de date est une étape du workflow à part entière (calculer une échéance qui sera réutilisée par plusieurs nodes en aval, normaliser les dates d'un lot d'items), le node est plus lisible et plus facile à maintenir par un collègue non développeur. Si c'est un détail d'un seul champ (horodater le nom d'un fichier, injecter la date du jour dans un message), une expression en une ligne évite d'alourdir le canvas. Le fonctionnement complet de $now, $today et des méthodes Luxon est détaillé dans notre guide des dates et heures avec Luxon dans n8n, et la mécanique générale des {{ }} dans notre guide de la syntaxe des expressions n8n.

Un pipeline type qui combine les deux :

Webhook (ticket reçu) → Date & Time (Get Time Between Dates : âge du ticket)
      → IF (âge > 48 h ?) → Date & Time (Add to a Date : relance J+7)
      → Set (formater les champs) → Slack / Email

Les opérations du node, une par une

Le node Date & Time propose une liste d'opérations ; en voici les principales avec un cas d'usage réel pour chacune.

Format a Date — l'affichage lisible

L'opération la plus utilisée : elle prend une date d'entrée (champ d'un item, expression, ou date courante) et la restitue dans le format demandé. Les formats prédéfinis couvrent les cas standard, et un format personnalisé accepte les jetons Luxon :

Format	Résultat
dd/MM/yyyy	04/08/2026
dd LLLL yyyy	04 août 2026
yyyy-MM-dd'T'HH:mm	2026-08-04T09:30
cccc	mardi

Cas concret : un rapport hebdomadaire généré le lundi, dont l'objet d'email doit afficher « Rapport du 04/08/2026 ». Un node Date & Time en mode Format a Date, entrée {{ $now }}, format dd/MM/yyyy, et le champ de sortie s'injecte dans l'objet du node d'envoi.

Attention à la casse des jetons : en Luxon, mm désigne les minutes et MM le mois — l'inversion des deux est l'erreur de formatage la plus fréquente.

Add/Subtract Time — la relance à J+7

L'opération Add to a Date (et sa jumelle Subtract from a Date) additionne ou retranche une durée : indiquez la date de départ, la quantité, et l'unité (secondes à années). Le cas classique est la date de relance : un devis envoyé aujourd'hui doit déclencher un rappel dans 7 jours.

Le node calcule dateRelance = dateEnvoi + 7 jours, puis deux stratégies s'offrent à vous : stocker cette date dans votre CRM et laisser un workflow planifié la vérifier chaque matin, ou faire patienter le workflow lui-même jusqu'à l'échéance avec un node Wait en mode « Wait until specified time » pointant sur le champ calculé — un pattern détaillé dans notre guide du node Wait.

À savoir : l'ajout se fait en jours calendaires. Pour des jours ouvrés, il faut tester le jour de la semaine obtenu (weekday vaut 6 pour samedi, 7 pour dimanche en Luxon) et décaler — voir la recette en fin d'article.

Round a Date — arrondir au début du mois ou de la journée

Round a Date arrondit une date vers le bas ou vers le haut à l'unité choisie : début de la journée, du mois, de l'année… C'est l'opération à utiliser pour construire des bornes de période propres : « toutes les commandes depuis le début du mois » se calcule en arrondissant $now au début du mois, sans aucune manipulation manuelle de chaîne.

Extract Part of a Date — router selon le mois ou l'heure

Extract Part of a Date isole un composant : année, mois, jour, heure, minute… Utile pour du routage conditionnel : un node IF ou Switch en aval peut orienter les items selon le mois extrait (traitement de clôture en décembre), ou selon l'heure (file « urgente » pour les demandes reçues hors horaires ouvrés).

Get Current Date — l'horodatage de référence

Get Current Date insère la date-heure courante dans un champ, avec ou sans l'heure. C'est l'équivalent node de {{ $now }}, pratique pour horodater un traitement (« importé le… ») de façon visible dans le canvas. Si vous constituez un objet avec plusieurs champs dont un horodatage, il est souvent plus simple de tout regrouper dans un node Set avec une expression — notre guide du node Set / Edit Fields montre comment combiner champs statiques et expressions dans une même étape.

Get Time Between Dates — l'âge d'un ticket

Get Time Between Dates calcule l'écart entre deux dates dans l'unité choisie (minutes, heures, jours…). Exemple type : mesurer l'âge d'un ticket de support entre sa date de création et maintenant, pour escalader ceux qui dépassent 48 heures :

Date & Time (Get Time Between Dates)
  Start Date : {{ $json.created_at }}
  End Date   : {{ $now }}
  Units      : hours
→ IF (timeDifference.hours > 48) → escalade Slack

L'option « Include Other Units » renvoie l'écart décomposé (jours + heures + minutes), pratique pour un affichage humain (« ouvert depuis 2 j 5 h »).

Fuseaux horaires : les trois pièges classiques

Les dates décalées « d'exactement une ou deux heures » sont le symptôme numéro un d'un problème de fuseau, pas d'un bug de calcul. Trois mécanismes se superposent dans n8n :

1. GENERIC_TIMEZONE : la variable d'environnement de l'instance, qui fixe le fuseau par défaut de tous les workflows. Sur une instance auto-hébergée non configurée, c'est souvent UTC — d'où des horodatages qui semblent « en retard » de 2 h par rapport à l'heure de Paris en été.
2. Le fuseau du workflow : chaque workflow peut surcharger ce défaut dans ses réglages (Settings → Timezone). C'est ce fuseau qu'utilisent $now, $today et les déclencheurs planifiés — un point qui pièges beaucoup d'utilisateurs du Schedule Trigger, comme nous le détaillons dans notre guide du Schedule Trigger, du cron et des fuseaux horaires.
3. Les dates ISO reçues des API : une chaîne comme 2026-08-04T07:30:00Z est en UTC (le Z final). Si vous la formatez telle quelle en « heure de la journée », vous affichez l'heure UTC, pas l'heure locale. Il faut la convertir explicitement : option de timezone dans le node Date & Time, ou .setZone('Europe/Paris') en Luxon, avant tout formatage.

La règle d'or : stockez et transportez les dates en ISO 8601 UTC d'un bout à l'autre du workflow, et ne convertissez vers un fuseau local qu'au dernier moment, pour l'affichage. Ne corrigez jamais un décalage en ajoutant deux heures à la main : le workflow cassera au changement d'heure.

Ce soin apporté aux fuseaux n'est pas du perfectionnisme : dans les équipes réparties sur plusieurs fuseaux, le décalage temporel a un coût de coordination bien documenté. Une étude de J. Alberto Espinosa et Erran Carmel publiée en 2003 dans Software Process: Improvement and Practice pose les fondations conceptuelles de ce phénomène : la séparation temporelle entre membres d'une équipe distribuée engendre des coûts de coordination propres, distincts de la simple distance géographique (Espinosa & Carmel, 2003 — voir sur Google Scholar). Une automatisation qui envoie ses notifications à la bonne heure locale pour chaque destinataire réduit précisément ce type de friction — à condition que la gestion des fuseaux soit fiable.

Quand préférer une expression ou un node Code

Le node Date & Time atteint ses limites dans trois situations :

• Enchaînement d'opérations : « prendre la date de commande, ajouter 3 jours, arrondir au début de journée, formater en français » demanderait trois nodes Date & Time en série. Une expression Luxon le fait en une ligne : {{ DateTime.fromISO($json.orderDate).plus({ days: 3 }).startOf('day').setZone('Europe/Paris').toFormat('dd/MM/yyyy') }}.
• Logique conditionnelle sur la date : jours ouvrés, jours fériés, « le dernier vendredi du mois »… Dès qu'il y a un if dans le raisonnement, un node Code est plus clair. Notre guide du node Code et des expressions JavaScript couvre l'accès à Luxon (DateTime) depuis le node Code.
• Parsing de formats exotiques : une date reçue en 04-08-26 ou Aug 4th, 2026 ne sera pas toujours interprétée correctement. DateTime.fromFormat($json.date, 'dd-MM-yy') en Luxon lève l'ambiguïté explicitement.

Recettes prêtes à copier

Quatre expressions qui répondent aux besoins les plus fréquents — à coller dans un champ de node, ou à reproduire avec les opérations Date & Time équivalentes :

// Relance à J+7, au début de la journée, en ISO
{{ $now.plus({ days: 7 }).startOf('day').toISO() }}

// Horodatage de fichier : rapport-2026-08-04-0930.pdf
{{ 'rapport-' + $now.setZone('Europe/Paris').toFormat('yyyy-MM-dd-HHmm') + '.pdf' }}

// Âge d'un ticket en heures (nombre entier)
{{ Math.floor($now.diff(DateTime.fromISO($json.created_at), 'hours').hours) }}

// J+7 en sautant le week-end (samedi → lundi, dimanche → lundi)
{{ (() => { const d = $now.plus({ days: 7 }); return d.weekday === 6 ? d.plus({ days: 2 }) : d.weekday === 7 ? d.plus({ days: 1 }) : d; })().toISO() }}

En résumé

Le node Date & Time rend accessibles sans code les six manipulations de dates qui reviennent partout : formater, ajouter ou retrancher du temps, arrondir, extraire un composant, horodater et mesurer un écart. Réservez-le aux étapes de date qui méritent d'être visibles dans le canvas, passez à une expression Luxon quand une seule ligne suffit, et à un node Code dès que la logique devient conditionnelle. Surtout, traitez les fuseaux horaires comme une décision explicite — fuseau du workflow vérifié, dates en UTC en interne, conversion locale à l'affichage — plutôt que comme un décalage à rattraper : c'est ce qui distingue un workflow qui envoie sa relance à 9 h heure de Paris toute l'année d'un workflow qui dérive à chaque changement d'heure.