Resposta direta
Dado temporal sem fuso não é dado errado; é dado incompleto. Ele registra um instante sem dizer a que referência esse instante pertence, e cada sistema que o lê aplica a convenção que tem. O diagnóstico consiste em localizar onde o campo é gerado, qual relógio o preenche e em que ponto a conversão acontece. Só depois disso faz sentido escolher uma referência única e reescrever o histórico. Sem esse levantamento, a correção vira ajuste de tela: o valor armazenado continua ambíguo e a divergência retorna no próximo relatório.
- Objetivo
- Diagnosticar
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Separa o instante da referência e inclui origem do relógio e horário de verão no diagnóstico, em vez de tratar o fuso como ajuste de exibição.
O que o campo declara e o que ele omite
Um campo de data e hora carrega duas informações distintas: o instante e a referência usada para localizá-lo. Quando a segunda não está no registro, ela fica implícita no sistema que gravou, no fuso do servidor ou no navegador de quem digitou. O campo parece completo porque exibe um valor plausível.
A primeira verificação é de forma, não de conteúdo. Valores com deslocamento explícito, textos livres no formato local e números de época sem unidade declarada exigem tratamentos diferentes. Misturá-los na mesma coluna é o que produz a divergência que aparece depois, na comparação entre relatórios.
Inspeção da origem antes de qualquer conversão
A origem define o significado. Vale registrar, para cada tabela e cada integração, qual processo escreve o campo, de qual relógio ele lê e se existe conversão no caminho. Um campo preenchido pelo usuário em horário local e outro gerado por servidor em UTC podem ter o mesmo nome e comportamentos opostos.
O histórico precisa do mesmo cuidado. Registros antigos podem ter sido gravados sob outra convenção, inclusive durante vigência de horário de verão. Comparar duas datas sem saber a regra vigente na época produz conclusão falsa. O que se mede aqui é a quantidade de registros cuja origem não pode ser determinada, não a diferença entre relatórios.
O que a padronização não resolve
Adotar uma referência única corrige o armazenamento, não o significado do que já foi registrado. Se a origem de um lançamento é desconhecida, convertê-lo cria precisão aparente sem eliminar a dúvida. Nesses casos, o correto é marcar o registro como incerto e definir quem responde por ele.
Também não se recupera a granularidade perdida. Um campo que guarda apenas a data não devolve a hora, e um registro sem fuso que atravessou horário de verão pode ter ocorrido duas vezes no mesmo horário local. A padronização não garante que dois eventos distintos voltem a ser distinguíveis; ela apenas impede que novos erros sejam gravados.
Recurso prático
Perguntas de inspeção para um campo temporal sem fuso
| Pergunta de inspeção | O que ela revela |
|---|---|
| O valor traz deslocamento explícito ou apenas a data e a hora locais? | Separa registro com referência de texto livre, que herda a convenção de quem digitou. |
| Quem escreve o campo: o dispositivo, o servidor ou o usuário? | Indica de qual relógio vem o valor e onde existe conversão silenciosa no caminho. |
| O histórico atravessa período de horário de verão? | Mostra registros repetidos ou ausentes na virada, típicos de horário local sem referência. |
O erro mais comum é comparar o horário exibido em duas telas sem conferir a conversão feita na apresentação. O valor gravado pode estar correto e a leitura, não.
Sobre o que está escrito aqui
Conceitos relacionados: timestamp sem fuso · UTC · horário de verão · relógio do servidor · campo de data e hora. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Sistemas isolados: o que checar antes de comp… — sistemas desconectados
- Planilhas divergentes: como unificar a base d… — planilhas divergentes
Páginas relacionadas
O mesmo problema em outro objetivo
- Horário sem fuso: como fixar a referência antes de comparar — Organizar um processo
- Horário sem fuso: como comparar registros entre sistemas — Comparar alternativas
- Horário sem fuso: o que medir antes de comparar — Explicar medição
- Data e hora sem fuso: onde o registro perde sentido — Orientar implementação
- Data e hora sem fuso: o que exigir no contrato — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Campo numérico aceitando texto: o que fazer com o registro — Regra de tratamento para registros com texto em campo numérico: o que corrigir na hora, o que separar para conferência e quem responde pela decisão.
- Migração em curso: o que decidir antes de desligar o antigo — A organização de uma migração em etapas: sequência, donos de decisão, janela de congelamento e critério para desligar o sistema antigo.
- Planilhas divergentes: alternativas para confrontar bases — Avaliação de quatro métodos práticos para comparar arquivos concorrentes, apontando esforço, precisão e limites de cada abordagem operacional.
- Campo com formatos diferentes: onde normalizar — Onde normalizar um campo preenchido de formas diferentes: comparar tratamento na gravação e na leitura, definir responsável e critério de aceitação.
- Data em formato livre: como dizer se o campo é confiável — Distingue data digitada à mão de data de sistema, o que um campo livre impede medir e quando padronizar não compensa.