Strefy czasowe i wrażliwość

1) Podstawowe zasady

UTC jako transport i przechowywanie. Wszystkie znaczniki czasu serwera i klawisze sortowania są w UTC. Konwersja do czasu lokalnego „ściany” - na krawędzi (krawędzi/interfejsu użytkownika) lub w specjalnie dedykowanym serwisie formatowania.
Przesunięcie strefowe. „Europa/Kijów” to nie tylko „UTC + 02:00”: zasady zmieniają się z czasem. Przechowywać identyfikatory IANA (tzdb) w profilu użytkownika/obiektu, a nie „+ 03:00”.
Wyraźne rozróżnienie zegara.

Zegar ścienny (czas ludzki, podlegający DST).
Zegar UTC (uniwersalna skala).
Zegar monotoniczny (do pomiaru czasu trwania i czasu trwania). Nigdy nie obliczaj czasu na zegarze ściennym.
Idempotencja i tolerancja na drżenia czasowe. Systemy muszą prawidłowo przetrwać małe skoki NTP/offset.

2) Modele danych i umowy API

Zdarzenia: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), opcjonalnie 'wall _ time' (lokalny z offsetem przy tworzeniu).
Okresy: używać w UTC połowicznych odstępów „[start, end)”; dla harmonogramów czytelnych dla człowieka należy zachować oryginalną strefę wyrażenia +.
Duplikat rules: serialize jako RRULE/cron equivalent + IANA zone. Delegować planowanie do silnika, który rozumie DST.
Format czasu w API: ISO 8601/RFC 3339 z wyraźnym 'Z' lub przesunięciem, na przykład '2025-10-31T17: 00: 00Z'. Nie przechodź linii pływających bez offsetu.
Wersioning: zmiana zasad prowadzenia działalności w czasie (na przykład zmiana kraju na stały UTC + 1) to migracja konfiguracji i ponowne obliczenie harmonogramów; rozważyć w schematach wydania.

3) Czas oszczędzania światła dziennego (DST): niejasności i zaniechania

Zdublowane czasy lokalne. Jesienią lokalne „02:30” może się zdarzyć dwa razy. Plantator w strefie musi rozróżniać „2025-10-26T02: 30 + 03” i „2025-10-26T02: 30 + 02”.
Brakowało lokalnych czasów. Wiosną, minutowe odstępy „skakać” (na przykład, '02: 00-03: 00' nie istnieje). Planista musi określić strategię: przejść do '03:00', pominąć lub wykonać „jak najszybciej”.
Zalecenie: zapisać zadanie jako „lokalną strefę reguły +”, i urzeczywistnić rzeczywiste przypadki w UTC z wyprzedzeniem (rolling window), ustalając wybraną politykę na DST.

4) Sekundy skoku przez smear czasu

Skok sekundy. Dodatkowa sekunda jest czasami wstawiona w UTC. Większość procesów biznesowych nie powinna „widzieć” 23:59:60.
Rozmaz. Niektóre środowiska delikatnie rozprowadzają regulację na okno (na przykład ± 12 godzin), aby uniknąć skoku.
Praktyka: uzgodnić jedną politykę czasu dla całego klastra (NTP/smir), zalogować go w metadanych i zachować go w zakładce.

5) Planery i wzory kronowe

Niebezpieczeństwo "prostej korony. "Klasyczny cron nie zna stref DST i IANA. Użyj silników, w których harmonogram jest związany ze strefą (klasa kwarcu, usługi Scheduler w chmurze, Kubernetes CronJob ze strefą poprzez kontroler/administrację).
Urzeczywistnianie harmonogramów. Dla niezawodności, urzeczywistnić następny N działa w UTC (na przykład przez 7-30 dni), zapisać kursor i określić zasady w DST.
Idempotencja zadań. Deduplikowanie „(job_id, scheduled_at_utc)”; ponowne uruchomienie nie powinno powielać działań niepożądanych.
Zegar się poślizgnął. W przypadku długich przerwy/incydentów, zdecydować, czy nadrobić zaległości lub pominąć. Konfiguracja na zadanie.

6) Czas w protokołach i kolejkach

Autobusy imprezowe (Kafka/Pulsar). Zapisz 'event _ time' i 'ingest _ time' osobno. Użyj 'event _ time' dla przydziałów retrospektywnych.
Idempotentni konsumenci. Podczas przekierowywania, skupić się na klucz zdarzenia i 'event _ time' zamiast przesunięcia w partii.
Sortowanie i okna. Obliczanie okien „24 godziny czasu przechowywania lokalnego” jako odstępów UTC uzyskanych z lokalnych reguł danej strefy dla określonej daty.

7) Kłody, ślady, mierniki

Ujednolicony standard strefy czasowej: wszystkie dzienniki techniczne i mierniki w UTC (ze wskazaniem 'Z'). Wyświetlacz w deskach rozdzielczych - zlokalizowany dla użytkownika.
Trace - Pass 'trace _ start _ utc',' duration _ ms 'na zegarze monotonicznym. Nigdy nie odejmuj znaczników czasowych „ściany”.
Raporty biznesowe: Utwórz „dzień” w strefie domeny (np. „Europa/Paryż” dla francuskiego podatku), a nie UTC. Dokument jest jasny.

