Zeitzonenplanung für selbstgehostete Anwendungen: Checkliste vor der Bereitstellung

Zeitzonendesign ist eine betriebliche Anforderung, keine Anzeigepräferenz

Eine Entscheidung zur Zeitzone verändert, wie Menschen Fristen interpretieren, wann geplante Arbeiten ausgeführt werden, welche Datensätze zu einem Berichtszeitraum gehören und wie zuverlässig sich eine Ereignisabfolge untersuchen lässt. Behandeln Sie sie vor der Bereitstellung als Teil des Anwendungsdesigns, insbesondere bei Workloads für Zusammenarbeit, CRM, Publishing, Analysen, Terminplanung und Automatisierung.

Eine einzige „Anwendungszeitzone“ kann nützlich sein, stellt jedoch nicht automatisch eine vollständige Richtlinie dar. Ein globales Team benötigt möglicherweise eine stabile, systemweite Konvention für Berichte, Termine in der Ortszeit von Kunden, individuelle Anzeigepräferenzen für Nutzer sowie zeitzonenbewusste Zeitpläne für einen bestimmten Arbeitsbereich. Das sind unterschiedliche Anforderungen, die verschiedenen Ebenen zugeordnet sein können.

Die entscheidende Frage lautet nicht einfach: „Welche Zeitzone sollten wir einstellen?“ Fragen Sie stattdessen: Welche Geschäftsereignisse stehen für einen präzisen Zeitpunkt, welche für eine lokale Verpflichtung zu einer bürgerlichen Uhrzeit, und welche sind nur als Datum gedacht? Die Antwort bestimmt die benötigten Felder, Einstellungen, Integrationen und Tests.

• Ein Zeitpunkt: Ein Job wurde ausgeführt, eine Anmeldung erfolgte oder eine Nachricht wurde zu einem weltweit eindeutigen Moment gesendet.
• Eine lokale Verpflichtung zu einer bürgerlichen Uhrzeit: ein Termin um 09:00 Uhr an einem benannten Ort, für den Sommerzeitregeln gelten können.
• Eine Geschäftsangabe nur als Datum: ein Veröffentlichungsdatum, Urlaubstag oder Rechnungszeitraum, der sich bei der Anzeige an einem anderen Ort nicht unerwartet verschieben soll.
• Eine Anzeigepräferenz: die Art, wie ein einzelner Nutzer ansonsten eindeutige Datensätze dargestellt haben möchte.

Ermitteln Sie jede Zeitquelle im Stack

Beginnen Sie die Bestandsaufnahme, indem Sie den Weg jedes zeitkritischen Ereignisses zeichnen. Ein Browser kann einen Zeitstempel erzeugen, eine Anwendung ihn interpretieren, ein Container einen Worker ausführen, eine Datenbank ihn speichern und ein externer Kalender oder eine API ihn empfangen. Eine Abweichung an irgendeiner Stelle kann zu einem Ergebnis führen, das in einer Oberfläche korrekt und in einer anderen falsch erscheint.

Dokumentieren Sie Einstellungen und beobachtetes Verhalten, statt anzunehmen, dass ein Container das Verhalten des Hosts übernimmt. Docker-Images können dauerhafte Umgebungsvariablen mit Dockerfile ENV definieren, während zur Bereitstellungszeit über docker run --env oder eine gleichwertige Konfiguration bereitgestellte Werte diese ersetzen können. Prüfen Sie die Anwendungsdokumentation und die bereitgestellte Laufzeitkonfiguration auf dokumentierte Variablen oder Einstellungen zur Zeitzone.

Bei Anwendungen, die über Airbip bereitgestellt werden, läuft die Anwendung als Docker-Workload auf Airbip-Cloud-Servern. Daher sind Konfiguration auf Anwendungsebene und dokumentierte Container-Einstellungen wichtige Punkte für die Bereitstellungsdokumentation. Airbip übernimmt die umgebende Infrastruktur wie Routing und die Automatisierung von TLS-Zertifikaten, doch die Zeitzonensemantik innerhalb einer Anwendung, ihrer Daten und ihrer Integrationen erfordert weiterhin eine verantwortliche Entscheidung.

