Fim do segundo bissexto: o que muda para servidores, NTP e logs

A Conferência Geral de Pesos e Medidas (CGPM) aprovou, em 15 de outubro de 2026, em Versalhes, a resolução que acaba com os segundos bissextos no Tempo Universal Coordenado (UTC). Pelo texto, o UTC passa a ser uma escala contínua a partir de 20 de maio de 2027, e a diferença tolerada entre o relógio atômico e a rotação da Terra sobe para até 3.600 segundos, ou seja, uma hora.

Para quem cuida de servidores, a decisão aposenta o minuto de 61 segundos (o famoso 23:59:60), um evento raro que já derrubou serviços grandes. O Bureau Internacional de Pesos e Medidas (BIPM), que produz o UTC, registrou no próprio texto o motivo da pressa: a chance de um segundo bissexto negativo, que nunca foi aplicado e para o qual quase nenhum sistema está preparado, chegaria a 30% até 2035.

Como o UTC se comportava e como fica a partir de 20 de maio de 2027

A Resolução 5 da 28ª CGPM não muda a duração do segundo nem a forma de produzir o UTC. Ela muda a regra de ajuste. Até agora, sempre que a rotação da Terra (medida pela escala UT1) se afastava do UTC perto de 0,9 segundo, o Serviço Internacional de Rotação da Terra (IERS) anunciava um segundo extra no fim de junho ou de dezembro. Com o novo limite de uma hora, os ajustes param por vários séculos, segundo o BIPM.

Há um detalhe que poucos textos deram. O Boletim C número 72 do IERS, distribuído em julho de 2026 aos mantenedores da base de fusos horários (tz), já confirmou que não haverá segundo extra no fim de dezembro de 2026. A janela seguinte seria o fim de junho de 2027, depois da data em que o UTC contínuo entra em vigor. Na prática, o ajuste de 31 de dezembro de 2016 fica como o último da história.

Por que um segundo a mais custava tão caro

O problema nunca foi o segundo em si, e sim o fato de ele quebrar premissas escritas no código. Em 30 de junho de 2012, a inserção travou máquinas Linux por causa de um defeito no tratamento de temporizadores do kernel, com CPUs presas em 100%, e tirou sites como o Reddit do ar por dezenas de minutos. No réveillon de 2017, o DNS da Cloudflare falhou em parte das consultas porque um cálculo de tempo de resposta em Go ficou negativo quando o relógio voltou um segundo.

Para fugir desse degrau, provedores grandes passaram a “espalhar” o segundo extra ao longo de horas, a técnica chamada leap smearing. O Google, por exemplo, usa uma janela linear de 24 horas. O efeito colateral aparece no próprio texto da resolução: métodos diferentes entre provedores deixavam servidores discordando entre si durante o ajuste e distribuindo um horário fora do padrão do Sistema Internacional.

Seu NTP, seus bancos de dados e seus logs depois da mudança

Para a maioria das aplicações, nada precisa ser feito com urgência, porque o sistema operacional segue o NTP e a hora continua andando no mesmo ritmo. O que muda é que alguns mecanismos ficam ociosos:

1. Campo de aviso do NTP: o pacote NTP tem dois bits (Leap Indicator) para avisar que haverá segundo extra. Sem novos ajustes, eles deixam de ser acionados.
2. Arquivos de segundos bissextos: o leap-seconds.list, usado pelo ntpd (diretiva leapfile) e por outras ferramentas, deixa de ganhar linhas novas. Vale checar se o seu monitoramento não alerta pela data de validade do arquivo.
3. Misturar fontes: a orientação de não combinar servidores NTP que espalham o segundo com servidores que não espalham perde o sentido para eventos futuros.

Preciso mexer no chrony ou no ntpd antes de maio de 2027?

Não. No chrony, opções como leapsecmode e smoothtime simplesmente deixam de ter evento para tratar. Não há ganho em removê-las às pressas: o mais seguro é limpar essas linhas numa manutenção programada depois de 20 de maio de 2027, junto com a atualização da documentação interna.

No código, a mudança tende a ser silenciosa. O time_t do POSIX já tratava todo dia como tendo exatos 86.400 segundos, e o datetime do Python sempre recusou o segundo 60. Se a sua equipe está migrando para o Python 3.15, aproveite a rodada de testes para procurar validações manuais de horário e tratamentos especiais para 23:59:60 que podem virar código morto. Em logs, a vantagem é concreta: correlação de eventos entre sistemas deixa de ter o risco de um minuto duplicado ou de durações negativas.

Quem escapa da mudança e quem ainda precisa revisar sistemas

Quem só consome horário via NTP escapa. Quem depende da diferença entre UT1 e UTC, não. A própria resolução reconhece que algumas aplicações precisam de um limite máximo fixo para projetar software, e é por isso que ele foi definido em uma hora. Os grupos que devem revisar premissas são estes:

• Software de astronomia, rastreamento de satélites e apontamento de antenas que trata UTC como aproximação da rotação da Terra sem corrigir pela diferença DUT1.
• Equipamentos que recebem horário por rádio e decodificam a diferença UT1-UTC no formato atual, limitado a menos de um segundo.
• Sistemas que tratam o tempo GPS ou o TAI e convertem para UTC usando tabelas de ajustes: elas param de crescer, mas o código precisa aceitar isso sem erro.

Pontos que o BIPM, o IERS e a UIT ainda vão definir

A decisão fixa a data e o limite, mas deixa trabalho operacional em aberto. A União Internacional de Telecomunicações (UIT), por meio do grupo de trabalho 7A, ainda estuda como atualizar o código que transmite a diferença UT1-UTC por estações de rádio. A Resolução 655 da conferência de radiocomunicações de 2023 prevê um período de transição para equipamentos que não puderem ser trocados antes, até 2035, e não depois de 2040. O IERS também precisa mudar a forma como faz e divulga seus anúncios, e o BIPM ficou encarregado de acompanhar a evolução da diferença UT1-UTC e informar o Comitê Internacional de Pesos e Medidas, conforme a lista de resoluções adotadas pela 28ª CGPM. O que fazer quando a diferença acumulada se aproximar de uma hora, daqui a séculos, não foi decidido.