Le générateur de cron assemble des expressions crontab à cinq champs — minute, heure, jour du mois, mois, jour de la semaine — la syntaxe que lit tout démon cron sous Linux et Unix. Remplissez les cinq champs avec la notation que cron accepte réellement : un joker, une valeur unique, une plage comme 9-17, un pas comme */15 ou 0-30/5, ou une liste séparée par des virgules, plus les noms de mois et de jours que cron lui-même reconnaît (jan-déc, dim-sam, et même des plages comme lun-ven et jan-mar). Chaque champ est validé contre ses vraies bornes — minutes 0–59, heures 0–23, jours 1–31, mois 1–12, jours de la semaine 0–7 avec 7 signifiant dimanche exactement comme le dit la page de manuel — et l'entrée invalide est rejetée avec un message qui dit ce qui ne va pas, jamais « corrigée » en silence. À partir de la spécification analysée, l'outil dérive trois choses importantes : l'expression canonique à coller dans crontab, une description en langage clair du moment où le travail s'exécute, et le prochain moment réel d'exécution, calculé minute par minute selon les véritables règles de correspondance du démon. Cette dernière étape est celle où la plupart des générateurs mentent, et celui-ci est soigneux de trois façons. La prochaine exécution est calculée dans le fuseau horaire local de votre navigateur, et la page le dit, parce qu'un démon cron sur un serveur tourne dans le fuseau du serveur. La règle OU classique est respectée : lorsque le jour du mois ET le jour de la semaine sont restreints, cron se déclenche quand L'UN des deux correspond — surprenant, documenté, et affiché dans la description. Et les dates impossibles sont signalées honnêtement : un travail pour le 31 février ne trouve aucune prochaine exécution dans l'horizon de 366 jours et vous le dit au lieu de boucler indéfiniment. Tout est calculé localement — rien de ce que vous tapez n'est envoyé ni stocké. Utilisez-le pour planifier une sauvegarde, un build, un rapport ou un travail de base de données et obtenir la bonne expression avant qu'elle ne parte en production.
Questions fréquentes
Que signifie la règle OU pour jour-du-mois et jour-de-la-semaine ?
Lorsque les deux champs sont restreints — par exemple jour-du-mois 1 et jour-de-la-semaine 5 — cron s'exécute quand L'UN des deux correspond, donc le travail se déclenche le 1er du mois ET chaque vendredi. Cela surprend presque tout le monde, et c'est exactement le comportement de Vixie cron et de ses descendants. L'outil le respecte dans le calcul de la prochaine exécution et le déclare dans la description.
Quel fuseau horaire utilise le calcul de la prochaine exécution ?
Le fuseau horaire local de votre navigateur. Un démon cron tourne dans le fuseau du serveur, qui peut être UTC ou autre chose — la page indique le fuseau explicitement, et vous devez le comparer au serveur qui exécutera le travail avant de faire confiance à l'heure affichée.
Pourquoi 7 est-il accepté pour dimanche, et 0 aussi ?
crontab(5) définit jour-de-la-semaine comme 0–7, où 0 et 7 signifient tous deux dimanche ; 7 est une forme héritée que certains systèmes acceptent. L'outil accepte les deux et les normalise vers la même valeur pour la correspondance.
Où est le champ des secondes ?
Le format standard à cinq champs n'a pas de champ des secondes — la plus petite unité est la minute. Certains outils (comme Quartz et certaines bibliothèques Node) étendent cron avec les secondes, mais ces extensions ne sont pas portables entre démons, donc ce générateur s'en tient au format portable à cinq champs.
Que se passe-t-il avec des dates impossibles comme le 31 février ?
Cron ne les déclenche tout simplement jamais. L'outil calcule la prochaine exécution sur un horizon de 366 jours et, quand aucune n'existe — comme pour le 31 février — le signale honnêtement au lieu d'afficher une date qui ne viendra jamais.