Fuso orario e sensibilità

1) Principi di base

UTC come trasporto e storage. Tutti i timeline server e le chiavi di ordinamento sono in UTC. La conversione in tempo di acciaio locale è al bordo (edge/UI) o in un servizio di formattazione dedicato.
«Europa/Kyiv» non è solo «UTC + 02:00». Le regole cambiano nel tempo. Memorizzare gli ID IANA (tzdb) in un profilo utente/oggetto anziché + 03:00.
Una netta differenza di orologi.

Wall clock (tempo umano soggetto a DST).
UTC clock (scala universale).
Monotonic clock (per misurare lunghezze e timeout). Non calcolate mai i timeout dell'orologio.
Idempotia e tolleranza al tremore del tempo. I sistemi devono affrontare in modo corretto piccoli picchi NTP/offset.

2) Modello di dati e contratti API

Gli eventi sono «occurred _ at» (UTC, RFC 3339), «timezone» (IANA), opzionalmente «wall _ time» (locale mantenendo lo spostamento durante la creazione).
Periodi: usa intervalli semisconosciuti «[start, end)» in UTC; per le programmazioni umane, memorizzare l'espressione originale + area.
Regole ripetute: serializzare come RRULE/cron-equivalente + zona IANA. Per pianificare, delegare un motore che comprenda DST.
Formato temporale API: ISO 8601/RFC 3339 con «Z» o spostamento esplicito, ad esempio «2025-10-31T17: 00: 00Z». Non passare righe flottanti senza offset.
Versioning: la modifica delle regole aziendali del tempo (ad esempio, il passaggio del paese a UTC + 1 permanente) è una migrazione delle configurazioni e un ricalcolamento delle pianificazioni. Tenere conto degli schemi di versione.

3) Ora estiva (DST): ambiguitete e pass

Tempi locali duplicati. In autunno, la 02:30 potrebbe succedere due volte. Il pianificatore nella zona deve distinguere tra «2025-10-26T02: 30 + 03» e «2025-10-26T02: 30 + 02».
Orari locali mancati. In primavera, non esistono intervalli di minuti (ad esempio, '02: 00-03: 00'). Il programmatore deve definire la strategia da spostare a «03:00», saltare o eseguire «il prima possibile».
Raccomandazione: conserva l'operazione come regola locale + zona, mentre le istanze effettive vengono materializzate in precedenza in UTC (rolling window), con il criterio selezionato impostato su DST.

4) Leap seconds и time smear

Leap second. Un secondo in più a volte viene inserito in UTC. La maggior parte dei processi aziendali non devono essere visti 23:59:60.
Smear (smussatura). Alcuni ambienti distribuiscono delicatamente la regolazione alla finestra (ad esempio, © 12 ore) per evitare il salto.
Pratica: concordare un unico criterio temporale per l'intero cluster (NTP/Smir), regolarlo nei metadati e tenerlo in runbook.

5) Pianificatori e cron-pattern

Il pericolo del semplice cron. Il classico cron non conosce le zone DST e IANA. Utilizzare i motori in cui la pianificazione è collegata alla zona (classe Quartz, servizi Scheduler cloud, Kubernets) con la zona tramite il controller/admission.
Materializzazione degli orari. Per l'affidabilità, materializzare i prossimi N di avvio in UTC (ad esempio per 7-30 giorni), memorizzare cursor e determinare il criterio in DST.
Idempotismo delle attività. Ключ deduplication: `(job_id, scheduled_at_utc)`; un nuovo avvio non deve duplicare gli effetti collaterali.
Scivolamento di ore. In caso di lunghe interruzioni o incidenti, decidere se eseguire catch-up (eseguire il mancato) o skip. Configurare per-job.

6) Tempo in protocolli e code

Pneumatici di evento (Kafka/Pulsar). Memorizza «event _ time» e «ingest _ time» separatamente. Usa «event _ time» per ricalcolare i calcoli retrospettivi.
Consumatori idipotenti. Quando la consegna viene ripetuta, concentrati sulla chiave dell'evento e su «event _ time» piuttosto che sull'offset nella partitura.
Ordinamento e finestre. Le finestre in 24 ore, ora locale del negozio, calcolano come gli intervalli UTC ottenuti dalle regole locali di una determinata zona a una data specifica.

7) Fogli, tracciati, metriche

