Übersprungene Stunden, doppelte Stunden und wie Social-Media-Planer mit Zeitzonen umgehen

Wie gehen Social-Media-Planer mit Zeitzonen um?

Technisch betrachtet läuft die Frage, wie Social-Media-Planer mit Zeitzonen umgehen, auf eine Regel hinaus: Bewahre die Uhrzeit, die die Person gewählt hat, zusammen mit dem IANA-Zonennamen auf, in dem sie sie gewählt hat, und mache aus diesem Paar erst dann einen UTC-Zeitpunkt, wenn eine Plattform-API einen Zeitstempel braucht. „9:00 in America/New_York am 15. Juli“ ist die Absicht. 2026-07-15T13:00:00Z ist das, was die API bekommt.

Der Zonenname zählt, weil er die Regeln trägt. Die IANA Time Zone Database, die laut IANA „the history of local time for many representative locations worldwide“ enthält, wird „updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules.“ Das Release, das auf iana.org stand, als diese Seite geschrieben wurde, war 2026d. Ein Name wie Europe/Berlin verweist auf diese Regeln. Ein Offset wie +01:00 verweist auf nichts und veraltet zweimal im Jahr.

Jede weitere Designentscheidung folgt aus dieser Trennung zwischen Absicht und Zeitpunkt. Der Rest dieser Seite zeigt, wo jede Hälfte bricht.

Warum ist ein fester UTC-Offset das Falsche zum Speichern?

Ein fester Offset hält fest, was die Uhr an einem Tag anzeigte, und nimmt an, dass das für immer gilt. Speichere 9:00 New Yorker Zeit im Januar als 09:00-05:00, verwende diesen Offset für einen Beitrag im Juli wieder, und der Beitrag landet bei 2026-07-15T10:00:00-04:00. Das ist 10:00 Ortszeit, eine Stunde zu spät, weil New York im Sommer auf UTC-4 läuft.

RFC 9557, das IETF-Dokument, das RFC-3339-Zeitstempeln Zonennamen in eckigen Klammern hinzufügt, warnt genau davor. Es nennt Offset-Zeitzonen „strongly discouraged“ und sagt, Programme „MUST NOT copy the UTC offset from a timestamp into an offset time zone.“ Sein eigenes Beispiel zeigt, warum: 2020-01-01T00:00+01:00[Europe/Paris] lässt ein Programm sechs Monate addieren und bei der korrekten Sommerzeit landen, während dieselbe Rechnung mit 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.“

Derselbe Fehler versteckt sich in wiederkehrenden Beiträgen. Ein wöchentlicher Slot, gespeichert als „jeden Montag 08:00 UTC“, verschiebt sich für alle außerhalb von UTC um eine Stunde, wenn ihre Uhren umgestellt werden. Ein Slot, gespeichert als „jeden Montag 08:00 Europe/London“, tut das nicht.

Was passiert mit einem Beitrag, der in der übersprungenen Stunde geplant ist?

Er verweist auf eine Zeit, die es nie gibt, und der Planer muss eine echte wählen. 2026 stellt New York seine Uhren am 8. März um 07:00Z von 02:00 auf 03:00 vor. Zwischen 02:00 und 02:59 passiert an diesem Datum nichts. Ein Beitrag für 02:30 hat keinen passenden Zeitpunkt.

Die JavaScript-API Temporal macht die Wahl über ihre Option disambiguation explizit, die "compatible", "earlier", "later" oder "reject" annimmt. MDN dokumentiert den Standard so: „compatible (default): Same behavior as Date: use later for gaps and earlier for ambiguities.“ Unter „compatible“ wird 02:30 zu 03:30 EDT, also 07:30Z. Pythons zoneinfo liefert für fold=0 denselben Zeitpunkt und für fold=1 06:30Z, eine Stunde früher.

"reject" ist die ehrliche Wahl für eine Planungsoberfläche. Lehne den Slot ab und sag der Person, dass es 02:30 in dieser Nacht nicht gibt, statt ihren Beitrag stillschweigend zu verschieben. Für einen Hintergrundjob, der auf jeden Fall auslösen muss, ist „compatible“ die am wenigsten überraschende Regel, und sie entspricht dem, was Date ohnehin tut.

Was passiert in der doppelten Stunde?

Dieselbe Uhrzeit kommt zweimal vor, und der Planer muss eine wählen. Am 1. November 2026 stellt New York um 06:00Z von 02:00 EDT auf 01:00 EST zurück, also tritt 01:30 einmal um 05:30Z und noch einmal um 06:30Z auf. Die UNIX-Zeitstempel sind 1793511000 und 1793514600, genau 3.600 Sekunden auseinander.

MDNs Regel für „compatible“ lautet „earlier for ambiguities“, also postet ein Temporal-basierter Planer beim ersten 01:30. Pythons zoneinfo macht dasselbe für fold=0. So oder so muss die Regel im Code stehen, denn nichts in „01:30 America/New_York“ sagt, welchen der beiden Zeitpunkte die Person meinte. Ein Kalender, der in dieser einen Nacht beide Optionen zeigt, vermeidet das Raten.

