Quartz vs cron standard : les différences clés
Un guide de décision concis pour choisir le bon dialecte cron et éviter les incompatibilités d'analyseur.
Ouvrir l'explicateur QuartzPourquoi le dialecte cron est important
La plupart des erreurs cron commencent avant le déploiement, lorsque l'intention de planification et la syntaxe divergent. Si vous écrivez une expression cron pour un analyseur standard à 5 champs et la déployez sur un planificateur basé sur Quartz, le résultat n'est pas seulement une erreur de syntaxe. Les champs changent de position, les tokens sont mal interprétés, et la planification peut se déclencher à un moment complètement incorrect ou échouer silencieusement sans retour utile.
La confusion provient d'un fait simple : il n'existe pas de format « cron » unique. Le crontab Unix original utilise cinq champs (minute, heure, jour du mois, mois, jour de la semaine). Quartz Scheduler étend cela à six ou sept champs en ajoutant les secondes au début et une année optionnelle à la fin. Les deux sont appelés « expressions cron », mais ils sont structurellement incompatibles. Les confondre est la cause numéro un des échecs de planification liés au dialecte.
Cet article explique les différences clés avec des exemples pratiques, des vérifications de validation et des étapes concrètes dans Cronwise. Collez n'importe quelle expression dans l'explicateur Quartz pour voir sa signification instantanément.
Structure des champs : 5 champs vs 7 champs
La différence la plus fondamentale entre les deux dialectes est le nombre de champs et leurs positions. Le cron standard utilise exactement cinq champs :
| Position | Champ | Valeurs autorisées |
|---|---|---|
| 1 | Minute | 0-59 |
| 2 | Heure | 0-23 |
| 3 | Jour du mois | 1-31 |
| 4 | Mois | 1-12 |
| 5 | Jour de la semaine | 0-7 (0 et 7 = dimanche) |
Le cron Quartz ajoute un champ secondes au début et un champ année optionnel à la fin :
| Position | Champ | Valeurs autorisées |
|---|---|---|
| 1 | Secondes | 0-59 |
| 2 | Minutes | 0-59 |
| 3 | Heures | 0-23 |
| 4 | Jour du mois | 1-31 |
| 5 | Mois | 1-12 ou JAN-DEC |
| 6 | Jour de la semaine | 1-7 ou SUN-SAT |
| 7 | Année (optionnelle) | 1970-2099 |
Ce décalage positionnel est la source la plus courante d'erreurs entre dialectes. Une expression standard comme 0 9 * * MON (chaque lundi à 09 h 00) devient 0 0 9 ? * MON * en Quartz. Si vous collez la version standard dans un analyseur Quartz, 0 est lu comme secondes, 9 comme heures, et * comme jour du mois, ce qui produit une planification complètement différente.
Tokens exclusifs à Quartz : ?, L, W et #
Au-delà des champs supplémentaires, Quartz introduit quatre caractères spéciaux qui n'existent pas dans le cron standard. Ces tokens permettent des motifs de planification impossibles à exprimer dans un crontab à 5 champs.
Le token ? (pas de valeur spécifique) est requis dans le champ jour du mois ou jour de la semaine. Quartz ne permet pas aux deux champs d'utiliser simultanément des valeurs concrètes. Le cron standard n'a pas cette restriction, donc certaines expressions standard nécessitent une restructuration pour Quartz.
Le token L (dernier) cible le dernier jour d'un mois ou le dernier jour de la semaine spécifique. Par exemple, L dans le jour du mois signifie le dernier jour (28-31 selon le mois), et 5L dans le jour de la semaine signifie le dernier jeudi.
Le token W (jour ouvrable) sélectionne le jour ouvrable le plus proche d'un jour du mois donné. 15W signifie le jour ouvrable le plus proche du 15. Si le 15 est un samedi, la tâche se déclenche le vendredi 14. C'est précieux pour la planification en jours ouvrés.
Le token # (nième occurrence) cible une occurrence spécifique d'un jour de la semaine dans un mois. 6#3 signifie le troisième vendredi. Le cron standard ne fournit aucun moyen intégré d'exprimer ce motif.
Interpréter des planifications réelles : exemples côte à côte
Voir les deux dialectes en parallèle rend les différences concrètes. Voici des exigences de planification courantes exprimées dans les deux formats :
| Intention | Cron standard | Cron Quartz | Différence clé |
|---|---|---|---|
| Chaque jour à minuit | 0 0 * * * | 0 0 0 * * ? * | Préfixe secondes ; ? dans jour de la semaine |
| Jours ouvrables à 09 h 30 | 30 9 * * 1-5 | 0 30 9 ? * MON-FRI * | Préfixe secondes ; ? dans jour du mois ; jours nommés |
| Premier de chaque mois à 06 h 00 | 0 6 1 * * | 0 0 6 1 * ? * | Préfixe secondes ; ? remplace le joker dans jour de la semaine |
| Toutes les 15 minutes pendant les heures ouvrables | */15 9-17 * * 1-5 | 0 0/15 9-17 ? * MON-FRI * | Champ secondes ; différences de syntaxe de pas ; ? obligatoire |
| Dernier jour de chaque mois à midi | Non pris en charge nativement | 0 0 12 L * ? * | Token L exclusif à Quartz |
La dernière ligne met en évidence un écart de fonctionnalités. Le cron standard ne peut pas exprimer nativement « le dernier jour du mois ». Quartz le gère avec un simple token L. Cet avantage de motif explique pourquoi de nombreuses plateformes d'entreprise adoptent le dialecte Quartz malgré sa complexité accrue.
Cas limites et pièges courants
Les différences de dialecte créent des cas limites subtils qui passent les vérifications syntaxiques de base mais causent des problèmes à l'exécution :
Décalage de numérotation des jours de la semaine. Le cron standard utilise 0-7 où 0 et 7 représentent dimanche. Quartz utilise 1-7 où 1 est dimanche et 7 est samedi. L'expression * * * * 5 (vendredi en cron standard) devient 0 * * ? * 6 * en Quartz. Se tromper décale votre tâche d'un jour.
L'absence de ? cause un rejet. Quartz exige ? dans exactement un des deux champs de jour. Utiliser * dans les deux est invalide en Quartz, bien que parfaitement valide en cron standard.
Ambiguïté du champ année. Avec six tokens, certains analyseurs Quartz traitent le sixième comme jour de la semaine tandis que d'autres l'analysent comme année. Cronwise prend en charge les modes d'analyse explicites standard5, withSeconds6 et quartz7 pour éliminer cette ambiguïté.
Décalages de fuseau horaire lors de la migration de dialecte. Changer de dialecte cron signifie souvent changer de plateforme de planification, qui peut avoir un fuseau horaire par défaut différent. Une planification qui fonctionnait correctement dans un crontab configuré en UTC peut se déclencher au mauvais moment dans un planificateur Quartz utilisant le fuseau horaire de la JVM. Pour en savoir plus sur ce risque, lisez Les fuseaux horaires cron expliqués pour les équipes internationales.
Choisir le bon dialecte
Le choix du dialecte est déterminé par votre plateforme, pas par vos préférences personnelles. Choisir le mauvais format ne cause pas seulement des erreurs d'analyse ; il peut produire des planifications silencieusement incorrectes qui semblent valides mais se déclenchent aux mauvais moments.
Utilisez le cron standard à 5 champs quand :
- Votre planificateur est un démon cron Unix/Linux, un timer systemd ou un service cron cloud qui accepte la syntaxe à 5 champs.
- Vous n'avez pas besoin de précision inférieure à la minute ni de tokens avancés de ciblage de jours.
- Votre équipe travaille principalement dans un contexte shell ou DevOps où le cron standard est le dialecte courant.
Utilisez le cron Quartz quand :
- Votre planificateur est Quartz Scheduler, Spring Boot ou un autre framework basé sur la JVM.
- Vous avez besoin d'une granularité à la seconde ou de tokens comme
L,Wet#pour la logique de dernier jour, jour ouvrable le plus proche ou nième jour de la semaine.
Si vous n'êtes pas sûr du dialecte attendu par votre plateforme, vérifiez la documentation du planificateur pour le nombre de champs. Cinq champs signifie standard. Six ou sept champs (commençant par les secondes) signifie Quartz. Cronwise identifie automatiquement le dialecte lorsque vous collez une expression, mais connaître le format attendu prévient la confusion à la source.
Appliquer dans le flux de travail Cronwise
Cronwise fournit des outils dédiés pour les deux dialectes afin que vous n'ayez jamais à deviner ou convertir mentalement entre les formats. Voici le flux de travail de vérification recommandé avant de déployer toute planification cron :
Liste de vérification
| Vérification | Pourquoi c'est important | Critère de réussite |
|---|---|---|
| Confirmer le dialecte | Le mauvais analyseur produit de mauvais résultats | Le nombre de champs correspond à votre planificateur (5 vs 6/7) |
| Valider l'expression | Détecte les erreurs de syntaxe et les tokens mal placés | Aucune erreur ou avertissement dans la validation Cronwise |
| Lire l'explication en langage clair | Révèle les décalages d'intention avant le déploiement | L'explication correspond à votre objectif de planification |
| Examiner l'aperçu des prochaines exécutions | Les horodatages concrets exposent les cas limites | Les 10 prochaines exécutions tombent dans les fenêtres attendues |
| Vérifier le fuseau horaire | Le fuseau horaire du planificateur peut différer de votre heure locale | Le fuseau horaire de l'aperçu correspond au planificateur de production |
| Sauvegarder et documenter | Réutilisation et piste d'audit pour la collaboration en équipe | Expression sauvegardée avec une note descriptive |
Commencez avec l'explicateur Quartz pour décoder une expression existante, ou utilisez le générateur Quartz pour en construire une nouvelle visuellement. Pour le cron standard, l'explicateur d'accueil et le générateur suivent le même flux de travail avec la syntaxe à 5 champs.
Résumé et prochaines étapes
Les différences fondamentales entre Quartz et le cron standard se résument à trois domaines : le nombre de champs (5 vs 6/7), les tokens spéciaux (?, L, W, #) et la numérotation des jours de la semaine (0-7 vs 1-7). Toute autre distinction découle de ces divergences structurelles. Savoir quel dialecte votre planificateur attend et valider avec le bon analyseur élimine la classe la plus courante d'erreurs de planification.
Avant de déployer toute planification, parcourez la liste de vérification ci-dessus. Confirmez le dialecte, validez l'expression, lisez l'explication en langage clair, examinez les horodatages des prochaines exécutions dans votre fuseau horaire de production et sauvegardez le résultat avec une note descriptive pour votre équipe.
Pour une exploration approfondie, lisez notre guide sur les caractères spéciaux Quartz pour maîtriser la syntaxe L, W et #. Si le comportement des fuseaux horaires vous préoccupe, Les fuseaux horaires cron expliqués pour les équipes internationales couvre les décalages UTC, les cas limites de l'heure d'été et les stratégies de planification tenant compte des fuseaux horaires. Parcourez tous les articles cron pour continuer à apprendre.