Analyseur et générateur d’expressions cron

Non. L’expression est analysée et les heures d’exécution sont calculées dans votre navigateur en JavaScript ; elle n’est pas envoyée à LeedyBox.

Dans le cron Unix, lorsque le jour du mois et le jour de la semaine sont tous deux restreints (aucun des deux ne commence par *), un jour convient si l’un ou l’autre des champs correspond : cette expression s’exécute donc le 13 de chaque mois et tous les vendredis. L’outil applique cette règle aux expressions Unix, et « Planification » indique alors « l’un des deux suffit ». Pour les expressions Spring, il exige que les deux champs correspondent, et Quartz et AWS évitent la question en imposant « ? » dans l’un des deux champs. Avec le cron Unix, une solution courante consiste à planifier la tâche tous les vendredis et à vérifier la date dans la tâche elle-même.

Cela dépend du format. Dans les expressions Unix et Spring, 0 et 7 désignent tous deux le dimanche et 1 le lundi ; dans Quartz et AWS, 1 désigne le dimanche et 7 le samedi, si bien que 1-5 y signifie du dimanche au jeudi. Les noms de jours comme MON-FRI évitent cette différence dans Spring, Quartz et AWS.

Saisissez uniquement les champs de planification. La commande en fin de ligne de crontab, ainsi que le nom d’utilisateur dans /etc/crontab, sont comptés comme des champs supplémentaires : l’outil signale alors un champ non valide ou un nombre de champs incorrect. Pour AWS, collez les six champs situés à l’intérieur de cron( ), sans cette enveloppe.

Spring ajoute un champ des secondes au début : 0 9 * * 1-5 devient ainsi 0 0 9 * * 1-5. Quartz exige en plus « ? » dans l’un des champs de jour et numérote le dimanche 1 : la même planification s’écrit donc 0 0 9 ? * MON-FRI. AWS n’a pas de champ des secondes, exige « ? » dans l’un des champs de jour, comme Quartz, et ajoute une année à la fin : 0 9 ? * MON-FRI *. Si l’expression Unix restreint les deux champs de jour, elle repose sur la règle « l’un ou l’autre » décrite plus haut, que ces formats n’utilisent pas : il faut alors en général deux planifications. Vérifiez le résultat avec le format cible sélectionné et comparez les prochaines exécutions.

L’expression est valide, mais aucune heure correspondante n’a été trouvée dans les 8 années environ que l’outil examine. Les causes typiques sont des dates qui n’existent pas, comme 0 0 30 2 * (30 février) ou le jour 31 combiné uniquement à des mois de 30 jours, et un champ année situé dans le passé. Une année située à plus de 8 ans donne le même message, bien que cette planification puisse s’exécuter plus tard. Certains planificateurs, dont le cron Unix classique, acceptent sans avertissement une date qui n’existe pas, et la tâche ne s’exécute pas.

Les heures d’exécution sont calculées pour le fuseau sélectionné sous « Fuseau horaire ». Choisissez celui qu’utilise votre planificateur : crontab suit généralement le fuseau horaire du serveur, les règles planifiées d’AWS EventBridge utilisent l’UTC, et EventBridge Scheduler permet de définir un fuseau horaire. Le menu propose le fuseau de votre navigateur, l’UTC et une sélection de fuseaux courants ; si celui de votre planificateur n’y figure pas, choisissez-en un qui a le même décalage par rapport à l’UTC et les mêmes dates de changement d’heure. Une exécution prévue à une heure sautée lorsque l’on avance l’heure est omise de la liste, et une heure qui se produit deux fois lorsque l’on recule l’heure n’y figure qu’une fois. Les démons cron gèrent ces heures de différentes manières ; cronie, par exemple, peut exécuter juste après le changement d’heure une tâche prévue pendant l’heure sautée. Vérifiez le comportement de votre planificateur, ou utilisez l’UTC, qui ne connaît pas d’heure d’été.