Zeitzonen und Empfindlichkeit

1) Grundprinzipien

UTC als Transport und Lagerung. Alle Server-Zeitstempel und Sortierschlüssel sind in UTC. Konvertierung in lokale „Wand“ -Zeit - am Rand (Edge/UI) oder in einem speziellen Formatierungsdienst.
Die Zone ≠ die Verschiebung. 'Europe/Kyiv' ist nicht nur 'UTC + 02:00': Die Regeln ändern sich im Laufe der Zeit. Speichern Sie die IANA-IDs (tzdb) im Benutzer-/Objektprofil, nicht „+ 03:00“.
Klare Unterscheidung der Uhren.

Wanduhr (menschliche Zeit, unterliegt DST).
UTC-Uhr (universelle Skala).
Monotonische Uhr (zur Messung von Zeitdauern und Timeouts). Berechnen Sie niemals Timeouts auf einer „Wanduhr“.
Idempotenz und Toleranz gegenüber dem Zittern der Zeit. Systeme müssen kleine NTP/Offset-Sprünge korrekt überstehen.

2) Datenmodell und API-Verträge

Ereignisse: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), optional 'wall _ time' (lokal mit Beibehaltung des Offsets beim Anlegen).
Perioden: halbgeschlossene Intervalle'[start, end) 'in UTC verwenden; Speichern Sie für von Menschen lesbare Zeitpläne den ursprünglichen Ausdruck + Zone.
Wiederkehrende Regeln: Serialisieren als RRULE/cron-Äquivalent + IANA-Zone. Planung delegieren Sie die Engine, die DST versteht.
Zeitformat in der API: ISO 8601/RFC 3339 mit einem expliziten'Z 'oder Offset, z. B.' 2025-10-31T17: 00: 00Z'. Übergeben Sie keine „schwebenden“ Zeilen ohne Offset.
Versionierung: Die Änderung der Geschäftsregeln der Zeit (z. B. die Umstellung eines Landes auf eine konstante UTC + 1) ist die Migration von Konfigurationen und die Neuberechnung von Zeitplänen. Beachten Sie die Versionsschemata.

3) Sommerzeit (DST): Ambiguitäten und Pässe

Duplizierte lokale Zeiten. Im Herbst kann ein lokales „02:30“ zweimal passieren. Der Planer in der Zone muss zwischen '2025-10-26T02: 30 + 03' und '2025-10-26T02: 30 + 02' unterscheiden.
Verpasste lokale Zeiten. Im Frühjahr „springen“ Minutenintervalle (z.B. '02: 00-03: 00' existiert nicht). Es liegt in der Verantwortung des Planers, die Strategie zu definieren: auf „03:00“ verschieben, überspringen oder „so schnell wie möglich“ ausführen.
Empfehlung: Speichern Sie den Auftrag als „lokale Regel + Zone“ und materialisieren Sie die tatsächlichen Instanzen in UTC im Voraus (Rolling Window), wobei die ausgewählte Richtlinie auf DST festgelegt wird.

4) Leap seconds и time smear

Leap second. Eine zusätzliche Sekunde wird manchmal in UTC eingefügt. Die meisten Geschäftsprozesse sollten nicht „sehen“ 23:59: 60.
Smear (Verschmieren). Einige Umgebungen verteilen die Einstellung sanft auf das Fenster (z. B. ± 12 Stunden), um einen Sprung zu vermeiden.
Praxis: Vereinbaren Sie eine einheitliche Zeitrichtlinie für den gesamten Cluster (NTP/Near), loggen Sie sie in Metadaten und speichern Sie sie im Runbook.

5) Planer und Cron-Muster

