Calcul de dates x jours en bash
Calculez rapidement une date future ou passée à partir d’une date de départ, d’un nombre de jours et d’un mode d’ajout ou de soustraction. Cet outil est pensé pour les administrateurs système, développeurs shell, équipes DevOps et utilisateurs Linux qui veulent valider une commande date avant de l’exécuter en Bash.
Sélectionnez une date, saisissez un nombre de jours, puis cliquez sur le bouton pour obtenir la date calculée, la variation en semaines et une commande Bash prête à l’emploi.
Guide expert du calcul de dates x jours en Bash
Le calcul de dates x jours en Bash est une opération extrêmement fréquente dans les environnements Linux et Unix. On la rencontre dans les scripts de sauvegarde, les traitements batch, les tâches planifiées par cron, les pipelines DevOps, les rotations de logs, les systèmes de rétention, les audits, ainsi que dans les scripts d’administration quotidiens. Pourtant, derrière une apparente simplicité, le sujet cache plusieurs points importants: le comportement de la commande date, la différence entre une implémentation GNU et BSD, la gestion des mois, le passage à l’heure d’été, l’UTC, les formats de sortie et la robustesse des scripts destinés à la production.
Quand un administrateur dit qu’il veut “ajouter 30 jours à une date” ou “soustraire 7 jours à aujourd’hui”, il attend généralement un résultat juste, reproductible et facile à intégrer dans une variable shell. En Bash, la réponse la plus courante consiste à utiliser la commande date avec l’option -d sous GNU/Linux. Par exemple, date -d "2025-01-01 +30 days" +"%Y-%m-%d" permet de calculer une date future au format ISO. Cela paraît direct, mais pour écrire des scripts fiables, il faut comprendre ce qui se passe réellement, dans quelles conditions la commande marche, et quels garde-fous ajouter.
Le principe de base
Dans Bash, on n’effectue pas le calcul calendaire “à la main”. On délègue ce travail à la commande système date, capable d’analyser une date d’entrée, une expression relative et un format de sortie. L’intérêt est immense: le moteur de calcul gère automatiquement les années bissextiles, les changements de mois, la longueur variable des mois et la normalisation des valeurs. Cela signifie qu’une opération comme “ajouter 45 jours au 20 janvier” franchira naturellement février, puis mars, sans que vous ayez besoin d’écrire une logique complexe.
- Date de départ: une date explicite, par exemple
2025-02-10. - Décalage: un nombre de jours positif ou négatif.
- Sortie: un format lisible pour l’humain ou standardisé pour les scripts.
- Contexte: fuseau local ou UTC selon le besoin métier.
Exemples Bash les plus utilisés
Dans un système GNU/Linux classique, les commandes ci-dessous couvrent une grande partie des cas courants:
date -d "+7 days" +"%Y-%m-%d"pour connaître la date dans 7 jours.date -d "-14 days" +"%Y-%m-%d"pour obtenir la date 14 jours plus tôt.date -d "2025-03-01 +30 days" +"%Y-%m-%d"pour partir d’une date donnée.date -u -d "2025-03-01 +30 days" +"%Y-%m-%dT%H:%M:%SZ"pour produire une sortie en UTC.
Le format %Y-%m-%d est particulièrement apprécié, car il est triable lexicalement, lisible, compact et largement compatible avec les outils de traitement de texte, de monitoring, d’automatisation ou de stockage. Pour un script de sauvegarde, on peut écrire par exemple:
expiration=$(date -d "$date_reference +90 days" +"%Y-%m-%d")
Cette approche permet de définir une date d’expiration, une période de rétention ou un délai contractuel sans recoder la logique du calendrier.
Pourquoi les erreurs arrivent souvent
Les erreurs proviennent généralement non pas du calcul lui-même, mais du contexte d’exécution. La première source d’erreur est la différence entre GNU date et BSD date. Sur la plupart des distributions Linux, la syntaxe -d est disponible. Sur macOS, la commande native date utilise une logique différente, et les expressions relatives ne fonctionnent pas toujours de la même manière. Un script testé sous Ubuntu peut donc échouer sur un poste macOS si aucune compatibilité n’est prévue.
Deuxième difficulté: le fuseau horaire. Si votre calcul doit être purement calendaire, le fuseau local peut suffire. En revanche, dans les scripts inter-serveurs, les API, les jobs de synchronisation ou la journalisation d’événements, travailler en UTC réduit fortement les ambiguïtés. C’est particulièrement utile lorsque vos serveurs tournent dans plusieurs régions ou quand les opérations de maintenance traversent un changement d’heure.
Impact des changements d’heure et de l’UTC
Ajouter “1 jour” et ajouter “24 heures” sont des opérations proches, mais conceptuellement différentes. Dans beaucoup de cas, elles mènent au même résultat. Toutefois, autour des transitions d’heure d’été ou d’heure d’hiver, la réalité du temps civil peut introduire des décalages si le script manipule à la fois une date et une heure. Lorsqu’on raisonne en jours calendaires, il est souvent plus sûr d’utiliser une date sans heure explicite, ou de normaliser en UTC lorsque la précision et la répétabilité priment.
| Contexte | Approche recommandée | Avantage principal | Risque réduit |
|---|---|---|---|
| Scripts locaux simples | Fuseau local, format %Y-%m-%d |
Lecture humaine immédiate | Complexité inutile |
| Serveurs multi-régions | UTC avec -u |
Cohérence inter-environnements | Décalages liés au fuseau |
| Rotation de logs | ISO 8601 | Tri et parsing faciles | Formats ambigus |
| Jobs cron critiques | Date calculée puis validation | Moins d’erreurs silencieuses | Exécution au mauvais jour |
Quelques chiffres utiles à connaître
Pour bien choisir une stratégie, il est utile de rappeler certaines données calendaires réelles. Une semaine contient 7 jours, mais un mois ne contient pas toujours 30 jours, et une année n’en contient pas systématiquement 365. Les années bissextiles ajoutent un jour à février, portant l’année à 366 jours. Sur un horizon de 4 ans, cela peut avoir un effet concret sur les scripts de rétention, les échéances légales et les calculs de période.
| Unité | Valeur réelle ou usuelle | Commentaire pratique |
|---|---|---|
| Semaine | 7 jours | Constante simple pour les fenêtres glissantes |
| Mois civil | 28 à 31 jours | Éviter d’assimiler systématiquement 1 mois à 30 jours |
| Année non bissextile | 365 jours | Cas le plus fréquent |
| Année bissextile | 366 jours | Impact sur février et sur les calculs longs |
| 30 jours | 4,2857 semaines | Approximation utile pour reporting et tableaux de bord |
Bonnes pratiques pour écrire un script Bash fiable
Un script robuste ne se contente pas de calculer une date. Il valide aussi l’entrée, contrôle le format de sortie, documente l’intention et précise si le calcul doit être local ou UTC. Il est recommandé de conserver une convention homogène dans tout le projet. Si vos logs sont au format ISO en UTC, vos calculs de dates devraient suivre la même logique. Si votre métier raisonne en jours civils locaux, alors vos variables doivent le montrer explicitement.
- Valider la date d’entrée avant de lancer le calcul.
- Préciser le format de sortie attendu dans une variable ou un commentaire.
- Utiliser l’UTC pour les automatisations distribuées ou inter-serveurs.
- Tester les dates proches des fins de mois et du 29 février.
- Éviter les hypothèses simplistes du type “1 mois = 30 jours” si le besoin est calendaire.
- Prévoir une alternative pour macOS si l’environnement n’est pas exclusivement GNU/Linux.
Différence entre jours calendaires et logique métier
Dans certains projets, “x jours” signifie des jours calendaires. Dans d’autres, il s’agit de jours ouvrés. Bash avec date gère parfaitement les jours calendaires, mais pas les jours ouvrés au sens métier sans logique supplémentaire. Si vous devez exclure les week-ends ou les jours fériés, il faudra construire une boucle, utiliser un calendrier externe ou intégrer une source de données métier. Ce point est fondamental, car beaucoup d’erreurs viennent d’une ambiguïté entre le besoin exprimé et le calcul réellement implémenté.
Cas d’usage concrets en administration système
Voici quelques scénarios dans lesquels le calcul de dates x jours en Bash est réellement utile:
- Rétention de sauvegardes: supprimer les archives plus anciennes que 90 jours.
- Rotation de logs: sélectionner les fichiers datant de plus de 14 jours.
- Alerting: déclencher une alerte si un certificat expire dans moins de 30 jours.
- Conformité: calculer une échéance d’audit à partir d’une date de référence.
- Planification: générer des dates cibles pour des tâches batch ou des campagnes techniques.
Dans tous ces cas, un simple décalage d’un jour peut provoquer une suppression prématurée, un oubli d’alerte ou un non-respect de procédure. D’où l’intérêt d’un calculateur visuel comme celui de cette page: il sert de garde-fou avant l’intégration d’une formule dans un script automatisé.
Compatibilité et portabilité
Si votre environnement cible est strictement Linux, GNU date est généralement le choix naturel. En revanche, si vous devez livrer un script portable entre Linux et macOS, il faut prévoir une stratégie de compatibilité. Dans certains cas, installer les outils GNU sur macOS résout le problème. Dans d’autres, il est préférable de déléguer le calcul à Python, Perl ou à un outil plus portable. Le vrai enjeu n’est pas de “faire en Bash à tout prix”, mais d’obtenir un comportement cohérent sur tous les hôtes.
Pour approfondir les notions de temps, de synchronisation et de références calendaires, il est utile de consulter des sources institutionnelles et académiques. Le NIST publie des références sur le temps et la synchronisation. Le U.S. Naval Observatory fournit des ressources historiques et techniques sur les repères temporels. Enfin, les établissements universitaires comme Princeton University offrent des ressources utiles sur les systèmes, les formats et les pratiques logicielles.
Conclusion
Le calcul de dates x jours en Bash est une opération simple en apparence, mais stratégique en pratique. Bien maîtrisé, il rend vos scripts plus fiables, plus lisibles et plus prévisibles. La bonne démarche consiste à partir d’une date clairement définie, à choisir entre fuseau local et UTC, à utiliser un format de sortie normalisé, et à tester les cas limites comme les fins de mois ou les années bissextiles. Avec ces réflexes, Bash devient un excellent outil pour les calculs calendaires courants, notamment dans les workflows d’automatisation et d’administration système.