Resposta direta
Comparar horário sem fuso exige primeiro decidir o que o campo representa. O mesmo valor pode ser hora local do evento, hora do servidor que gravou ou UTC sem marcação. Sem essa definição, qualquer junção entre bases produz intervalos errados, e o erro muda de tamanho no horário de verão. As alternativas usuais são preservar a hora local com fuso explícito em campo separado, converter para UTC na entrada ou manter o valor original e tratar a conversão na consulta. A escolha se compara por reversibilidade, rastro de auditoria e custo de correção, não por preferência técnica.
- Objetivo
- Comparar alternativas
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Compara as alternativas de tratamento do horário sem fuso pelo custo operacional de cada uma, não pela conversão em si.
Três origens possíveis para o mesmo valor
Um campo de data e hora sem fuso admite pelo menos três leituras: hora local de quem gerou o registro, hora do servidor que gravou ou UTC sem indicação. As três produzem o mesmo texto e resultados diferentes em qualquer conta de intervalo.
O efeito aparece quando duas bases se encontram. Um pedido gravado às 23h40 pode pertencer ao dia anterior ou ao seguinte, dependendo da origem. Relatórios diários, janelas de prazo e ordem de eventos passam a depender de suposição, não de dado.
O que comparar entre as alternativas
Preservar a hora local e gravar o fuso em campo separado mantém o valor original legível e permite reconstruir a conversão. Converter para UTC na entrada simplifica a comparação, mas apaga a hora local se o original não for guardado. Manter o valor bruto e converter na consulta distribui a regra por cada relatório.
Os critérios de comparação são reversibilidade, existência de rastro de auditoria, custo de corrigir registros antigos, comportamento na mudança de horário de verão e quantidade de pontos do sistema que precisam aplicar a mesma regra. O caminho com menos pontos de conversão tende a envelhecer melhor.
O que a escolha não resolve
A escolha não recupera a informação que nunca foi gravada. Base histórica sem metadado de origem continua ambígua, e a conversão apenas formaliza uma suposição. Também não corrige regras de fuso alteradas depois do registro nem atende exigência contratual de manter a hora local do evento.
Quando o campo alimenta obrigação legal, faturamento ou registro de jornada, a hora local original costuma ser o dado exigido. Nesses casos, a alternativa mais simples tecnicamente pode ser a errada. A decisão precisa ficar por tipo de evento, com dono definido e registro da hipótese adotada.
Recurso prático
Roteiro para escolher o tratamento de um campo temporal sem fuso
- Listar cada campo de data e hora, o sistema que o grava e o que ele alimenta em relatório, contrato ou cálculo de prazo.
- Classificar o campo em uma das três origens prováveis e separar o que é fato do que é suposição.
- Testar as alternativas em uma janela que contenha mudança de horário de verão e comparar a ordem dos eventos e os totais diários.
- Medir o custo de correção: quantos registros teriam de ser reescritos e quantos relatórios aplicariam a mesma regra.
- Registrar a decisão, o dono do campo e a data da última revisão junto ao dicionário de dados.
O erro mais comum é converter tudo para UTC sem guardar a hora local original. Isso resolve a comparação e cria um problema novo quando alguém precisa provar o horário que constava no documento.
Conceitos usados nesta página
- Trilha de auditoria — Trilha de auditoria é o conjunto de registros que permite reconstruir quem fez o quê, quando e com qual dado — inclusive depois que o resultado já foi usado.
Sobre o que está escrito aqui
Conceitos relacionados: timestamp sem fuso · horário de verão · UTC · fuso do servidor · trilha de auditoria. 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
- Cadastros duplicados: como medir o volume real — cadastros duplicados
- Cadastros duplicados: o que exigir na contrat… — cadastros duplicados
Páginas relacionadas
O mesmo problema em outro objetivo
- Horário sem fuso: o dado que muda de dia ao ser lido — Diagnosticar
- Horário sem fuso: como fixar a referência antes de comparar — Organizar um processo
- 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
- Dado sensível em planilha compartilhada: comparar opções — Compara as formas de trabalhar com dado sensível em planilha compartilhada, do controle de acesso à responsabilidade sobre a cópia.
- Correção direta no banco de produção: o que medir — Medição de correções feitas direto no banco de produção: registro mínimo, contagem, reincidência e o que o número não mostra.
- Alteração sem registro: o que ainda dá para reconstruir — O que ainda pode ser reconstruído quando a alteração não foi registrada: fontes de rastro, limites da reconstrução e o que registrar daqui em diante.
- Log de integração sem nível de erro: o que exigir no contrato — Contrato de log de integração: níveis de severidade, campos obrigatórios, retenção, responsabilidade e teste de aceite com falha provocada.
- Registro excluído sem trilha: o que reconstruir depois — Processo para lidar com exclusão sem histórico: o que reconstruir, quem responde e quais cadastros passam a exigir trilha.