Warum sind die Unterschiede zwischen den USA und Europa für globales Posten wichtig?

Die beiden Regionen stellen ihre Uhren an unterschiedlichen Tagen um, also ist der Abstand zwischen ihnen nicht konstant. 2026 stellen London und Berlin am 29. März um 01:00Z vor, drei Wochen nach New York. Vom 8. März bis zum 29. März liegt New York vier statt fünf Stunden hinter London. Im Herbst stellt Europa am 25. Oktober zurück und New York am 1. November, was eine weitere Woche mit vier Stunden öffnet.

Diese Daten stammen aus der tz-Datenbank, nicht aus einer Faustregel. Ein Planer, der „London ist New York plus fünf“ fest einprogrammiert, postet vier Wochen im Jahr eine Stunde daneben. Einer, der jeden Beitrag über seinen eigenen Zonennamen umrechnet, trifft alle vier Wochen ohne Sonderfälle. Das zählt am meisten, wenn eine Kampagne in mehreren Regionen zu deren lokaler bester Zeit zum Posten in sozialen Medien rausgeht.

Welche Zeitformate akzeptieren Plattform-APIs?

Jede Plattform-API, die einen zukünftigen Zeitpunkt annimmt, will einen absoluten Zeitpunkt: einen UNIX-Integer oder einen ISO-8601- oder RFC-3339-String mit Offset oder Z. Keine nimmt einen IANA-Zonennamen an. Die Tabelle deckt die Planungsfelder ab, die die eigene Dokumentation jeder Plattform beschreibt.

Zwei Details aus dieser Tabelle erwischen Leute. Metas Pages-API-Leitfaden schreibt den Standard „ISO 8061“, ein Tippfehler für ISO 8601 auf genau der Seite, die das Feld definiert. Und Facebook Reels akzeptieren nur die Integer-Form, also braucht ein Planer, der ISO-Strings an /feed sendet, für Reels einen eigenen Codepfad.

Bluesky ist ein Sonderfall. Es hat kein Planungsfeld, aber jeder Post-Record trägt ein Pflichtfeld createdAt, das das Lexicon als „Client-declared timestamp“ beschreibt. Die atproto-Spezifikation sagt „Timezone specification is required“ und „It is strongly preferred to use the UTC timezone, and to represent the timezone with a simple capital Z suffix.“ Ein Bluesky-Beitrag in der Warteschlange sollte sein createdAt beim Senden bekommen, nicht in dem Moment, in dem er entworfen wurde.

Nimmt irgendeine Plattform-API einen Zeitzonennamen an?

Nein. Keine der hier behandelten Planungsdokumentationen akzeptiert einen String wie America/New_York. Die Umrechnung vom Zonennamen in einen Zeitpunkt ist immer die Aufgabe des Planers, und die Plattform sieht die Zone nie.

Facebook kommt der Umrechnung auf eigener Seite am nächsten, und genau das ist der riskante Teil. Metas Leitfaden akzeptiert relative strtotime()-Strings wie +2 weeks und tomorrow, sagt aber nicht, in welcher Zone „tomorrow“ aufgelöst wird. Metas eigener Rat lautet: „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.“ Ein Planer, der einen berechneten UNIX-Zeitstempel sendet, braucht diese Prüfung nie.

RFC 9557 definiert tatsächlich einen Platz für einen Zonennamen, als Suffix in eckigen Klammern: 2022-07-08T00:14:07+01:00[Europe/Paris]. Keiner der oben genannten Planungsendpunkte dokumentiert Unterstützung für dieses Suffix, also entferne es vor dem Senden. Die plattformspezifischen Details zu zwei dieser Felder stehen in den Regeln zur Vorlaufzeit von scheduled_at bei Mastodon und jedem publishAt-Feld von YouTube und seinen Fehlerbildern.

Was sollte ein Planer für jeden Beitrag speichern?

Drei Dinge: die lokale Uhrzeit, den IANA-Zonennamen und den daraus abgeleiteten UTC-Zeitpunkt. Die ersten beiden sind die Quelle der Wahrheit. Der dritte ist ein Cache, nach dem die Warteschlange sortiert und auslöst.

Der Grund, die lokale Zeit zu behalten, ist, dass sich Zonenregeln nach dem Planen ändern. MDN sagt es deutlich: „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.“ Wenn ein Update der tz-Datenbank erscheint, berechne den UTC-Zeitpunkt jedes zukünftigen Beitrags aus Uhrzeit und Zone neu. Ein System, das nur UTC gespeichert hat, kann das nicht, weil es nicht mehr weiß, worum die Person gebeten hat.

Die andere Hälfte ist der Sendepfad. Wandle beim Versand in das Format um, das jede API will: einen Integer für Facebook Reels, ISO mit Z-Suffix für YouTube und Mastodon, volle Minuten für X Ads. Prüfe das Ergebnis vor dem Senden gegen die minimale Vorlaufzeit der Plattform. Mastodon lehnt alles innerhalb von 5 Minuten ab, Facebook alles innerhalb von 10. Diese Prüfungen richtig zu machen, ist der größte Teil dessen, was eine zuverlässige Warteschlange von einer unterscheidet, die Social-Media-Beiträge plant und sie zweimal im Jahr zur falschen Stunde veröffentlicht.