• Host-Betriebssystem: lokale Uhr, Zeitzone und Ansatz zur Zeitsynchronisation.
• Container-Image und Laufzeitkonfiguration: Umgebungsvariablen, gegebenenfalls eingebundene Zeitzonendaten und Worker-Konfiguration.
• Anwendung: globale Standardwerte, Organisations- oder Arbeitsbereichseinstellungen, Nutzerpräferenzen und Scheduler-Einstellungen.
• Datenbank: Spaltentypen, Sitzungszeitzone, Import-/Exportverhalten und Reporting-Abfragen.
• Browser und Mobilclient: lokale Darstellung, Datumsauswahlfelder und übermittelte Werte.
• Verbundene Dienste: Kalender, Webhooks, API-Konsumenten, Data Warehouses, Benachrichtigungstools und Identitätssysteme.

Ordnen Sie die Geschäftsereignisse zu, die von Zeit abhängen

Listen Sie die Ereignisse auf, die Ihre Anwendung erzeugt, verarbeitet, berechnet oder anzeigt. Tun Sie dies gemeinsam mit Geschäftsverantwortlichen und Administratoren: Ein technisch gültiger Standardwert kann dennoch zu einem unbrauchbaren Betriebsprozess führen, wenn ein regionales Team seinen Monat an einem anderen lokalen Datum abschließt oder ein Kunde einen Termin zur falschen Zeit erhält.

Benennen Sie für jedes Ereignis den fachlichen Verantwortlichen, die maßgebliche Quelle, das vorgesehene Zeitmodell, den mitgeführten Zeitzonenbezeichner oder Offset, den Speicherort, die Anzeigeregel und jedes nachgelagerte Ziel. Dieses Inventar bildet die Grundlage für Konfiguration und Abnahmetests.

• Termine und Verfügbarkeit: Buchungszeiträume, Erinnerungen, Verschiebungen, Stornierungen und wiederkehrende Besprechungen.
• Fristen: Aufgaben, Servicezusagen, Genehmigungsstichtage, Veröffentlichungsfenster und Kampagnenstarts.
• Geplante Automatisierung: wiederkehrende Workflows, Importe, Exporte, Zusammenfassungen, von der Anwendung angestoßene Backups und Aufbewahrungsjobs.
• Analysen und Berichte: tägliche Aggregationen, Monatsendgrenzen, Kohortendefinitionen und Dashboard-Filter.
• Aufbewahrung und Compliance: Ablauf, Löschberechtigung, Ereignisse im Zusammenhang mit Legal Holds und Richtlinienzeiträume.
• Audit- und Sicherheitsereignisse: Authentifizierung, Berechtigungsänderungen, Datenexporte, administrative Aktionen und Fehler.

Bewahren Sie eindeutige Daten auf und zeigen Sie lokale Zeit passend an

Bei Ereignissen, die zu einem bestimmten Moment stattgefunden haben, bewahren Sie eine eindeutige Darstellung dieses Moments auf und wenden Sie die lokale Darstellung erst dort an, wo eine Person sie lesen muss. RFC-3339-Zeitstempel mit einem numerischen UTC-Offset kommunizieren eine bekannte Beziehung zu UTC. Verwenden Sie keine Zeitzonenabkürzung wie CST oder IST als Bezeichner: IANA weist darauf hin, dass solche Abkürzungen in der Praxis mehrdeutig sind.

Wenn ein Verhalten den bürgerlichen Zeitregeln eines Orts folgen muss, verwenden Sie einen ortsbasierten IANA-Bezeichner wie America/Denver statt eines festen numerischen Offsets. Eine benannte Zone repräsentiert Regeln, die Sommerzeitverhalten einschließen können, während ein numerischer Offset allein diese künftigen Regeländerungen nicht ausdrückt. Die IANA-Zeitzonendatenbank wird regelmäßig wegen politischer Änderungen an Grenzen, Offsets und Sommerzeitregeln aktualisiert. Deshalb ist es sinnvoll, sie über die Betriebsumgebung und das Supportmodell der Anwendung aktuell zu halten.

