Heures sautées, heures répétées : comment les planificateurs de réseaux sociaux gèrent les fuseaux horaires

Comment les planificateurs de réseaux sociaux gèrent-ils les fuseaux horaires ?

En coulisses, la question de savoir comment les planificateurs de réseaux sociaux gèrent les fuseaux horaires se résume à une règle : garder l'heure d'horloge choisie par la personne avec le nom de zone IANA dans lequel elle l'a choisie, et ne transformer cette paire en instant UTC que lorsqu'une API de plateforme a besoin d'un timestamp. « 9:00 à America/New_York le 15 juillet » est l'intention. 2026-07-15T13:00:00Z est ce que reçoit l'API.

Le nom de zone compte parce qu'il porte les règles. La base de données des fuseaux horaires de l'IANA, que l'IANA décrit comme contenant « the history of local time for many representative locations worldwide », est « updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. » La version listée sur iana.org au moment de la rédaction de cette page était 2026d. Un nom comme Europe/Berlin pointe vers ces règles. Un décalage comme +01:00 ne pointe vers rien et devient obsolète deux fois par an.

Tous les autres choix de conception découlent de cette séparation entre intention et instant. La suite de cette page montre où chaque moitié casse.

Pourquoi un décalage UTC fixe est-il la mauvaise chose à enregistrer ?

Un décalage fixe enregistre ce qu'affichait l'horloge un jour donné et suppose que cela vaut pour toujours. Enregistrez 9:00 heure de New York en janvier sous la forme 09:00-05:00, réutilisez ce décalage pour une publication de juillet, et elle tombe à 2026-07-15T10:00:00-04:00. Il est alors 10:00 en heure locale, une heure trop tard, car New York est à UTC-4 en été.

La RFC 9557, le document de l'IETF qui ajoute des noms de zone entre crochets aux timestamps RFC 3339, met en garde contre exactement ce cas. Elle qualifie les fuseaux à décalage de « strongly discouraged » et dit que les programmes « MUST NOT copy the UTC offset from a timestamp into an offset time zone. » Son propre exemple montre pourquoi : 2020-01-01T00:00+01:00[Europe/Paris] permet à un programme d'ajouter six mois et de tomber sur la bonne heure d'été, alors que le même calcul sur 2020-01-01T00:00+01:00[+01:00] « will produce an incorrect result that will be off by one hour in the time zone Europe/Paris. »

Le même bug se cache dans les publications récurrentes. Un créneau hebdomadaire enregistré comme « chaque lundi 08:00 UTC » dérive d'une heure pour tous ceux qui ne sont pas en UTC quand leurs horloges changent. Un créneau enregistré comme « chaque lundi 08:00 Europe/London » ne dérive pas.

Que devient une publication programmée pendant l'heure sautée ?

Elle désigne une heure qui n'existe jamais, et le planificateur doit en choisir une réelle. En 2026, New York avance ses horloges de 02:00 à 03:00 le 8 mars, à 07:00Z. Rien ne se passe entre 02:00 et 02:59 ce jour-là. Une publication réservée pour 02:30 n'a aucun instant correspondant.

L'API JavaScript Temporal rend ce choix explicite avec son option disambiguation, qui accepte "compatible", "earlier", "later" ou "reject". MDN documente la valeur par défaut ainsi : « compatible (default): Same behavior as Date: use later for gaps and earlier for ambiguities. » Avec « compatible », 02:30 devient 03:30 EDT, soit 07:30Z. Le zoneinfo de Python donne le même instant pour fold=0, et 06:30Z, une heure plus tôt, pour fold=1.

"reject" est le choix honnête pour une interface de planification. Refusez le créneau et dites à la personne que 02:30 n'existe pas cette nuit-là, au lieu de déplacer sa publication en silence. Pour une tâche de fond qui doit se déclencher quoi qu'il arrive, « compatible » est la règle la moins surprenante, et elle correspond à ce que fait déjà Date.

Que se passe-t-il pendant l'heure répétée ?

La même heure d'horloge se produit deux fois, et le planificateur doit en choisir une. Le 1er novembre 2026, New York recule de 02:00 EDT à 01:00 EST à 06:00Z, donc 01:30 survient une fois à 05:30Z et une seconde fois à 06:30Z. Les timestamps UNIX sont 1793511000 et 1793514600, exactement 3 600 secondes d'écart.

La règle de MDN pour « compatible » est « earlier for ambiguities », donc un planificateur basé sur Temporal publie au premier 01:30. Le zoneinfo de Python fait de même pour fold=0. Dans les deux cas, la règle doit vivre dans le code, car rien dans « 01:30 America/New_York » n'indique lequel des deux instants la personne voulait. Un calendrier qui affiche les deux options cette nuit-là évite de deviner.