Die Gefahr des „einfachen Cron“. Der klassische Cron kennt keine DST- und IANA-Zonen. Verwenden Sie Engines, bei denen der Zeitplan an eine Zone gebunden ist (Quartz-Klasse, Cloud-Scheduler-Dienste, Kubernetes CronJob mit Zone über Controller/Admission).
Materialisierung von Zeitplänen. Für die Zuverlässigkeit materialisieren Sie die nächsten N Starts in UTC (z. B. für 7-30 Tage), speichern Sie den Cursor und bestimmen Sie die Richtlinie in DST.
Die Idempotenz der Aufgaben. Ключ deduplication: `(job_id, scheduled_at_utc)`; Der Neustart darf keine Nebenwirkungen duplizieren.
Das Gleiten der Uhr. Bei langen Pausen/Vorfällen entscheiden Sie, ob Sie ein Catch-up (ausführen, was Sie verpasst haben) oder ein Skip durchführen. Konfigurieren Sie per-job.

6) Zeit in Protokollen und Warteschlangen

Ereignisbusse (Kafka/Pulsar). Speichern Sie' event _ time' und 'ingest _ time' getrennt. Für retrospektive Neuberechnungen verwenden Sie' event _ time'.
Idempotente Verbraucher. Konzentrieren Sie sich bei der Neulieferung auf den Schlüssel des Ereignisses und 'event _ time' und nicht auf den Offset in der Partei.
Sortierung und Fenster. Berechnen Sie „24 Stunden vor Ort“ -Fenster als UTC-Intervalle, die von den lokalen Regeln einer bestimmten Zone an einem bestimmten Datum abgeleitet sind.

7) Protokolle, Traces, Metriken

Einheitlicher Zeitzonen-Standard: alle technischen Protokolle und Metriken in UTC (mit Angabe von'Z'). Anzeige in Dashboards - lokalisiert für den Benutzer.
Traces: Übergeben Sie' trace _ start _ utc', 'duration _ ms' auf einer monotonen Uhr. Subtrahiere niemals „Wand“ -Zeitstempel.
Geschäftsberichte: Bilden Sie einen „Tag“ in der Domain-Zone (z. B. „Europa/Paris“ für die französische Steuer) und nicht nach UTC. Klar dokumentieren.

8) Benutzerprofile und Inhalte

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
Multi-Zonen-Entitäten: Für Teams/Organisationen speichern Sie die „Domain Zone“ (z.B. Store/juristische Person) unabhängig von der persönlichen Zone des Teilnehmers.
Benachrichtigungen: Berechnen Sie „stille Stunden“ im Benutzerbereich; senden shedulite von UTC-Fenster, mit Sicherheit bei DST.

9) Anti-Muster

Nur lokale Zeit ohne Offset/Zone speichern.
Den Offset „+ hh: mm“ anstelle der IANA-ID fest flashen.
Zählen Sie die Dauer durch die Differenz von zwei „Wand“ Zeitstempel.
Planen Sie mit cron ohne Zonenunterstützung/DST.
Machen Sie Analysen „für Tage“ in UTC, wenn der Standard eine lokale Zone erfordert.
Nehmen Sie die Unveränderlichkeit der Regeln der Zone an (Länder ändern die Zeitpolitik).

10) Testen der Zeit

Kontrollierte Uhr. Injizieren Sie die „Uhr“ in den Code (Clock/TimeProvider) für deterministische Tests.

• Umstellung auf Sommer-/Winterzeit (Doppel/Pässe).
• Verschieben eines Benutzers zwischen Zonen (Ändern von 'preferred _ timezone').
• Regeländerung in tzdb (Aktualisierung der Basis - Regressionstests).
• NTP Offsets, verzögerte Lieferung von Ereignissen.
• Fuzzy-Tests. Zufällige Zonen, Daten, Formate; Vergleich mit der Referenzbibliothek.

11) Beobachtbarkeit und Betrieb

Alertas: NTP nicht synchron, tzdb Update-Verzögerung, Spitzen von „unerfüllten“ Cron-Aufgaben in DST.
Dashboards: Verteilung der Ereignisse nach Zonen/lokalen Tagen; Catch-Up/Skip-Zähler.
Runbook: Verfahren zur Änderung der Zeitregeln in der Gerichtsbarkeit; die Aktualisierungsreihenfolge von tzdb; Kommunikation mit Fahrplaninhabern.