Gehen Sie nicht davon aus, dass der Speichertyp eines Zeitstempels jede Geschäftsfrage beantwortet. In PostgreSQL werden Werte vom Typ timestamp with time zone intern in UTC gespeichert und entsprechend der Sitzungsvariable TimeZone angezeigt; die ursprünglich angegebene oder angenommene Zeitzone bleibt nicht erhalten. Dagegen ist timestamp without time zone ein bürgerlicher Datums- und Zeitwert und kein Zeitpunkt; eine Zeitzonenangabe in einer so typisierten Eingabe wird ignoriert. Prüfen Sie die tatsächlich verwendeten Typen der Anwendung, bevor Sie Berichte oder Untersuchungsverfahren darauf aufbauen.

• Verwenden Sie einen präzisen Zeitpunkt für Ereignisreihenfolge, Audit-Nachweise, Ausführungshistorie und regionsübergreifende Systemaktivität.
• Speichern oder bewahren Sie die relevante benannte Zone separat auf, wenn der Ort und dessen Regeln für die bürgerliche Zeit fachlich relevante Daten sind.
• Verwenden Sie für Verpflichtungen, die nur ein Datum betreffen, eine explizite Darstellung nur als Datum; erzeugen Sie keine Mitternachtszeitstempel, sofern die Anwendungssemantik dies nicht ausdrücklich verlangt.
• Legen Sie die Zeitzone von Berichtszeiträumen fest und kennzeichnen Sie Berichte und Exporte mit dieser Konvention.
• Behandeln Sie einen aktuellen UTC-Offset nicht als dauerhafte Zeitzonenrichtlinie.

Setzen Sie Standardwerte auf der richtigen Ebene

Wählen Sie die engste Einstellung, die die Geschäftsanforderung erfüllt. Ein Systemstandard kann einheitliches Verhalten für unbeaufsichtigte Prozesse und Nutzer ohne Präferenz bieten. Er sollte nicht die berechtigte Anforderung überschreiben, dass ein Arbeitsbereich, eine Ressource, ein Kundenstandort oder ein einzelner Nutzer nach einer anderen lokalen Zeitbasis arbeitet.

Ermitteln Sie vor der Wahl eines Standardwerts, welche Einstellungen nur die Anzeige beeinflussen, welche Speicherung oder Parsing betreffen und welche geplante Arbeit steuern. Diese Unterschiede sind anwendungsspezifisch. Bestätigen Sie sie anhand der offiziellen Anwendungsdokumentation und testen Sie dann das bereitgestellte Verhalten, statt von einer ähnlich benannten Einstellung zu extrapolieren.

Eine praktische Ausgangsbasis für viele Bereitstellungen ist eine klar dokumentierte Systemkonvention für Betrieb und Reporting, kombiniert mit Einstellungen für benannte Zonen bei ortsgebundenen Zeitplänen und mit Anzeigepräferenzen auf Nutzerebene, sofern die Anwendung dies unterstützt. Stellen Sie dies nicht als universelle Vorlage dar: Ein Team in einer einzigen Region ohne Kundenterminplanung kann bewusst eine einfachere Richtlinie wählen.

• Systemstandard: Definieren Sie seinen Zweck und welche Dienste oder Worker ihn verwenden.
• Organisations- oder Arbeitsbereichszeitzone: Verwenden Sie sie, wenn ein gemeinsamer Kalender, ein Reporting-Stichtag oder Betriebszeiten eines Teams einen gemeinsamen lokalen Kontext benötigen.
• Nutzerzeitzone: Verwenden Sie sie für personalisierte Anzeige und Benachrichtigungen, wenn Nutzer in mehreren Regionen arbeiten.
• Ressourcen- oder Standortzeitzone: Verwenden Sie sie für Räume, Niederlassungen, Servicegebiete und Kundentermine.
• Zeitplanzweitzone: Dokumentieren Sie sie für jede Automatisierung oder wiederkehrende Aufgabe separat, wenn die Anwendung dies unterstützt.

