Datas e fusos horários: o bug que aparece às 21h

Um dos bugs mais clássicos de sistemas brasileiros aparece à noite: depois das 21h, horário de Brasília, já é o dia seguinte em UTC. Pedidos, agendamentos e relatórios começam a aparecer na data errada — e ninguém entende por quê.

A regra de ouro

Guarde em UTC, exiba no fuso do usuário. O banco registra o instante exato; a conversão para o horário local acontece só na exibição.

Erros comuns

1. 1.Guardar datas como texto ("10/05/2026 22:30") sem fuso.
2. 2.Converter duas vezes: no servidor e no navegador.
3. 3.Filtrar "pedidos de hoje" usando o início do dia em UTC, não em Brasília.
4. 4.Datas sem hora (aniversários, vencimentos) tratadas como instantes — um vencimento em 10/05 vira 09/05 às 21h.
5. 5.Servidor configurado num fuso e banco em outro.

Na prática

• Formato ISO 8601 com fuso em APIs: 2026-05-10T01:30:00Z (API REST bem desenhada: nomes, status codes e paginação que não confundem ninguém).
• Intl.DateTimeFormat no front, com o fuso explícito quando necessário.
• Para datas "de calendário", guarde só a data, sem horário.
• Relatórios por dia calculados no fuso do negócio.

Testes

Inclua casos perto da meia-noite e em fusos diferentes nos testes automatizados (Testes automatizados de API: o mínimo que evita desastres).

Agendamentos

Sistemas de agenda são os mais sensíveis — um horário errado significa um paciente na porta da clínica fechada (Software para clínicas: agenda, confirmação automática e menos faltas).

A We Codex constrói sistemas com dados confiáveis. Veja sistemas web ou fale com a gente.