Recursos · 82
Relatórios fiáveis: fusos horários, fechos e eventos tardios
Evitar dias deslocados, contagens duplicadas e comparações incoerentes entre exportações e painéis.
Atualizado · 3 min
O que este guia ajuda a alcançar
- Distinguir instantes e dias de negócio
- Definir limites
- Tratar chegadas tardias
- Comparar âmbitos equivalentes
- Testar reconstrução
Verificação rápida
- Converter tudo para UTC basta?
- Porque muda o total após exportar?
- Um evento tardio é duplicado?
Método passo a passo
- 1
Distinguir instantes e dias de negócio
Separar evento, receção, alteração e data de atividade. UTC não define sozinho o dia comercial de uma loja. PostgreSQL converte timestamp with time zone para UTC sem guardar o nome do fuso original; conservá-lo separadamente quando necessário.
Resultado: dicionário de datas e fusos.
- 2
Definir limites
Usar início incluído e fim excluído. Calcular limites no fuso de negócio antes de converter. Testar horário de verão, fim do mês e datas sem hora; um dia local nem sempre tem vinte e quatro horas.
Resultado: casos de atribuição a períodos.
- 3
Tratar chegadas tardias
Definir que relatórios podem mudar e até quando. Guardar receção e identificadores para distinguir atraso de duplicado. Uma versão distribuída exige revisão datada ou correção explícita.
Resultado: política de revisão.
- 4
Comparar âmbitos equivalentes
Alinhar períodos, estados de negócio e fechos. Separar encomendas criadas, pagas, canceladas e reembolsadas. Examinar registos próximos dos limites antes de concluir que a recolha perdeu dados.
Resultado: reconciliação de discrepâncias por registo.
- 5
Testar reconstrução
Repetir um intervalo com mudança de hora e eventos tardios. Explicar diferenças num fecho igual. Mostrar fuso, atualização e estado provisório ou fechado junto dos resultados.
Resultado: teste reproduzível e legenda.
Planilha reutilizável
Preencha com suas observações autorizadas. Estes campos são um modelo de trabalho, não resultados observados.
| Campo | Informações a serem registradas |
|---|---|
| Calendário | Fuso, início da semana e limites |
| Tempos | Evento, receção, alteração e precisão |
| Fecho | Snapshot, revisão e tratamento dos atrasos |
| Reconciliação | Estados, identificadores e diferenças explicadas |
Exemplo prático fictício
Situação ilustrativa
Exemplo fictício: duas equipas comparam vendas de segunda-feira usando UTC e Europe/Paris.
Decisão e evidências esperadas
A reconciliação identifica encomendas no limite do dia e fixa um período de negócio e um fecho comuns.
Distinguir os mecanismos
| Mecanismo | Finalidade | Verificação ou limitação |
|---|---|---|
| Data de negócio | Atribui atividade a um calendário | Não é um instante sem convenção |
| Hora do evento | Indica quando ocorreu a atividade | Pode chegar tarde |
| Hora de receção | Mostra atualização da pipeline | Não é necessariamente a data da atividade |
Indicadores de gestão
| Indicador | O que mede | Primeira ação |
|---|---|---|
| Atraso de receção | Tempo até à disponibilidade | Definir janela provisória |
| Revisões | Variações entre versões comparáveis | Separar atrasos de correções |
| Diferenças nos limites | Registos atribuídos a dias distintos | Corrigir a convenção temporal |
Erros comuns
- Não é um instante sem convenção
- Pode chegar tarde
- Não é necessariamente a data da atividade
Perguntas frequentes
Converter tudo para UTC basta?
Não. Dias, semanas e fechos continuam a exigir calendário e fuso de negócio.
Porque muda o total após exportar?
Podem entrar eventos, correções ou novos estados. Verificar fecho e política de revisão.
Um evento tardio é duplicado?
Não. Comparar identificador e conteúdo; o atraso não demonstra repetição.
Referências oficiais
As referências apoiam o método. Adapte as verificações ao seu contexto; elas não são uma certificação. Os títulos das referências originais e os documentos de origem podem estar em outro idioma.
Referências consultadas em .