Behandeln Sie Sommerzeitgrenzen und globale Teams als zentrale Anwendungsfälle

Übergänge zur Sommerzeit legen Annahmen offen, die an gewöhnlichen Daten verborgen bleiben. Bei der Umstellung im Frühjahr gibt es manche lokalen Uhrzeiten nicht. Bei der Umstellung im Herbst kann eine lokale Uhrzeit zweimal auftreten. Falls ein Kalender oder eine API lokale Zeit zusammen mit einer Zeitzone akzeptiert, testen Sie beide Fälle und legen Sie fest, was Nutzer erwarten sollen.

Das Verhalten von Kalendern muss ein explizites Zeitmodell verwenden. RFC 5545 legt fest, dass ein DATE-TIME-Wert ohne UTC-Kennzeichnung und ohne TZID eine schwebende Zeit ist. Für Empfänger in unterschiedlichen Zeitzonen kann er zu unterschiedlichen tatsächlichen Zeitpunkten auftreten und sollte nur verwendet werden, wenn genau dieses Verhalten wirklich angemessen ist. Verwenden Sie für eine feste Zeit UTC oder lokale Zeit mit Zeitzonenreferenz.

Wiederkehrende Zeitpläne erfordern besondere Prüfung. RFC 5545 legt fest, dass Wiederholungsinstanzen zu nicht existierenden lokalen Zeiten ignoriert werden. Das kann standardkonform sein und trotzdem einer geschäftlichen Erwartung wie „Sende diese Erinnerung jeden Tag um 02:30 Uhr“ widersprechen. Entscheiden Sie anhand der dokumentierten Fähigkeiten der Anwendung oder des angebundenen Schedulers, ob die gewünschte Richtlinie Überspringen, Verschieben, Ausführen zu einer alternativen Zeit oder eine Prüfung durch einen Betreiber vorsieht.

• Testen Sie eine Zeit innerhalb der bei der Umstellung im Frühjahr entfallenden Stunde in jeder unterstützten benannten Zone.
• Testen Sie beide Vorkommen einer bei der Umstellung im Herbst wiederholten lokalen Zeit und prüfen Sie die Reihenfolge in Benutzeroberfläche, Exporten und Logs.
• Testen Sie einen wiederkehrenden Termin oder Job, der jeden Übergang überschreitet.
• Testen Sie Nutzer, die denselben Termin aus mindestens zwei verschiedenen Zonen anzeigen.
• Testen Sie Felder, die nur ein Datum enthalten, in der Nähe von Mitternacht für Nutzer östlich und westlich der geschäftlichen Standardzeitzone.

Prüfen Sie geplante Aufgaben und Integrationen durchgängig

Der nominale Ausdruck eines Schedulers sagt nicht alles aus. Cron kann eine CRON_TZ-Zeitzone für eine Crontab verwenden, während die Zeitstempel der Daemon-Logs die lokale Zeitzone des Rechners nutzen. Somit können ein Zeitplan und die Logs, die seine Ausführung belegen sollen, unterschiedliche Zeitzonenkontexte verwenden. Halten Sie bei der Validierung beide fest.

Auch das Cron-Verhalten bei Zeitumstellungen ist Betriebsverhalten, das getestet und nicht vorausgesetzt werden sollte. Das referenzierte Cron-Handbuch beschreibt eine besondere Behandlung lokaler Zeitänderungen unter drei Stunden, einschließlich der Behandlung von Jobs in der übersprungenen Stunde und der Vermeidung doppelter Ausführung betroffener Jobs bei einer Rückstellung der Uhr. Andere Scheduler und Worker auf Anwendungsebene können sich anders verhalten. Validieren Sie daher die exakt verwendete Komponente.

