Dialectes d'expressions cron : champs, secondes et le piège jour du mois / jour de la semaine

Ce que c'est

« Expression cron » désigne au moins cinq grammaires incompatibles :

Dialecte	Ordre des champs	Secondes	Année	jour du mois + jour de la semaine
Vixie cron / cronie crontab(5)	minute heure dom mois dow (5 champs)	non	non	OU lorsque les deux sont restreints (aucun n'est *)
Quartz CronTrigger	secondes minutes heures dom mois dow [année] (6 ou 7 champs)	oui, premier champ	7ᵉ champ facultatif	exactement l'un des deux doit valoir ? ; * dans les deux est rejeté
Kubernetes CronJob	minute heure dom mois dow (5 champs) ; le fuseau horaire se définit dans .spec.timeZone, pas dans la chaîne	non	non	OU, comme Vixie cron
GitHub Actions schedule	minute heure dom mois dow (5 champs), syntaxe POSIX ; UTC, sauf si un timezone: IANA est défini sur l'entrée	non	non	non précisé dans la documentation de GitHub ; POSIX cron définit un OU
Règles AWS EventBridge cron()	minutes heures dom mois dow année (6 champs), évaluées en UTC	non	obligatoire, 6ᵉ champ	une valeur ou * dans l'un impose ? dans l'autre

La page de manuel crontab(5) indique que, lorsque les deux champs de jour sont restreints, « the command will be run when either field matches the current time » (la commande s'exécute dès que l'un des deux champs correspond à l'heure courante) : c'est un OU. Quartz et EventBridge interdisent au contraire de renseigner les deux et exigent un ? comme caractère de substitution dans l'un des deux.

Pourquoi c'est important

Retoucher légèrement une chaîne de planification écrite pour un système en modifie silencieusement le sens sur un autre, ou la fait rejeter. Une chaîne Quartz collée dans un manifeste Kubernetes échoue à la validation (trop de champs, secondes non prises en charge). Une chaîne cron EventBridge sans champ d'année est invalide. La documentation de CronJob de Kubernetes réserve explicitement la gestion du fuseau horaire au champ distinct .spec.timeZone (stable depuis la v1.27), indique qu'un préfixe CRON_TZ/TZ dans la chaîne de planification « is not officially supported (and never has been) » (n'est pas officiellement pris en charge, et ne l'a jamais été), et que les versions actuelles rejettent une telle planification avec une erreur de validation.

Comment l'appliquer

• Valider la chaîne finale avec l'analyseur propre au système cible avant de la déployer, et non avec un validateur cron générique.
• Pour Kubernetes, renseigner .spec.timeZone plutôt que d'intégrer un préfixe de fuseau horaire dans .spec.schedule.
• Les planifications GitHub Actions s'exécutent en UTC, sauf si l'entrée définit timezone: (un nom IANA tel que Europe/Zurich), ne se déclenchent jamais plus souvent que toutes les 5 minutes et peuvent être retardées ou abandonnées en cas de charge, surtout en début d'heure.
• Pour EventBridge, toujours fournir exactement 6 champs, année comprise, mettre ? dans celui du jour du mois ou du jour de la semaine qui n'est pas contraint, et exprimer les heures en UTC (les règles planifiées n'ont pas de paramètre de fuseau horaire).
• Pour Quartz, garder à l'esprit que la chaîne peut compter 6 ou 7 champs : omettre l'année est valide, omettre les secondes ne l'est pas.

Pièges

• Supposer que Kubernetes et EventBridge appliquent la même règle pour le jour du mois et le jour de la semaine : Kubernetes les combine par OU comme le cron classique, alors qu'EventBridge exige qu'exactement l'un des deux soit ?.
• Oublier qu'une chaîne Quartz à 7 champs avec année est invalide partout ailleurs.
• Ajouter timezone: à une planification GitHub Actions dont les heures ont déjà été converties à la main en UTC.