Manter o horário do sistema correto não é tão simples quanto parece
A maioria das pessoas não liga para o relógio do computador até receber um erro de certificado TLS ou falhar uma sincronização de backup. Quando isso acontece, o problema já está instalado há semanas. O serviço que cuida disso se chama hora actualizada, mas o nome enganoso faz muita gente acreditar que é um app móvel ou algo que você baixa e pronto. Não é. É um conceito de infraestrutura que envolve NTP, configuração de fuso horário e, em alguns casos, ferramentas específicas de cada sistema operacional.
O que você realmente precisa saber sobre hora actualizada
Em sistemas Linux, a hora actualizada depende do systemd-timesyncd ou do NTP tradicional. No Windows, é o Windows Time Service (w32time). Ambos se conectam a servidores de tempo por padrão, mas a configuração padrão nem sempre é a ideal. Por exemplo, em redes com DNS bloqueado ou com restrições de saída, os servidores padrão podem não responder. Já vi isso acontecer em data centers na América do Sul onde os pools da Microsoft e do NTP Project tinham latência acima de 300ms, o que causava deriva de tempo de vários segundos por dia. A solução prática nesses casos é apontar para servidores regionais. No Brasil, o redecomp.cpe.gov.br costuma ser estável. Em Portugal, os servidores do INESC-ID funcionam bem. Você configura isso editando o arquivo de configuração e rodando um flush. No Linux com systemd, o comando é algo como timedatectl set-ntp true seguido de timedatectl set-timezone America/Sao_Paulo. No Windows, é wmimgmt ou gpedit para definir os stratum servers diretamente no registro.
Como configurar na prática
Vamos começar pelo Linux porque é onde mais gente estraga. Primeiro, verifique se o serviço está rodando com systemctl status systemd-timesyncd. Se estiver ativo, tudo certo. Se não estiver, habilite com systemctl enable --now systemd-timesyncd. Depois, edite /etc/systemd/timesyncd.conf e adicione os servidores que funcionam na sua rede dentro da seção [Time]. Por exemplo: NTP=redecomp.cpe.gov.br pt.pool.ntp.org
FallbackNTP=pt.ubuntu.pool.ntp.org
Salve e reinicie o serviço. Para forçar uma sincronização imediata, use systemd-timesyncd-resync.service ou simplesmente reinicie o daemon. Verifique com timedatectl status que o sistema está sincronizado e qual o offset atual. Se o offset for maior que 50ms, algo não está certo e você precisa investigar a rede. No Windows, abra o PowerShell como administrador e rode w32tm /query /status para ver quem é o source atual. Se aparecer Something_went_wrong, o serviço está desconfigurado. O comando w32tm /config /syncfromflags:manual /manualpeerlist:"pt.pool.ntp.org" resolve na maioria das vezes. Depois disso, w32tm /resync aplica a mudança. Reiniciar o serviço com net stop w32time && net start w32time ajuda a limpar estados corrompidos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Problemas que ninguém conta
Uma das coisas mais chatas é a deriva de tempo em máquinas virtuais. Hipervisores como VMware e Hyper-V sincronizam o clock da VM com o host periodicamente, o que pode causar saltos de vários segundos se o host estiver com hora errada ou se a carga da CPU for alta. Já perdi dias rastreando falhas em backups agendados que só aconteciam porque a VM havia sofrido um jump de tempo após uma migração live. A correção é desativar a sincronização de hora do hipervisor e deixar o guest confiar apenas no NTP externo. No VMware, isso é feito editando o .vmx e adicionando vmxmitigate.clockadj = "OFF". No Hyper-V, desative o serviço de integração de tempo ou use o registry key DisableSyncFromParent. Outro problema silencioso é o horário de verão. Muitos sistemas herdam a política do fuso horário e atualizam automaticamente, mas se você definiu o timezone manualmente sem respeitar as regras do IANA, o sistema pode não aplicar a mudança. Configure sempre usando os nomes da zona IANA, como America/Sao_Paulo, nunca offsets fixos como UTC-3. Offset fixo quebra quando o horário de verão entra em vigor.
Se você trabalha com containers Docker, saiba que eles herdam o clock do host. Isso significa que se o host tiver deriva, todos os containers terão o mesmo problema. Não adianta configurar NTP dentro do container. A correção deve ser feita no host. Eu descobri isso depois de um container PostgreSQL reclamar de transações entre nós com diferença de 12 segundos, o que corrompeu logs de replicação.
Quando hora actualizada não resolve
Existem cenários onde sincronizar a hora do sistema simplesmente não funciona. Sensores industriais com clocks de cristal de baixa qualidade derivam dezenas de segundos por dia mesmo com NTP configurado. Nesse caso, a solução é hardware com oscilador de temperatura compensada (TCXO) ou usar protocolos como PTP (Precision Time Protocol) que oferecem precisão na casa dos microssegundos. Para a maioria das pessoas isso é overkill, mas se você opera uma plataforma de trading ou log distribuído, a diferença entre NTP e PTP é a diferença entre dados confiáveis e dados inutilizáveis. Sistemas embarcados sem conexão de rede também são um problema. Se o dispositivo não tem como alcançar um servidor NTP, a hora só pode ser ajustada manualmente ou via bootloader que leia RTC externo. Ferramentas como chronyd com modo offline ajudam um pouco, mas a precisão nunca será boa sem uma referência externa.
Verificação rápida
Antes de qualquer coisa, confirme se o problema é realmente de horário. Em vez de assumir, rode date ou w32tm /query /status para ver o estado atual. Compare com um telefone ou site como time.gov. Se a diferença for menor que 1 segundo, o sistema está razoavelmente ok e o problema provavelmente é outra coisa. Se for maior que 5 segundos, aí sim foca na correção da hora actualizada. Corrigir o horário depois que serviços já estavam rodando com tempo errado pode causar problemas maiores, como certificados TLS com datas inválidas que precisam ser renovados manualmente.