Dokumentieren Sie für jede Integration, ob die Payload UTC, einen RFC-3339-Zeitstempel mit Offset, lokale Zeit mit benannter Zone, schwebende Zeit oder Daten nur als Datum überträgt. Dokumentieren Sie außerdem, was der empfangende Dienst mit diesen Daten tut. Ein Integrationsvertrag sollte festlegen, wer für Umwandlung, Validierung und Fehlerbehandlung zuständig ist – und nicht nur einen beispielhaften Zeitstempel zeigen.

• Für jeden Zeitplan: Ausdruck, vorgesehene Zone, Ausführende Komponente, Log-Zone, Wiederholungsrichtlinie und Sommerzeiterwartung.
• Für jedes API-Feld: Typ, Beispieldarstellung, ob es einen Zeitpunkt oder eine bürgerliche Zeit bezeichnet, und Validierungsverhalten.
• Für jede Kalenderanbindung: Zeitzonenreferenz, Behandlung von Wiederholungen, erwartete Anzeige für Eingeladene und Verhalten bei Neuplanung.
• Für Webhooks und Exporte: Zeitstempelformat, Vorhandensein von Zeitzone/Offset, Annahmen zur Reihenfolge und Parsing-Regeln des Ziels.
• Für externe Systeme: Bestimmen Sie die verantwortliche Person, die jeder Zeitzonenumwandlung oder Schemaänderung zustimmen muss.

Prüfen Sie Datenbank, Exporte und Audit-Logs, bevor Sie sich darauf verlassen

Reporting- und Untersuchungsverfahren sollten auf beobachtetem Datenverhalten beruhen, nicht allein auf einer Bildschirmbeschriftung. Prüfen Sie repräsentative Datensätze in der Anwendung, Datenbank und in Exportformaten. Bestätigen Sie, ob die Filterung in der Anwendung, in der Datenbanksitzung oder im Client erfolgt, ob Daten vor der Gruppierung umgerechnet werden und ob ein Export seine Zeitzonenkonvention ausweist.

Für Audit-Zwecke dokumentieren Sie sowohl die Ereigniszeit als auch den Zeitpunkt, zu dem ein Log geschrieben wurde, wenn diese voneinander abweichen können. OWASP empfiehlt, die Zeit über Server und Geräte hinweg zu synchronisieren, wo dies möglich ist, und Logging in Anwendungstests sowie Sicherheitsprüfungen einzubeziehen. Ein verlässlicher Audit-Prozess benötigt außerdem eine festgelegte Zeitzonenkonvention für Personen, die Logs lesen, insbesondere wenn mehrere Systeme beteiligt sind.

Ändern Sie Produktionsdaten einer Anwendung nicht direkt, nur um Zeitstempel zu vereinheitlichen, ohne einen anwendungsspezifischen Migrationsplan. Klären Sie zunächst, wie die Anwendung ihre Felder interpretiert, erstellen Sie ein wiederherstellbares Backup, testen Sie anhand einer Nicht-Produktionskopie und validieren Sie betroffene Berichte, Zeitpläne, Integrationen und Audit-Ansichten.

• Prüfen Sie die Rohdatentypen der Datenbankspalten und das dokumentierte Datenmodell der Anwendung.
• Vergleichen Sie ein Ereignis in der Benutzeroberfläche, Datenbank, im Anwendungslog, im Reverse-Proxy- oder Host-Log, soweit verfügbar, sowie in exportierten Daten.
• Überprüfen Sie Sortierung und Bereichsfilter rund um lokale Mitternacht und eine Sommerzeitgrenze.
• Bestätigen Sie, ob ursprüngliche Eingabezone, aktuelle Anzeigezone und UTC-Zeitpunkt separat verfügbar sind, sofern das Geschäft dies benötigt.
• Bewahren Sie Nachweise zu Testeingaben, erwarteten Ergebnissen, tatsächlichen Ergebnissen und Konfigurationsversionen auf.