Risorse · 82
Report affidabili: fusi orari, chiusure ed eventi tardivi
Evitare giorni spostati, doppi conteggi e confronti incoerenti fra esportazioni e dashboard.
Aggiornato · 3 min
Obiettivi di questa guida
- Distinguere istanti e giorni aziendali
- Fissare i confini
- Gestire gli arrivi tardivi
- Confrontare perimetri uguali
- Provare la ricostruzione
Verifica rapida
- Basta convertire tutto in UTC?
- Perché il totale cambia dopo l’export?
- Un evento tardivo è un duplicato?
Metodo passo passo
- 1
Distinguere istanti e giorni aziendali
Separare evento, ricezione, modifica e data di attività. UTC non definisce da solo il giorno di un negozio. PostgreSQL converte timestamp with time zone in UTC senza conservare il nome del fuso originario: registrarlo separatamente quando necessario.
Risultato: dizionario delle date e dei fusi.
- 2
Fissare i confini
Usare inizio incluso e fine esclusa. Calcolare i limiti nel fuso aziendale prima della conversione. Testare ora legale, fine mese e date prive di orario; un giorno locale non dura sempre ventiquattro ore.
Risultato: casi di assegnazione ai periodi.
- 3
Gestire gli arrivi tardivi
Definire quali report possono cambiare e fino a quando. Conservare ricezione e identificatori per distinguere ritardo e duplicato. Una versione già distribuita richiede una revisione datata o una correzione esplicita.
Risultato: politica delle revisioni.
- 4
Confrontare perimetri uguali
Allineare periodi, stati aziendali e chiusure. Separare ordini creati, pagati, annullati e rimborsati. Esaminare i record vicini al confine del giorno prima di concludere che la raccolta ha perso dati.
Risultato: riconciliazione dei record discordanti.
- 5
Provare la ricostruzione
Ripetere un intervallo con cambio d’ora ed eventi tardivi. Spiegare ogni differenza a parità di chiusura. Mostrare fuso, aggiornamento e stato provvisorio o chiuso accanto ai risultati.
Risultato: test riproducibile e legenda.
Foglio di lavoro riutilizzabile
Completare con le proprie osservazioni autorizzate. Questi campi costituiscono un modello di lavoro, non risultati osservati.
| Campo | Informazioni da registrare |
|---|---|
| Calendario | Fuso, inizio settimana e limiti |
| Orari | Evento, ricezione, modifica e precisione |
| Chiusura | Snapshot, finestra di revisione e ritardi |
| Confronto | Stati, identificatori e differenze spiegate |
Esempio pratico fittizio
Situazione illustrativa
Esempio fittizio: due team confrontano vendite del lunedì usando UTC e Europe/Paris.
Decisione e prove attese
La verifica individua ordini al confine del giorno e adotta periodo aziendale e chiusura comuni.
Distinguere i meccanismi
| Meccanismo | Scopo | Verifica o limitazione |
|---|---|---|
| Data aziendale | Assegna attività a un calendario | Non è un istante senza convenzione |
| Ora dell’evento | Misura quando avviene l’attività | Può arrivare in ritardo |
| Ora di ricezione | Descrive freschezza della pipeline | Non coincide necessariamente con l’attività |
Indicatori di gestione
| Indicatore | Cosa misura | Prima azione |
|---|---|---|
| Ritardo di ricezione | Tempo fino alla disponibilità | Definire la finestra provvisoria |
| Revisioni | Variazioni fra versioni confrontabili | Separare ritardi e correzioni |
| Scarti al confine | Record assegnati a giorni diversi | Correggere la convenzione |
Errori comuni
- Non è un istante senza convenzione
- Può arrivare in ritardo
- Non coincide necessariamente con l’attività
Domande frequenti
Basta convertire tutto in UTC?
No. Giorni, settimane e chiusure richiedono comunque calendario e fuso aziendale.
Perché il totale cambia dopo l’export?
Possono arrivare eventi, correzioni o nuovi stati. Verificare chiusura e politica di revisione.
Un evento tardivo è un duplicato?
No. Confrontare identificatore e contenuto; il ritardo non dimostra ripetizione.
Riferimenti ufficiali
I riferimenti supportano il metodo. Adattare i controlli al proprio contesto; non costituiscono una certificazione. I titoli dei riferimenti originali e i documenti di origine potrebbero essere in un'altra lingua.
Riferimenti consultati il .