8) Profile i zawartość użytkowników

Мровила: 'preferred _ timezone' (IANA), 'preferred _ locale', 'currency', 'week _ start' (Mon/Sun).
Podmioty wielosekcyjne: dla zespołów/organizacji przechowywać „strefę domeny” (na przykład sklep/podmiot prawny) niezależnie od strefy osobistej uczestnika.
Powiadomienia: obliczyć „ciche godziny” w strefie użytkownika; wysyłać z okna UTC, z zabezpieczeniami DST.

9) Anty-wzory

Przechowywać tylko czas lokalny bez przesunięcia/strefy.
Hard flash offset '+ hh: mm' zamiast identyfikatora IANA.
Obliczyć czas trwania przez różnicę dwóch „ściennych” znaczników czasowych.
Plan przez cron bez wsparcia strefy/DST.
Analytics „dzień po dniu” w UTC, gdy standard wymaga strefy lokalnej.
Zakładaj niezmienność zasad strefy (kraje zmieniają politykę czasu).

10) Badanie czasu

Kontrolowane godziny. Wstrzyknąć „zegar” do kodu (zegar/usługodawca) do testów deterministycznych.

• Czas oszczędzania światła dziennego (dubs/skips) zmienia się.
• Przesuń użytkownika między strefami (zmień 'preferowane _ timezone').
• Zmiana reguły w tzdb (aktualizacja podstawowa - testy regresyjne).
• NTP offsets, opóźniona dostawa zdarzeń.
• Rozmyte testy. Strefy losowe, daty, formaty; porównanie z biblioteką referencyjną.

11) Obserwowalność i działanie

Alerts: NTP misalignment, tzdb aktualizacji lag, wybuchy „niespełnionych” zadań cron z DST.
Deski rozdzielcze: rozkład wydarzeń według stref/dni lokalnych; liczniki nadrobienia zaległości/pominięcia.
Runbook: procedury zmiany zasad czasu w jurysdykcji; tzdb zaktualizować zamówienie komunikujące się z właścicielami harmonogramu.

12) Schematy wdrażania

Brama normalizacji czasu. Subtelna usługa, która normalizuje czas przychodzący do RFC 3339 UTC, zatwierdza strefy (IANA) i uzupełnia kontekst.
Lokalny budowniczy. Biblioteka/usługa, która buduje dokładne granice UTC '[start _ utc, end_utc)' z „dnia lokalnego” i strefy, biorąc pod uwagę DST.
Harmonogram materializer. Harmonogram przechowujący zasady jako „lokalna strefa wyrażenia +” materializuje przyszłe przypadki w UTC i zarządza kolizjami/pominięciami.
Wydarzenia z podwójnym Timestamp. Zdarzenia z polami 'occurred _ at _ utc',' wall _ time _ local ',' timezone '. Lokalne jest zastępowane interfejsem użytkownika, UTC dla systemów.

13) Lista kontrolna architekta

1. Czy UTC jest przechowywane wszędzie?
2. Czy jednostka posiada strefę IANA i politykę danych domeny?
3. Czy grafik rozumie DST i urzeczywistnia przypadki w UTC?
4. Kłody/mierniki - w UTC; raporty - w strefie domeny?
5. Timeouts/retreats - na zegarku monotonicznym?
6. Czy aktualizacja tzdb jest zautomatyzowana i monitorowana?
7. Testy obejmują zmiany reguł, podwójne/pominięte minuty?

14) Mini przepisy (pseudokoda)

Konwertuj lokalny „dzień pracy” do przedziału UTC

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)

Urzeczywistnienie harmonogramu powtarzania się

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 }

Idempotentny klucz startowy zadania

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

15) Bezpieczeństwo i zgodność

Audyt: Zachowaj prognozy czasu (UTC i lokalne), aby pogodzić roszczenia użytkowników („Obiecano mi przed 11: 00 Lima”) z chronologią serwera.
Regulacja: okresy sprawozdawcze powstają w wymaganych strefach (podatki, odpowiedzialne limity gier, ograniczenia marketingowe „o godzinę”).
Prywatność: strefa czasowa - ustawienia osobiste, ale nie dokładnie identyfikujące dane; Przetwarzanie w ramach wspólnej polityki prywatności.

Wniosek

„Wrażliwość czasu” nie dotyczy formatu daty, ale granic architektonicznych odpowiedzialności: gdzie przechowywać, gdzie przekształcić, jak planować i jak udowodnić poprawność. Zjednoczenie UTC, wyraźne strefy IANA, kompetentni rozkładowcy, podwójne znaczniki czasu i zegary monotoniczne zmieniają czas ze źródła incydentów w przewidywalną usługę infrastrukturalną.

• GeoDNS i geo-routing; Równoważenie obciążenia; Obserwowalność zdarzeń w czasie; Wzory kronów i urzeczywistnienie harmonogramu; Ograniczenia regionalne i lokalne dni sprawozdawcze.