Standard di timesone unico: tutti i fogli tecnici e le metriche in UTC (con «Z»). La visualizzazione nei dashboard è localizzata per l'utente.
Traccia: passa «trace _ start _ utc», «duration _ ms» su un orologio monotonico. Non sottragga mai i minutaggi.
Report aziendali: formare «24 ore» in un'area di dominio (ad esempio, «Europe/Paris» per l'imposta francese) anziché in base a UTC. Documentate chiaramente.

8) Profili e contenuti personalizzati

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
Entità multisone: per i comandi/organizzazioni, memorizzare la «zona di dominio» (ad esempio, negozio/giurista) indipendentemente dalla zona personale del partecipante.
Notificazioni: calcola l'orologio silenzioso nella zona utente; invio di shedulite dalla finestra UTC, con protezione DST.

9) Anti-pattern

Conserva solo il tempo locale senza offset o zone.
Chiedi rigidamente di spostare '+ hh: mm', invece dell'ID IANA.
Conta la durata attraverso la differenza tra i due minutaggi.
Pianifica con cron senza supporto zone/DST.
Eseguire l'analisi «giorno per giorno» in UTC quando la normativa richiede una zona locale.
Prevedere che le regole della zona (i paesi cambiano la politica temporale) siano immutate.

10) Test del tempo

Orologio controllato. Immettere l'orologio in codice (Clock/TimeProvider) per i test determinati.

• Passa all'ora estiva/invernale (doppie/passaggi).
• Sposta l'utente tra le zone (cambia preferred _ timezone).
• Modifica delle regole in tzdb (aggiornamento della base - test di regressione).
• Spostamenti NTP, invio eventi in ritardo.
• Test di Fazzi. Zone casuali, date, formati; confronto con la libreria di riferimento.

11) Osservabilità e funzionamento

Alert: disincronizzazione NTP, ritardi di aggiornamento tzdb, picchi di attività cron non completate in DST.
Dashboard: distribuzione degli eventi in zone/giorni locali; contatori catch-up/skip.
Runbook: procedure per cambiare le regole di tempo nella giurisdizione; Ordine di aggiornamento del tzdb; comunicazione con i proprietari degli orari.

12) Modelli di implementazione

Time Normalization Gateway. Un servizio sottile che normalizza i tempi di ingresso alla RFC 3339 UTC, valuta zone (IANA) e un contesto complementare.
Local-Day Builder. Una libreria/servizio che dal «giorno locale» e dalla zona costruisce precisi limiti UTC «[start _ utc, end _ utc)», dato DST.
Schedule Materializer. Un pianificatore che memorizza le regole come espressione locale + zona, materializza le future istanze in UTC e gestisce i conflitti/omissioni.
Dual-Timestamp Events. Eventi con i campi 'occurred _ at _ utc', 'wall _ time _ local',' timezone '. Per l'UI viene installato l'UTC locale, per i sistemi.

13) Assegno-foglia dell'architetto

1. UTC è memorizzato ovunque?
2. Le entità di area IANA e i criteri di data dominio sono disponibili?
3. Il pianificatore comprende DST e materializza le istanze in UTC?
4. Logi/metriche - in UTC; rapporti - nella zona di dominio?
5. Timeout/retrai sull'orologio monotonico?
6. L'aggiornamento tzdb è automatizzato e monitor?
7. I test coprono i cambi di regola, le riprese e i mancati minuti?

14) Mini-ricette (pseudocode)

Conversione del «giorno lavorativo» locale in un intervallo 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)

Materializzazione di una pianificazione ripetuta

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 }

Chiave idipotente di avvio attività

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

15) Sicurezza e conformità

Controllo: memorizza entrambe le proiezioni orarie (UTC e locale) per allineare i reclami personalizzati («mi è stato promesso fino alle 23 di Lima») con la cronologia del server.
Regolazione: i periodi di segnalazione vengono generati nelle zone richieste (tasse, limiti di gioco responsabili, vincoli di marketing orari).
Privacy: fuso orario - impostazioni personali, ma dati non identificativi precisi; elaborare in base alle regole generali sulla privacy.

Conclusione

«Sensibilità al tempo» non riguarda il formato della data, ma i limiti architettonici della responsabilità: dove memorizzare, dove convertire, come pianificare e come dimostrare la correttezza. Unificazione a livello UTC, chiare aree IANA, pianificatori abili, doppi timeline e orologi monotonici trasformano il tempo da fonte di incidenti a prevedibile servizio infrastrutturale.

• GeoDNS e geo-routing Bilanciamento del carico Osservazione degli eventi nel tempo; Cron-pattern e materializzazione degli orari Restrizioni regionali e notifiche locali.