Pourquoi les écarts entre les États-Unis et l'Europe comptent-ils pour la publication mondiale ?

Les deux régions changent d'heure à des dates différentes, donc l'écart entre elles n'est pas constant. En 2026, Londres et Berlin passent à l'heure d'été le 29 mars à 01:00Z, trois semaines après New York. Du 8 au 29 mars, New York a quatre heures de retard sur Londres au lieu de cinq. À l'automne, l'Europe recule le 25 octobre et New York le 1er novembre, ce qui ouvre une autre semaine à quatre heures.

Ces dates viennent de la base tz, pas d'une règle empirique. Un planificateur qui code en dur « Londres, c'est New York plus cinq » publie avec une heure de décalage quatre semaines par an. Celui qui convertit chaque publication via son propre nom de zone traite correctement les quatre semaines sans cas particulier. C'est surtout important quand une même campagne part vers plusieurs régions à leur meilleur moment pour publier sur les réseaux sociaux en heure locale.

Quels formats d'heure les API des plateformes acceptent-elles ?

Chaque API de plateforme qui accepte une heure future veut un instant absolu : un entier UNIX, ou une chaîne ISO 8601 ou RFC 3339 avec un décalage ou un Z. Aucune n'accepte un nom de zone IANA. Le tableau couvre les champs de programmation que décrit la documentation de chaque plateforme.

Deux détails de ce tableau piègent les gens. Le guide de la Pages API de Meta écrit la norme « ISO 8061 », une faute de frappe pour ISO 8601 sur la page même qui définit le champ. Et les Reels Facebook n'acceptent que la forme entière, donc un planificateur qui envoie des chaînes ISO à /feed a besoin d'un chemin de code séparé pour les Reels.

Bluesky est un cas à part. Il n'a pas de champ de programmation, mais chaque enregistrement de publication porte un createdAt obligatoire, que le lexicon décrit comme un « Client-declared timestamp ». La spécification atproto dit « Timezone specification is required » et « It is strongly preferred to use the UTC timezone, and to represent the timezone with a simple capital Z suffix. » Une publication Bluesky en file d'attente doit recevoir son createdAt au moment de l'envoi, pas au moment où elle a été rédigée.

Une API de plateforme accepte-t-elle un nom de fuseau horaire ?

Non. Aucune des documentations de programmation couvertes ici n'accepte une chaîne comme America/New_York. La conversion du nom de zone en instant revient toujours au planificateur, et la plateforme ne voit jamais la zone.

Facebook est celui qui s'approche le plus de faire la conversion lui-même, et c'est là qu'est le risque. Le guide de Meta accepte des chaînes strtotime() relatives comme +2 weeks et tomorrow, mais ne dit pas dans quelle zone « tomorrow » est résolu. Le conseil de Meta est le suivant : « If you are relying on strtotime()'s relative date strings you can read-after-write the scheduled_publish_time of the created post to make sure it is what is expected. » Un planificateur qui envoie un timestamp UNIX calculé n'a jamais besoin de cette vérification.

La RFC 9557 prévoit bien une place pour un nom de zone, sous forme de suffixe entre crochets : 2022-07-08T00:14:07+01:00[Europe/Paris]. Aucun des endpoints de programmation ci-dessus ne documente la prise en charge de ce suffixe, donc retirez-le avant l'envoi. Le détail par plateforme pour deux de ces champs se trouve dans les règles de délai du scheduled_at de Mastodon et chaque champ publishAt de YouTube et ses modes d'échec.

Que doit enregistrer un planificateur pour chaque publication ?

Trois choses : l'heure d'horloge locale, le nom de zone IANA, et l'instant UTC qui en découle. Les deux premiers font foi. Le troisième est un cache qui sert à la file pour trier et déclencher.

La raison de garder l'heure locale, c'est que les règles des zones changent après la programmation. MDN le dit simplement : « if you store a time in the future, with an anticipated offset, then before that time comes, the time zone definition may have changed due to political reasons. » Quand une mise à jour de la base tz sort, recalculez l'instant UTC de chaque publication future à partir de son heure d'horloge et de sa zone. Un système qui n'a enregistré que l'UTC ne peut pas le faire, car il ne sait plus ce que la personne a demandé.

L'autre moitié, c'est le chemin d'envoi. Convertissez au format que veut chaque API au moment de l'envoi : un entier pour les Reels Facebook, de l'ISO avec suffixe Z pour YouTube et Mastodon, des minutes entières pour X Ads. Vérifiez le résultat par rapport au délai minimum de la plateforme avant l'envoi. Mastodon rejette tout ce qui tombe dans les 5 minutes, et Facebook tout ce qui tombe dans les 10. Réussir ces vérifications, c'est l'essentiel de ce qui sépare une file fiable d'une file qui programme les publications sur les réseaux sociaux à la mauvaise heure deux fois par an.

