Resposta direta
O fuso precisa ser tratado como campo obrigatório do dado, não como detalhe de formato. A contratação deve declarar o fuso de origem, o fuso de gravação e se o valor chega como horário local com offset ou já convertido para UTC. Essa regra precisa estar escrita e testada em amostra que cruze horário de verão. Sem isso, o dado entra correto e passa a ser lido de formas diferentes por cada área. O custo aparece depois, em relatórios que não fecham e em discussões sobre qual número está certo.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o fuso como cláusula contratual e ponto de teste, não como ajuste técnico feito depois da integração.
O que a origem precisa declarar
Um valor de data e hora só é verificável quando vem acompanhado de três informações: o fuso da origem, o fuso em que foi gravado e o instante absoluto correspondente. Sem essa separação, um horário isolado é apenas texto. A diferença entre horário local com offset e horário já normalizado em UTC precisa estar explícita no layout de troca.
Também importa saber se o sistema de origem guarda o instante ou a intenção. Um agendamento para as 9h em São Paulo é regra de negócio; um registro de log às 9h é evento. Os dois exigem tratamento diferente quando o fuso muda ou quando o horário de verão entra em vigor.
O que o contrato precisa fixar
Quem converte é a decisão central. Se a conversão fica com o fornecedor, o contrato precisa dizer qual fuso de referência ele usa e o que acontece com registros antigos. Se fica com quem recebe, o dado bruto e o offset precisam chegar juntos, sem perda.
Cabe escrever também o comportamento em mudança de fuso, a regra para horários repetidos ou inexistentes no horário de verão e quem responde pelo histórico já entregue. Uma amostra com data no limite da mudança revela mais que qualquer descrição de manual.
Onde a exigência não resolve
Base histórica gravada sem fuso não se recupera por contrato. É possível marcar o que é ambíguo, adotar uma convenção e documentar, mas o instante original pode ter se perdido. Nesses casos, o trabalho é delimitar o alcance da base, não reconstruí-la.
A exigência também não se aplica a dados que não representam instantes: data de competência contábil, vigência de contrato e dia útil são conceitos de calendário, não de relógio. Impor UTC nesses campos cria erro novo. A cláusula boa não garante consistência futura; ela torna a divergência visível e atribuível.
Recurso prático
Verificação da fonte temporal antes da assinatura
- Listar os campos de data e hora do layout e separar os que representam instante dos que representam calendário.
- Pedir ao fornecedor o fuso de origem, o fuso de gravação e o formato do offset em cada campo.
- Solicitar amostra com data no limite de mudança de horário de verão e conferir a conversão recebida.
- Definir por escrito quem converte, com qual referência, e o que ocorre com o histórico já entregue.
- Registrar no contrato a responsabilidade pela correção e o critério de aceite da entrega.
O erro mais comum é aceitar a informação de que o sistema já usa UTC sem verificar o histórico: a regra nova costuma valer apenas para registros criados depois da mudança.
Sobre o que está escrito aqui
Conceitos relacionados: fuso horário · offset UTC · horário de verão · timestamp · contrato de dados. 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
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
- Cadastros duplicados: como descobrir e consol… — 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: 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
Outras leituras em Integrações, sistemas e qualidade de dados
- Integração sem documentação: o que comparar antes de mexer — Compara quatro caminhos para uma integração sem documentação e indica o que observar em cada um: dependências, teste, responsável e custo de erro.
- Integração por API: o que definir antes de ir para produção — O que precisa estar definido antes de uma API entrar em produção: contrato de dados, comportamento em falha, reprocessamento e responsável pela integração.
- Base de teste diferente da produção: o que padronizar — Define o que a base de teste precisa reproduzir da produção, quem responde por mantê-la e quando ela deixa de servir para validar.
- APIs sem dono: como definir responsabilidade e contrato — O que registrar para cada API em uso: operação dependente, área responsável, contrato de dados e versão, além do combinado para descontinuar.
- Arquitetura de integração: o que comparar antes de decidir — A página compara arquiteturas de integração por onde mora a regra, quem responde pelo dado, reversibilidade e custo de mudança ao longo do tempo.