Fusuri orare și sensibilitate

1) Principii de bază

UTC ca transport și depozitare. Toate marcajele de timp ale serverului și cheile de sortare sunt în UTC. Conversia la ora locală de „perete” - la margine (muchie/UI) sau într-un serviciu de formatare special dedicat.
Zona ≠ decalată. „Europa/Kiev” nu este doar „UTC + 02:00”: regulile se schimbă în timp. Stoca IANA ID-uri (tzdb) în profilul utilizator/obiect, nu „+ 03:00”.
Distincţie clară de ceas.

Ceas de perete (timp uman, sub rezerva DST).
Ceas UTC (scară universală).
Ceas monotonic (pentru măsurarea duratelor și timeouts). Nu calculați niciodată timpii pe un ceas de perete.
Idempotența și toleranța la tremor de timp. Sistemele trebuie să supraviețuiască corect salturilor mici NTP/offset.

2) Modelul de date și contractele API

Evenimente: 'happened _ at' (UTC, RFC 3339), 'timezone' (IANA), opțional 'wall _ time' (local cu offset la creație).
Perioade: utilizați intervale jumătate închise „[start, end)” în UTC; pentru programele care pot fi citite de om, păstrați expresia originală + zona.
Reguli duplicat: serializați ca RRULE/cron echivalent + zona IANA. Delegat de planificare la un motor care înțelege DST.
Formatul timpului în API: ISO 8601/RFC 3339 cu „Z” explicit sau offset, de exemplu „2025-10-31T17: 00: 00Z”. Nu treceți liniile plutitoare fără decalaj.
Versioning: schimbarea regulilor de afaceri în timp (de exemplu, trecerea unei țări la UTC + 1 constant) este migrarea configurațiilor și recalcularea programelor; luați în considerare în schemele de eliberare.

3) Timpul de economisire a luminii de zi (DST): ambiguități și omisiuni

Duplicat ori locale. Toamna, „02:30” local se poate întâmpla de două ori. Planificatorul din zonă trebuie să facă distincția între „2025-10-26T02: 30 + 03” și „2025-10-26T02: 30 + 02”.
Ratat ori locale. În primăvară, intervale de minute „sari” (de exemplu, „02: 00-03: 00” nu există). Planificatorul trebuie să determine strategia: treceți la '03:00', săriți sau executați „cât mai curând posibil”.
Recomandare: stocați lucrarea ca „regulă locală + zonă” și materializați instanțele reale în UTC în avans (fereastră de rulare), fixând politica selectată pe DST.

4) Salt secunde и frotiu de timp

Salt în al doilea rând. O secundă suplimentară este uneori introdusă în UTC. Majoritatea proceselor de afaceri nu ar trebui să „vadă” 23:59:60.
Frotiu. Unele medii distribuie ușor ajustarea pe fereastră (de exemplu, ± 12 ore) pentru a evita un salt.
Practică: conveniți asupra unei politici unice de timp pentru întregul cluster (NTP/smir), înregistrați-l în metadate și păstrați-l în runbook.

5) Planificatori și modele cron

Pericol de "simplu cron. "Cron clasic nu cunoaște zonele DST și IANA. Utilizați motoare în care programul este legat de zonă (clasa Quartz, servicii cloud Scheduler, Kubernetes CronJob cu zonă prin controler/administrare).
Materializarea programelor. Pentru fiabilitate, materializați următorul N rulează în UTC (de exemplu, timp de 7-30 de zile), stocați cursorul și determinați politica la DST.
Idempotenţa sarcinilor. Ключ deduplicare: „(job_id, scheduled_at_utc)”; repornirea nu ar trebui să duplicați efectele secundare.
Alunecare de ceas. Pentru pauze/incidente lungi, decideți dacă să recuperați sau să săriți. Configurați per-job.

6) Timpul în protocoale și cozi

Autobuze de evenimente (Kafka/Pulsar). Stocați separat 'event _ time' și 'ingest _ time'. Utilizați 'event _ time' pentru alocări retrospective.
Consumatori idemptivi. Atunci când redelivering, se concentreze pe cheia de eveniment și „event _ time”, mai degrabă decât offset în lot.
Sortare și ferestre. Calculați ferestrele „24 de ore ora locală a magazinului” ca intervale UTC obținute din regulile locale ale unei anumite zone pentru o anumită dată.

7) busteni, urme, valori

Standard de fus orar unificat: toate jurnalele tehnice și măsurătorile din UTC (indicând „Z”). Afișare în tablouri de bord - localizate pentru utilizator.
Trace - Pass' trace _ start _ utc', "duration _ ms' pe un ceas monotonic. Nu scădeți niciodată marcajele de timp „de perete”.
Rapoarte de afaceri: Formați o „zi” în zona de domeniu (de ex. „Europa/Paris” pentru taxa franceză), mai degrabă decât UTC. Documentul este clar.