Questions fréquentes

Un planificateur de réseaux sociaux doit-il enregistrer les heures en UTC ?

Enregistrez l'instant UTC pour trier et déclencher, mais pas comme seul enregistrement. Gardez aussi l'heure d'horloge et le nom de zone IANA, pour pouvoir recalculer l'instant quand la base tz modifie les règles d'une zone. MDN note que la définition d'une zone « may have changed due to political reasons » avant qu'une heure future n'arrive.

Qu'est-ce qu'un nom de fuseau horaire IANA ?

C'est un identifiant issu de la base de données des fuseaux horaires de l'IANA, comme America/New_York, Europe/London ou Asia/Tokyo. Chaque nom pointe vers l'historique complet des décalages UTC et des règles d'heure d'été de ce lieu. L'IANA décrit la base comme « updated periodically to reflect changes made by political bodies ».

Que se passe-t-il si je programme une publication à 2:30 la nuit du passage à l'heure d'été ?

À New York, le 8 mars 2026, 02:30 n'existe pas. Avec la règle par défaut "compatible" de Temporal, la publication avance à 03:30 EDT, soit 07:30Z. Avec "reject", le planificateur lève à la place une RangeError, ce qui permet à l'interface de demander à la personne de choisir une autre heure.

Le scheduled_publish_time de Facebook accepte-t-il un fuseau horaire ?

Seulement sous forme de décalage dans une chaîne ISO 8601, comme 2018-09-01T10:15:30+01:00, qui est l'exemple de Meta. Il accepte aussi un timestamp UNIX en secondes et des chaînes strtotime(). Le guide de Meta ne dit pas dans quelle zone les chaînes relatives comme tomorrow sont résolues, et recommande de relire la valeur pour vérifier.

Quel format l'API YouTube attend-elle pour publishAt ?

La ressource videos de Google dit que status.publishAt « is specified in ISO 8601 format. » Envoyez une date et une heure complètes avec un Z ou un décalage explicite. Google documente qu'une valeur passée publie la vidéo « right away », donc un bug de conversion qui fait basculer l'heure dans le passé met la vidéo en ligne aussitôt, au lieu de renvoyer une erreur.

Pourquoi mes publications programmées sont-elles décalées d'une heure après la fin de l'heure d'été ?

La cause habituelle est un décalage fixe enregistré. Une publication enregistrée en 09:00-04:00 en été part toujours à 13:00 UTC après le changement d'heure, ce qui fait 08:00 à New York en hiver. Enregistrer America/New_York avec l'heure d'horloge et recalculer l'instant règle le problème.

Que devient une publication programmée à 1:30 quand les horloges reculent ?

Le 1er novembre 2026, New York répète l'intervalle de 01:00 à 01:59, donc 01:30 arrive à 05:30Z puis à 06:30Z. Avec la règle par défaut "compatible" de Temporal, et avec zoneinfo de Python et fold=0, la publication part à la première. La règle doit vivre dans le code du planificateur, car "01:30 America/New_York" ne dit pas laquelle des deux heures la personne visait.

Pourquoi New York n'a-t-elle que quatre heures de retard sur Londres certaines semaines ?

Les États-Unis et l'Europe changent d'heure à des dates différentes. En 2026, New York passe à l'heure d'été le 8 mars et Londres le 29 mars, et entre les deux New York a quatre heures de retard sur Londres au lieu de cinq. À l'automne, une autre semaine à quatre heures s'ouvre, du 25 octobre, quand l'Europe recule, au 1er novembre, quand New York suit.

Peut-on programmer une publication avec l'API d'Instagram ou de LinkedIn ?

Dans les documentations couvertes par cet article, les endpoints de création d'Instagram, Threads, LinkedIn, TikTok, Pinterest et X API v2 n'ont pas de champ pour une heure future. Facebook, YouTube, Mastodon et X Ads en ont un. Pour le premier groupe, le planificateur doit garder la publication et l'envoyer à l'heure voulue.

Quel horodatage une publication Bluesky doit-elle porter ?

Bluesky n'a pas de champ de programmation, mais chaque enregistrement de publication exige un createdAt, que le lexique décrit comme "Client-declared timestamp". La spécification atproto impose d'indiquer le fuseau et préfère nettement l'UTC avec un Z majuscule en suffixe. Une publication en file doit recevoir son createdAt à l'envoi, pas au moment du brouillon.