Convertir fuseau horaire cron : l'heure, pas l'expression

Que fait cet outil ?

Il inverse le sens de saisie habituel des outils cron. Le schéma classique est le suivant : tu tapes 0 9 * * 1-5, l’outil te dit « chaque jour ouvré à 09:00 » et liste les prochaines exécutions. C’est utile quand l’expression est déjà sous tes yeux, parce qu’elle traîne dans le fichier de configuration de quelqu’un d’autre. Quand tu écris une nouvelle tâche, tu ne l’as pas. Tu as une heure en tête.

Ici, l’heure est donc la saisie. Tu entres 09:00, tu choisis Berlin, tu cliques sur « jours ouvrés », et tu obtiens quatre blocs terminés : la ligne pour crontab -e, le bloc schedule d’un fichier GitHub Actions, un manifeste CronJob Kubernetes complet et la commande pour AWS EventBridge Scheduler. Chaque bloc porte la clé avec laquelle sa cible stocke le fuseau horaire et, en dessous, le même instant sous forme de ligne UTC figée, pour les environnements qui ne connaissent pas cette clé.

Tout se calcule dans le navigateur. Rien de ce que tu saisis n’est envoyé, et il n’y a pas de compte.

Pourquoi le fuseau horaire pose-t-il autant de problèmes avec cron ?

Parce que cron n’en a aucun. Les cinq champs d’une expression contiennent la minute, l’heure, le jour du mois, le mois et le jour de la semaine, et nulle part un fuseau. L’horloge concernée est décidée par ce qui évalue la ligne. Sur un serveur, c’est son heure système, dans un conteneur c’est le plus souvent UTC, sur une plateforme managée c’est ce que le fournisseur a décidé.

Il en sort une erreur que personne ne remarque en l’écrivant. La ligne est syntaxiquement correcte, elle est acceptée, la tâche tourne, aucun message d’erreur n’apparaît. Elle tourne simplement à la mauvaise heure. Et comme elle tourne à la mauvaise heure de façon fiable, cela ne remonte souvent que le jour où quelqu’un demande pourquoi le rapport est déjà dans sa boîte à sept heures.

La seconde moitié du problème, c’est l’heure d’été. Même une conversion correcte n’est valable que jusqu’au prochain changement. 09:00 heure de Berlin, c’est 07:00 UTC en été et 08:00 UTC en hiver. Écris une ligne UTC en août et elle est fausse d’une heure à partir du 25 octobre 2026, sans que rien ne casse pour te prévenir. Dans l’UE, la suppression du changement d’heure est bloquée depuis des années parce que les États membres n’arrivent pas à s’accorder sur l’heure permanente à retenir. Le sujet n’est donc pas près de disparaître.

Quelles clés de fuseau horaire existent ?

Les quatre cibles savent désormais porter le fuseau elles-mêmes. Simplement, chacune l’appelle autrement, et c’est précisément pour cela que des gens convertissent encore à la main alors qu’ils n’en ont plus besoin.

Cible	Clé	Disponible depuis
crontab (cronie, Vixie)	CRON_TZ=Europe/Berlin	Vixie cron 4.0
GitHub Actions	timezone: "Europe/Berlin"	Mars 2026
Kubernetes CronJob	spec.timeZone	Kubernetes 1.27
AWS EventBridge Scheduler	--schedule-expression-timezone	Novembre 2022
Timers systemd	OnCalendar=... Europe/Berlin	systemd 242

Le tableau a un retardataire et un trou. Le retardataire, c’est GitHub Actions : jusqu’en mars 2026, le bloc schedule ne comprenait qu’UTC, puis la clé timezone est arrivée. La documentation GitHub la montre aujourd’hui comme un exemple ordinaire. Le changement étant récent, beaucoup de tutoriels, de vieilles réponses de forum et plusieurs outils concurrents continuent d’affirmer qu’Actions ne fait que de l’UTC. Ce n’est plus vrai.

Le trou, ce sont les règles EventBridge classiques. Contrairement à Scheduler, elles n’ont pas de paramètre de fuseau, et AWS les liste dans sa propre documentation comme une fonctionnalité héritée avec un renvoi vers Scheduler. Si tu continues à les utiliser, tu n’échappes pas à la ligne UTC figée, et c’est à elle que s’applique le panneau du changement d’heure.

Pourquoi le jour de la semaine se décale-t-il ?

C’est l’erreur qui reste le plus longtemps invisible, parce qu’elle n’arrive qu’avec certains fuseaux et qu’elle se répète alors chaque semaine.

Prends 06:00 un lundi à Tokyo. Tokyo a neuf heures d’avance sur UTC, cela fait donc 21:00 UTC. Mais le dimanche, pas le lundi. Si tu convertis l’heure et laisses le 1 de lundi dans le champ du jour de la semaine, tu obtiens 0 21 * * 1, qui lance la tâche chaque lundi soir, soit 24 heures après l’instant voulu. La bonne ligne est 0 21 * * 0.

