Resposta direta
Horário sem fuso é leitura de relógio local, não um instante. A implementação se apoia em três decisões: gravar o instante em UTC, preservar o offset e o fuso de origem no próprio registro, e manter a regra de conversão versionada. Sem isso, o mesmo dado muda de significado quando o horário de verão muda ou quando outro sistema lê a base em fuso diferente. Onde o offset de origem não existe, o registro não pode ser convertido com segurança: ele fica marcado como não resolvido, com responsável e critério definidos, em vez de receber um fuso suposto.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o campo temporal isolado: como declarar o fuso, preservar o offset de origem e o que fazer quando o passado não pode mais ser convertido.
O que o valor sem fuso afirma sobre o registro
Um campo que guarda 14/03 09:15 diz apenas que o relógio de algum lugar marcava nove e quinze. Não diz se esse relógio estava em São Paulo, em Lisboa ou em um servidor ajustado em UTC. A distância entre essas leituras é de horas e aparece em prazo, em janela de atendimento e na ordem dos eventos.
O problema não está no formato, está na ausência de declaração. Dois sistemas podem gravar o mesmo fato com valores diferentes e ambos estarem corretos na leitura local. A conciliação falha porque compara texto, não instante.
Declaração de fuso no desenho do campo
O desenho mínimo tem três partes: o instante em UTC, o offset vigente no momento do fato e o identificador do fuso de origem. O offset sozinho não reconstrói regras futuras, e o identificador sozinho não resolve registros antigos cujo offset mudou. Guardar os dois evita depender da tabela de conversão atual para interpretar o passado.
A regra vale por campo, não por sistema. Um cadastro pode ter data de nascimento, que é data civil sem hora, e data de criação do registro, que é instante. Tratar os dois com o mesmo tipo produz erro silencioso. A definição de qual é qual precisa estar escrita e ter responsável nomeado, porque corrigir um campo mal classificado custa mais que a definição inicial.
O que a conversão não recupera
Converter para UTC não corrige a regra de negócio que gerou o horário. Se o sistema registrou o encerramento no fuso do servidor por engano, o valor em UTC será consistente e ainda assim errado. Consistência técnica não substitui a conferência contra o documento de origem.
Também não há conversão segura quando o offset de origem se perdeu e o período atravessa mudança de horário de verão: a hora local fica ambígua ou inexistente. Nesses casos o dado permanece não resolvido, e o custo aceito é registrar a lacuna com critério. Há situações em que a abordagem não se aplica: eventos recorrentes em hora local, como um fechamento diário às 18h, são regra de calendário, não instante, e devem ficar como hora local com fuso declarado.
Recurso prático
Reconstrução do instante a partir de hora local e offset
instante_utc = hora_local − offset_origem; status_conversao fica ambíguo quando a hora local ocorre duas vezes ou nenhuma vez na transição de horário de verão
- hora_local
- data e hora sem fuso
- valor exatamente como gravado no sistema de origem, sem indicação de fuso
- offset_origem
- horas e minutos
- diferença entre a hora local e UTC vigente no momento do fato, com sinal
- instante_utc
- data e hora em UTC
- instante resultante, gravado em formato que declara o fuso
- status_conversao
- resolvido ou ambíguo
- marca se a hora local existe uma única vez naquele dia; horários repetidos ou inexistentes ficam como não resolvidos
O erro mais comum é aplicar o offset atual a registros antigos. A regra de horário de verão muda por decisão administrativa, então o offset precisa vir do momento do fato, não da tabela carregada hoje.
Sobre o que está escrito aqui
Conceitos relacionados: timestamp sem fuso · offset UTC · horário de verão · fuso de origem · registro 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
- Números que não batem: por que a divergência… — planilhas divergentes
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
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: 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: o que exigir no contrato — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Correção feita em um sistema: como medir se chegou ao outro — Medição da correção de cadastro entre dois sistemas: lote de auditoria, conferência por campo, prazo acordado e responsável pela divergência que sobra.
- Dado sem histórico de origem: o que a comparação pode afirmar — Compara as formas de confrontar dados sem rastro de origem: o que cada uma sustenta, o que custa e o que permanece indeterminado.
- Tempo de resposta do sistema: quatro arranjos de processo — Compara arranjos para absorver a espera do sistema no processo: mudar a ordem das etapas, criar fila, sobrepor tarefas ou reduzir a dependência.
- Campo obrigatório sem uso: manter, remover ou treinar — O que verificar quando um campo obrigatório é criado e ninguém preenche: origem, responsável, uso real e critério para manter, remover ou treinar.
- Sincronização sem janela: comparar cadências antes de decidir — Compara cadências de sincronização — contínua, lote curto, diário e sob demanda — pelo uso do dado, exigência operacional e risco assumido.