Outils de développement · Générateur Crontab
Cron et heure d'été : pourquoi une tâche 02:30 peut être ignorée ou exécutée deux fois
· Pourquoi c'est important
cron Calendrier fuseaux horaires heure d'été
Deux fois par an, l'horloge murale saute et une tâche cron planifiée dans l'intervalle ou le chevauchement se comporte de manière inattendue. Cet article explique ce que font les crons dérivés de Vixie, ce que font les autres et comment planifier en fonction de cela.
Un candidat d'aperçu manquant peut se produire lorsque la zone sélectionnée n'a pas une telle heure d'horloge murale.
L'heure d'une horloge murale quotidienne peut être absente à une date lorsqu'un fuseau horaire sélectionné avance ses horloges. ToolAcre représente ce cas en ne renvoyant aucun instant pour la minute locale inexistante et en l'ignorant dans la liste d'exécution suivante. L'expression reste valable ; un candidat de calendrier ne peut tout simplement pas être converti en un instant réel dans cette zone.
Ce comportement est implémenté dans `wallClockToEpoch`, qui convertit une date et une heure locales proposées, formate le résultat dans la même zone et compare chaque composant. Une incompatibilité renvoie null. `nextRuns` ignore les candidats nuls et poursuit sa recherche, empêchant ainsi une heure proche fabriquée d'apparaître comme si elle correspondait exactement à l'horaire.
Les deux événements : le printemps en avant qui supprime une heure et le repli d'automne qui en répète une
Les changements d'horloge créent deux cas conceptuels : un écart vers l'avant avec des heures murales qui ne se produisent jamais, et un chevauchement vers l'arrière où certaines étiquettes apparaissent plus d'une fois. Le référentiel propose des tests pour maintenir une heure locale quotidienne lors d'un changement à venir et pour omettre une heure de printemps inexistante. Il ne contient pas de suite complète de tests de politique de chevauchement.
Cette limite de preuves est importante car les implémentations du planificateur peuvent faire des choix distincts. Cet article décrit l'algorithme de prévisualisation du navigateur, et non le comportement du démon universel. Avant de vous appuyer sur une tâche récurrente lors d'une transition d'horloge, lisez et testez le planificateur réel sur l'hôte cible plutôt que de transformer un aperçu en promesse d'exécution.
ToolAcre omet les heures locales inexistantes ; il ne modélise pas toutes les politiques de démons dérivées de Vixie
Le classeur affirmait que certains démons dérivés de Vixie exécutaient des tâches ignorées après un saut et supprimaient les doublons. ToolAcre ne fait ni l'un ni l'autre dans son code d'aperçu : il omet un candidat dont les composants locaux ne peuvent pas faire l'aller-retour. Aucun package démon n’est invoqué et aucune politique de rattrapage n’est modélisée. Ces affirmations opérationnelles sont donc corrigées plutôt que répétées.
L'exemple testé de Londres recherche 01:30 autour du changement 2026 de mars. Étant donné que cette minute locale n’existe pas à la date de transition, les jours renvoyés sont les dates valides suivantes. Cela prouve le comportement de liste de la route. Il n'établit pas ce qu'un processus cron installé séparément fait avec une ligne déjà enregistrée.
Le comportement de planification des caractères génériques dans les démons externes est une preuve extérieure au référentiel
Les étoiles sont développées dans chaque valeur autorisée par l'analyseur, mais la conversion ultérieure de l'horloge murale décide toujours si une date-heure particulière correspond à un instant. ToolAcre n'a pas de règle de démon externe distincte pour les « tâches génériques ». Tous les candidats voyagent via le même code de recherche de calendrier et de conversion de zone.
Les descriptions restent purement grammaticales : `* * * * *` se lit comme chaque minute, tandis qu'un champ de minutes échelonné reçoit un libellé d'étape. La phrase ne raconte pas la politique de transition. Utilisez la liste de prochaine exécution pour les exemples calculés par l'outil et ne déduisez pas de garantie de rattrapage, de nouvelle tentative ou de suppression des doublons à partir de la seule prose.
Les autres implémentations ne sont pas déduites de cet aperçu du navigateur
L'implémentation de la zone s'appuie sur les données `Intl.DateTimeFormat` exposées par le navigateur ou le runtime Node. ToolAcre valide un nom de zone IANA fourni, propose la liste prise en charge par le moteur lorsqu'elle est disponible et inclut UTC. Il n'inspecte pas BusyBox, les orchestrateurs de conteneurs ou les produits cloud cron.
Lorsqu'un autre planificateur n'est pas d'accord, traitez cela comme une question de dialecte et d'exécution. Enregistrez sa version, la configuration de la zone et le comportement de transition observé. L'aperçu du navigateur est toujours utile en tant que comparaison transparente, mais son code ne peut pas répondre à la stratégie appliquée par un autre service ni si ce service réessaye le travail manqué.
Exemple concret : choisissez une heure de mur et inspectez les candidats calculés par ToolAcre
Une méthode de travail plus sûre consiste à sélectionner la zone de déploiement, à saisir l'expression quotidienne proposée et à inspecter les dates autour de la prochaine transition connue de cet environnement. Si un candidat requis est absent, choisissez une autre heure murale ou une politique de planification que la cible documente explicitement. Réexécutez l'aperçu après avoir modifié l'heure.
La source inclut un préréglage à 02:30, mais un préréglage est un exemple et non une recommandation universelle. Sa validité dépend du calendrier et de la zone sélectionnés. La fenêtre de cinq résultats de ToolAcre peut ne pas couvrir une transition distante, alors choisissez un contexte de départ approprié dans les tests lors de l'audit du comportement d'implémentation.
La sélection de zone fait partie de cet aperçu et est abordée ici uniquement en tant que comportement de l'outil.
Contrairement à la séparation du classeur, la gestion des zones fait directement partie de l'aperçu de cet outil. Le panneau demande « Afficher les prochaines exécutions » et avertit que la machine exécutant cron peut utiliser une zone différente de celle du lecteur. Le choix d’une zone modifie les instants résultants tout en préservant les champs d’horloge murale de l’expression.
La sélection configure uniquement le calcul du navigateur. Il n'écrit pas de directive de fuseau horaire, ne met pas à jour un serveur et n'intègre pas le choix dans l'expression copiée. Conservez la zone prévue dans la documentation de déploiement adjacente, puis configurez le planificateur réel via des mécanismes éprouvés pour cet environnement.
À emporter : aperçu dans la zone prévue sans traiter la liste comme une garantie d'exécution
Une liste de prochaine exécution est une sortie de modèle à partir de cinq champs, un instant de départ, l'arithmétique du calendrier et les données de la zone du navigateur. Il est précieux pour détecter des heures inexistantes et des décalages horaires accidentels. Il ne s'agit ni d'une trace de démon ni d'une preuve de l'exécution d'une commande.
Utilisez l'aperçu pour identifier les heures de mur à risque, puis vérifiez le planificateur cible à la limite de transition. La promesse défendable de ToolAcre est étroite : les tâches quotidiennes restent à l’heure locale sélectionnée lorsque cette heure existe, et les candidats locaux inexistants sont omis. Tout ce qui va au-delà appartient au système déployé.