12) Implementierungsmuster

Time Normalization Gateway. Ein schlanker Dienst, der die eingehenden Zeiten auf RFC 3339 UTC normalisiert, Zonen validiert (IANA) und den Kontext ergänzt.
Local-Day Builder. Eine Bibliothek/ein Dienst, der aus einem „lokalen Tag“ und einer Zone genaue UTC-Grenzen'[start _ utc, end_utc) 'unter Berücksichtigung von DST erstellt.
Schedule Materializer. Der Scheduler, der die Regeln als „lokaler Ausdruck + Zone“ speichert, materialisiert zukünftige Instanzen in UTC und verwaltet Kollisionen/Auslassungen.
Dual-Timestamp Events. Ereignisse mit den Feldern 'occurred _ at _ utc', 'wall _ time _ local', 'timezone'. Für UI wird lokal ersetzt, für Systeme - UTC.

13) Checkliste des Architekten

1. Ist UTC überall gespeichert?
2. Haben Entitäten eine IANA-Zone und eine Domänen-Datenrichtlinie?
3. Versteht der Planer DST und materialisiert Instances in UTC?
4. Logs/Metriken - in UTC; Berichte - in der Domain-Zone?
5. Timeouts/Retrays - auf einer monotonen Uhr?
6. Ist das tzdb-Update automatisiert und überwacht?
7. Decken die Tests Regeländerungen, Takes/Auslassungen von Minuten ab?

14) Mini-Rezepte (Pseudocode)

Lokalen „Arbeitstag“ in UTC-Intervall umwandeln

function localDayToUtcInterval(dateLocal, tz):
startLocal = combine(dateLocal, 00:00) in tz endLocal  = startLocal + 1 day startUtc  = toUTC(startLocal) // учитывает DST endUtc   = toUTC(endLocal)
return [startUtc, endUtc)

Materialisierung eines wiederkehrenden Zeitplans

inputs: rrule, tz, windowStartUtc, windowEndUtc for each localOccurrence in expand(rrule, tz, [windowStartUtc, windowEndUtc] projected to tz):
emit occurrence { scheduled_at_utc = toUTC(localOccurrence), tz }

Idempotenter Task-Startschlüssel

dedupe_key = hash(job_id + scheduled_at_utc.toString())

15) Sicherheit und Compliance

Audit: Speichern Sie beide Zeitprojektionen (UTC und lokal), um die Benutzeransprüche („mir wurde bis 23:00 Uhr Lima versprochen“) mit der Serverchronologie in Einklang zu bringen.
Regulatorisch: Berichtszeiträume werden in den erforderlichen Zonen gebildet (Steuern, verantwortungsvolle Spielgrenzen, Marketingbeschränkungen „stundenweise“).
Privatsphäre: Zeitzone - persönliche Einstellungen, aber nicht genau identifizierende Daten; Verarbeitung im Rahmen der allgemeinen Datenschutzrichtlinien.

Schluss

Bei „Zeitsensitivität“ geht es nicht um das Format des Datums, sondern um die architektonischen Grenzen der Verantwortung: wo zu lagern, wo zu transformieren, wie zu planen und wie die Richtigkeit nachzuweisen ist. Vereinheitlichung auf UTC-Ebene, explizite IANA-Zonen, kompetente Planer, doppelte Zeitstempel und monotone Uhren verwandeln die Zeit von der Quelle der Vorfälle in einen vorhersehbaren Infrastrukturdienst.

• GeoDNS und Geo-Routing; Lastausgleich; Beobachtung von Ereignissen über die Zeit; Cron-Muster und die Materialisierung von Zeitplänen; Regionale Einschränkungen und lokale Meldetage.