La bonne planification des tâches futures en fonction de l'heure locale, en tenant compte des fuseaux horaires et de l'heure d'été, est un sujet très complexe. J'ai déjà écrit à ce sujet dans une perspective de programmation sur Stack Overflow ici et ici .
Je vais résumer d'un point de vue non-programmation:
Définissez vos modèles de récurrence par heure locale - pas UTC . Par exemple, si vous configurez un réveil quotidien pour vous réveiller à 8h00 tous les jours, vous ne voulez pas vous réveiller une heure plus tôt ou une heure plus tard après une transition d'heure d'été. Si je suis dans le fuseau horaire du Pacifique américain, je ne peux pas planifier 16 h 00 UTC, car après la transition, il devra passer à 15 h 00 UTC pour conserver la même heure locale à 8 h 00.
Définissez le fuseau horaire représenté par l'heure "locale". Ne présumez pas que le fuseau horaire local du serveur est le même que celui qui compte pour l'utilisateur final.
Projetez l'heure locale à une date et une heure UTC pour chaque occurrence à laquelle vous souhaitez que l'événement se déclenche.
Vous le ferez presque toujours pour la prochaine occurrence immédiate, de sorte que vous pouvez utiliser l'horloge UTC pour déterminer l'instant réel à exécuter.
Dans certains cas, vous pouvez également projeter les plusieurs (ou plusieurs) instances suivantes, telles que les 5 prochaines occurrences, ou toutes les occurrences de l'année suivante. (Cette partie est très spécifique aux exigences de l'application.)
Avoir une stratégie (fixe ou configurable), de ce qu'il faut faire pour les événements qui tombent au moment d'une transition d' heure d'été :
Pour la transition "printemps vers l'avant", il y a un manque d'heure locale manquante lorsque l'occurrence pourrait ne pas exister. Par exemple, dans l'heure du Pacifique américain, une tâche quotidienne planifiée pour s'exécuter à 2 h 00, heure locale, n'existera pas le 9 mars 2014. Dans la plupart des cas, vous souhaiterez avancer cette heure de la quantité économisée (généralement 1 heure ), donc ce jour-là, il s'exécutera à 3 h 00, mais sera de nouveau exécuté à 2 h 00 dans l'instance suivante. (Cependant, il est tout à fait possible que vous souhaitiez une stratégie différente pour cela.)
Pour la transition "repli", il y a un chevauchement de l'heure locale en double lorsque l'occurrence peut exister deux fois . Par exemple, dans l'heure du Pacifique américain, une tâche quotidienne planifiée pour s'exécuter à 1 h 00 aura deux heures possibles d'exécution le 2 novembre 2014. Dans la plupart des cas, vous voudrez l'exécuter à la première occurrence de 1 : 00 AM PDT et ignorez la prochaine occurrence de 1:00 AM PST de la même date. (Mais encore une fois, vous souhaiterez peut - être une stratégie différente, telle que l'exécution sur la deuxième occurrence, ou l'exécution dans les deux. YMMV)
Soyez prêt à recalculer toutes vos heures UTC d'occurrence si vous avez besoin de mettre à jour vos données de fuseau horaire. L' IANA / Olson TZDB publie plusieurs mises à jour chaque année parce que les gouvernements du monde changent constamment d' avis sur les décalages de fuseau horaire et les règles d'heure d'été. Vous ne pouvez pas supposer pour une durée spécifique à l'avenir que les règles ne changeront pas .
Assurez-vous de vous abonner aux annonces de publication des données de fuseau horaire et d'avoir un processus pour les appliquer à vos systèmes et / ou applications.
Dans un cadre d'entreprise traditionnel, cette responsabilité devrait incomber au personnel des opérations informatiques.
Selon votre environnement, vous pouvez obtenir ces données via tzdatales mises à jour de packages linux, via Java JRE ou tzupdater , ou n'importe quel nombre d'autres canaux. Parfois, il est spécifique à l'environnement et parfois à la plate-forme de programmation, comme le package PECL timezonedb pour PHP , et bien d'autres.
Microsoft a ses propres données de fuseau horaire. Sous Windows, si vous utilisez à TimeZoneInfopartir de .NET (par exemple), vous utilisez ces données. Les mises à jour viennent d' ici et sont également diffusées automatiquement via Windows Update, vous devez donc garder un œil sur celles-ci afin de savoir quand / si vous devez recalculer.
Avec tout cela compris, il y a encore un scénario où vous planifieriez uniquement par UTC, et c'est pour les événements futurs ABSOLUS . Exemples:
Un travail qui s'exécute toutes les X heures ou toutes les X minutes.
Heures de début et de fin du lever du soleil, ou autre phénomène astronomique.
Une fenêtre de sécurité sensible au temps, comme lors de la transmission d'informations sensibles à une autre partie à un moment prédéterminé.
Planificateur de tâches Windows
Windows ne fait pas nécessairement la bonne chose. Faites attention à la façon dont vous définissez le déclencheur:
Lorsque vous cochez la case intitulée "Synchroniser entre les fuseaux horaires", la tâche est planifiée par UTC uniquement. (Toutes les heures sont toujours affichées comme heure locale, mais sont stockées en UTC.) C'est donc pour ce que j'ai appelé plus tôt un événement "absolu".
Lorsque vous laissez cette case décochée, elle va utiliser le fuseau horaire local de l'ordinateur sur lequel le code s'exécute. Il ne vous donne aucune option pour spécifier le fuseau horaire, donc ce n'est pas une très bonne implémentation à mon humble avis.
Je ne suis pas exactement sûr de son comportement DST, mais je vais expérimenter et vous revenir là-dessus. Il fait probablement ce que j'ai décrit ci-dessus, mais pas nécessairement.
Agent SQL
Le planificateur SQL Agent est encore pire, dans la mesure où il vous permet uniquement d'utiliser l'heure du serveur local. Encore une fois, aucun fuseau horaire ne peut être spécifié et vous ne pouvez pas non plus spécifier UTC.
Il a été demandé , mais pas accepté.