Veröffentlicht oder nur geplant: Datumsangaben von Beiträgen sauber trennen

Ein Beitrag, der für Donnerstag geplant ist, hat am Mittwoch noch kein Veröffentlichungsdatum. Viele Systeme speichern trotzdem ein einziges Datumsfeld, und dann steht auf einer Seite ein Datum, das niemand belegen kann: etwa weil der Zeitplan gescheitert ist oder der Beitrag später kam. Dieser Beitrag beschreibt eine Metadaten-Vorlage, die geplante und tatsächliche Zeitpunkte trennt.

Das Artefakt: Felder

• status: Entwurf, geplant, veröffentlicht, zurückgezogen
• scheduled_for: gewünschter Zeitpunkt, nur wenn geplant, sonst leer oder Verlauf
• published_at: Zeitpunkt, zu dem der Beitrag tatsächlich öffentlich wurde, leer bis dahin
• updated_at: letzte inhaltliche Änderung nach der Veröffentlichung, leer, wenn es keine gab

Regeln: published_at wird nur durch das Ereignis „öffentlich ausgeliefert“ gesetzt, nie durch Eintragen eines Wunschzeitpunkts. scheduled_for ist eine Absicht, kein Beleg.

Wer liest welches Feld?

Sichtbares Datum auf der Seite, Feeds und strukturierte Angaben für Suchmaschinen sollten nur published_at verwenden. Interne Listen dürfen scheduled_for zusätzlich anzeigen, deutlich als „geplant für“ beschriftet. Ob eine Suchmaschine oder ein anderer Dienst solche Felder so verwertet, wie Sie es erwarten, ist offen und sollte beobachtet werden.

Entscheidungszweige

Geplant und Zeitpunkt noch nicht erreicht: öffentlich nicht sichtbar. published_at leer.

Geplant und Zeitpunkt erreicht, Auslieferung erfolgreich: Status wechselt auf veröffentlicht, published_at wird gesetzt.

Geplant und Zeitpunkt erreicht, Auslieferung unklar: Status bleibt geplant, der Vorgang wird zur Prüfung markiert. Externe Folgeschritte, etwa eine Benachrichtigung an Abonnenten, werden nicht automatisch wiederholt, solange nicht geklärt ist, ob der erste Versuch ankam. Eine Person entscheidet.

Zeitpunkt verschoben: scheduled_for ändern, den bisherigen Wert im Verlauf behalten.

Hypothetisches Beispiel: Prüffälle

Vier Datensätze:

1. Entwurf: kein scheduled_for, kein published_at.
2. Geplant: scheduled_for in der Zukunft, published_at leer.
3. Veröffentlicht: scheduled_for war 10:00, published_at ist 10:02, da die Auslieferung zwei Minuten später erfolgte.
4. Geplant mit überschrittenem Zeitpunkt, Auslieferung unklar: Status geplant, markiert.

Erwartete öffentliche Anzeigen: Fall 1 keine, Fall 2 keine, Fall 3 das Datum 10:02, Fall 4 keine. Das sind drei Fälle ohne öffentliches Datum und einer mit. Die Vorlage soll diese Zählung stabil wiedergeben.

Abbruchbedingungen

Übernehmen Sie das Modell nicht, wenn:

• Ihr System die tatsächliche Auslieferung nicht als Ereignis meldet. Dann nur „zuletzt geändert“ anzeigen und kein Veröffentlichungsdatum behaupten.
• bestehende Beiträge kein belegbares Veröffentlichungsdatum haben. Das Datum bleibt unbekannt und wird nicht erfunden.
• die Zeitzone der Eingabe nicht eindeutig ist. Erst festlegen, dann speichern.

Vorgeschlagene Abnahmetests (nicht durchgeführt)

1. Die vier Datensätze anlegen und prüfen, dass die Seite nur bei Fall 3 ein Datum zeigt.
2. Ein geplanter Beitrag wird manuell verschoben: Prüfen, dass kein published_at entsteht.
3. Auslieferung simuliert scheitern lassen und prüfen, dass Status geplant bleibt und kein Folgeschritt automatisch erneut läuft.
4. Strukturierte Angaben und Feed von Fall 2 prüfen: Es darf kein Veröffentlichungsdatum erscheinen.
5. Nach einer Textkorrektur prüfen, dass updated_at sich ändert und published_at gleich bleibt.

So bleibt jedes sichtbare Datum ein belegter Zeitpunkt, und ein Wunschtermin wird nicht zur Tatsache.

Quellen