Häufig gestellte Fragen

Sollte ein Social-Media-Planer Zeiten in UTC speichern?

Speichere den UTC-Zeitpunkt zum Sortieren und Auslösen, aber nicht als einzigen Eintrag. Behalte auch die Uhrzeit und den IANA-Zonennamen, damit sich der Zeitpunkt neu berechnen lässt, wenn die tz-Datenbank die Regeln einer Zone ändert. MDN weist darauf hin, dass sich die Definition einer Zone „may have changed due to political reasons“, bevor ein zukünftiger Zeitpunkt eintritt.

Was ist ein IANA-Zeitzonenname?

Ein Bezeichner aus der IANA Time Zone Database, etwa America/New_York, Europe/London oder Asia/Tokyo. Jeder Name verweist auf die vollständige Geschichte der UTC-Offsets und Sommerzeitregeln für diesen Ort. IANA beschreibt die Datenbank als „updated periodically to reflect changes made by political bodies“.

Was passiert, wenn ich einen Beitrag für 2:30 Uhr in der Nacht der Umstellung auf Sommerzeit plane?

In New York gibt es am 8. März 2026 kein 02:30. Unter Temporals Standardregel "compatible" rückt der Beitrag auf 03:30 EDT vor, 07:30Z. Mit "reject" wirft der Planer stattdessen einen RangeError, sodass die Oberfläche die Person bitten kann, eine andere Zeit zu wählen.

Akzeptiert Facebooks scheduled_publish_time eine Zeitzone?

Nur als Offset in einem ISO-8601-String wie 2018-09-01T10:15:30+01:00, Metas eigenem Beispiel. Es akzeptiert außerdem einen UNIX-Zeitstempel in Sekunden und strtotime()-Strings. Metas Leitfaden sagt nicht, in welcher Zone relative Strings wie tomorrow aufgelöst werden, und empfiehlt, den Wert zur Kontrolle zurückzulesen.

Welches Format will die YouTube API für publishAt?

Googles videos-Ressource sagt, status.publishAt „is specified in ISO 8601 format.“ Sende ein vollständiges Datum mit Uhrzeit und einem Z oder einem expliziten Offset. Google dokumentiert, dass ein Wert in der Vergangenheit das Video „right away“ veröffentlicht, also schaltet ein Umrechnungsfehler, der die Zeit in die Vergangenheit verschiebt, das Video sofort live, statt einen Fehler zurückzugeben.

Warum liegen meine geplanten Beiträge nach dem Ende der Sommerzeit eine Stunde daneben?

Die übliche Ursache ist ein gespeicherter fester Offset. Ein im Sommer als 09:00-04:00 gespeicherter Beitrag löst nach der Umstellung weiterhin um 13:00 UTC aus, was im Winter 08:00 in New York ist. America/New_York zusammen mit der Uhrzeit zu speichern und den Zeitpunkt neu zu berechnen, behebt das.

Was passiert mit einem Beitrag für 1:30 Uhr, wenn die Uhren zurückgestellt werden?

Am 1. November 2026 wiederholt New York die Zeit von 01:00 bis 01:59, sodass 01:30 einmal um 05:30Z und noch einmal um 06:30Z eintritt. Nach Temporals Standardregel "compatible" und nach Pythons zoneinfo mit fold=0 geht der Beitrag zum ersten Zeitpunkt raus. Die Regel muss im Code des Planers stehen, weil "01:30 America/New_York" nicht sagt, welchen der beiden Zeitpunkte die Person meinte.

Warum liegt New York in manchen Wochen nur vier Stunden hinter London?

Die USA und Europa stellen die Uhren an unterschiedlichen Terminen um. 2026 geht New York am 8. März auf Sommerzeit und London am 29. März, dazwischen liegt New York vier statt fünf Stunden hinter London. Im Herbst entsteht eine weitere Vier-Stunden-Woche, vom 25. Oktober, wenn Europa zurückstellt, bis zum 1. November, wenn New York folgt.

Kann ich einen Beitrag über die Instagram- oder LinkedIn-API planen?

In den hier behandelten Dokumentationen haben die Create-Endpunkte von Instagram, Threads, LinkedIn, TikTok, Pinterest und X API v2 kein Feld für eine künftige Zeit. Facebook, YouTube, Mastodon und X Ads haben eines. Für die erste Gruppe muss der Planer den Beitrag selbst vorhalten und zum passenden Zeitpunkt senden.

Welchen Zeitstempel sollte ein Bluesky-Beitrag tragen?

Bluesky hat kein Planungsfeld, aber jeder Beitragsdatensatz braucht ein createdAt, das das Lexikon als "Client-declared timestamp" beschreibt. Die atproto-Spezifikation verlangt eine Zeitzonenangabe und bevorzugt ausdrücklich UTC mit einem großen Z als Suffix. Ein eingereihter Beitrag sollte sein createdAt beim Senden bekommen, nicht beim Entwurf.