8) Profiluri de utilizator și conținut

Профиль: 'prefered _ timezone' (IANA), 'prefered _ locale', 'valute', 'week _ start' (Mon/Sun).
Entități multi-zone: pentru echipe/organizații, stocați o „zonă de domeniu” (de exemplu, un magazin/persoană juridică) indiferent de zona personală a participantului.
Notificări: se calculează „ore liniștite” în zona utilizatorului; trimite de la fereastra UTC, cu securitate DST.

9) Anti-modele

Depozitați numai ora locală fără offset/zonă.
Hard flash offset '+ hh: mm' în loc de identificator IANA.
Calculați durata prin diferența a două marcaje de timp „de perete”.
Plan de cron fără zonă/suport DST.
Do analytics' zi de zi "în UTC, când standardul necesită o zonă locală.
Asumați invariabilitatea regulilor zonei (țările schimbă politica timpului).

10) Testarea timpului

Ore controlate. Injectați „ceasul” în cod (Clock/TimeProvider) pentru teste deterministe.

• Timpul de economisire a luminii de zi (dube/sărituri) se schimbă.
• Mutați utilizatorul între zone (schimbați 'prefered _ timezone').
• Modificarea regulii în tzdb (actualizare de bază - teste de regresie).
• NTP compensează, livrarea întârziată a evenimentelor.
• Teste fuzzy. Zone aleatorii, date, formate; comparație cu o bibliotecă de referință.

11) Observabilitate și funcționare

Alerte: nealinierea NTP, decalajul actualizării tzdb, explozii de sarcini cron „neîmplinite” cu DST.
Tablouri de bord: distribuirea evenimentelor pe zone/zile locale; catch-up/skip contoare.
Runbook: proceduri pentru schimbarea regulilor de timp într-o jurisdicție; ordine de actualizare tzdb comunicarea cu proprietarii de program.

12) Modele de implementare

Normalizarea Timpului Gateway. Un serviciu subtil care normalizează timpii de intrare la RFC 3339 UTC, validează zonele (IANA) și completează contextul.
Local-Day Builder. O bibliotecă/serviciu care construiește limitele UTC exacte [start _ utc, end_utc) 'din „ziua locală” și zona, ținând cont de DST.
Materializator de program. Un programator care stochează reguli ca „expresie locală + zonă” materializează instanțe viitoare în UTC și gestionează coliziuni/omisiuni.
Evenimente Dual-Timestamp. Evenimente cu câmpuri 'happened _ at _ utc',' wall _ time _ local ',' fus orar '. Local este înlocuit cu UI, UTC pentru sisteme.

13) Lista de verificare a arhitectului

1. UTC este stocat peste tot?
2. Are entitatea o zonă IANA și o politică de date de domeniu?
3. Schedulerul înțelege DST și materializează cazuri în UTC?
4. Jurnale/valori - în UTC; rapoarte - în zona de domeniu?
5. Timeouts/retrageri - pe un ceas monotonic?
6. Actualizarea tzdb este automatizată și monitorizată?
7. Testele acoperă modificările regulilor, dublele/minutele pierdute?

14) Mini rețete (pseudocod)

Convertiți „ziua de lucru” locală la intervalul 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)

Materializarea unui program recurent

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 }

Cheie de pornire a sarcinii idempotente

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

15) Siguranță și conformitate

Audit: Păstrați ambele proiecții de timp (UTC și local) pentru a reconcilia revendicările utilizatorilor („Am fost promis înainte de 11 p.m. Lima”) cu cronologia serverului.
Reglementare: perioadele de raportare se formează în zonele solicitate (taxe, limite de joc responsabil, restricții de marketing „la oră”).
Confidențialitate: fusul orar - setările personale, dar nu identificarea cu exactitate a datelor; Procesați în cadrul politicilor comune de confidențialitate.

Concluzie

„Sensibilitatea timpului” nu se referă la formatul datei, ci la limitele arhitecturale ale responsabilității: unde se stochează, unde se transformă, cum se planifică și cum se dovedește corectitudinea. Unificarea UTC, zonele IANA explicite, programatorii competenți, marcajele temporale duale și ceasurile monotonice transformă timpul dintr-o sursă de incidente într-un serviciu de infrastructură predictibil.

• GeoDNS și geo-rutare; Echilibrarea sarcinii; Observabilitatea evenimentelor în timp; Modelele cron și materializarea programului; Restricții regionale și zile de raportare locală.