Le même piège dans l’autre sens : 20:00 un vendredi à New York, c’est 00:00 UTC le samedi. Les fuseaux à demi-heure aggravent la chose, parce que le champ des minutes ne peut pas non plus rester en place. 09:00 à Calcutta, c’est 03:30 UTC et pas 03:00, l’Inde ayant cinq heures et demie d’avance. Le Népal est en UTC+5:45 et les îles Chatham en UTC+12:45.

L’outil décale le jour de la semaine et le champ des minutes. Pour un rythme mensuel, il décale aussi le jour du mois tant que c’est possible, et te le dit quand ça ne l’est pas. Le premier d’un mois ne peut pas reculer d’une journée : « le dernier jour du mois précédent » n’est pas un nombre fixe qui tienne dans le champ du jour.

Quand ma ligne UTC figée se décale-t-elle exactement ?

Précisément quand le fuseau choisi change son horloge. L’outil cherche cette date dans la base de données des fuseaux horaires que ton navigateur embarque déjà, et il la nomme, avec le sens, l’ampleur et l’heure à laquelle la ligne se déclenchera réellement ensuite.

Les prochaines échéances sont plus rapprochées qu’on ne croit, et tous les fuseaux ne bougent pas en même temps. Sydney avance le 4 octobre 2026, parce que dans l’hémisphère sud l’heure d’été ne commence qu’à ce moment-là. Berlin recule le 25 octobre 2026. New York suit une semaine plus tard, le 1er novembre 2026, les États-Unis suivant leur propre règle. Si tu planifies des tâches dans plusieurs régions, tu as donc trois échéances différentes en cinq semaines.

Certains fuseaux ne bougent jamais. Calcutta reste toute l’année en UTC+5:30, Tokyo en UTC+9, et São Paulo a supprimé l’heure d’été il y a des années. Pour ceux-là, l’outil le dit explicitement au lieu d’afficher un avertissement qui ne s’applique pas. Une ligne UTC figée y reste correcte définitivement.

Que faire contre ce décalage ?

Quatre pistes, dans l’ordre où elles paient.

La première, c’est la clé du tableau ci-dessus. Si ta cible la prend en charge, le problème n’existe pas, puisque le système gère l’heure d’été lui-même. C’est pour cela que les quatre blocs de l’outil embarquent le fuseau au lieu de montrer la ligne convertie.

La deuxième, c’est changer de cible. Une règle EventBridge classique se remplace par une entrée Scheduler, un conteneur busybox par une image de base avec cronie. Dans les deux cas, c’est du travail une fois plutôt que deux fois par an.

La troisième, c’est le travail manuel avec rappel. Si la ligne doit rester figée, note la date du panneau dans ton agenda et ajuste l’heure ce jour-là. Cela fonctionne tant que quelqu’un se sent responsable.

La quatrième, c’est assumer le décalage sciemment. Une tâche de nettoyage nocturne qui tourne à deux heures au lieu de trois en hiver ne dérange personne. C’est une décision tout à fait valable, elle doit juste être une décision et pas une surprise en novembre.

Et la ponctualité elle-même ?

Un point qui n’a rien à voir avec les fuseaux horaires mais qui déclenche les mêmes plaintes : les exécutions planifiées de GitHub Actions démarrent régulièrement en retard. GitHub ne garantit pas la minute et, aux heures pleines, quand beaucoup de planifications arrivent à échéance en même temps, la file d’attente s’allonge.

Bon à savoir avant d’accuser la conversion. Si ta tâche tourne avec quatre heures de retard, ce n’est pas le fuseau, car un fuseau décale d’une heure entière ou d’une demi-heure, jamais de quatre. Si en revanche ta tâche est systématiquement décalée d’exactement une heure, c’est presque toujours le fuseau ou l’heure d’été. L’ampleur de l’écart t’indique déjà où chercher.

Mon expression a-t-elle vraiment besoin d’un fuseau horaire ?

Pas toujours. Si ta tâche doit tourner à une heure fixe que quelqu’un voit, donc un rapport en début de journée, une clôture en fin d’activité, un rappel le matin, alors oui. Ces heures-là sont liées à une horloge locale, et une heure d’écart se remarque.

Si ta tâche doit seulement tourner régulièrement, donc nettoyer toutes les 15 minutes, rafraîchir un cache chaque heure, sauvegarder quelque chose dans la nuit, alors non. Pour ces cas, UTC est le choix le plus simple, parce qu’il ne change jamais et que tu t’épargnes toute la question. Le générateur d’expressions cron convient mieux là : tu tapes l’expression directement et il te l’explique.

La règle empirique : si l’heure est liée à une personne, il te faut un fuseau. Si elle n’est liée qu’à un intervalle, non.