Segundo bissexto: o ajuste que travou a internet em 2012
Às 21h59min59s do dia 30 de junho de 2012 (horário de Brasília), os relógios do mundo pararam por um instante — de propósito. Foi inserido um segundo bissexto, um “23:59:60” que a maioria dos softwares nunca tinha visto. O resultado: Reddit saiu do ar, LinkedIn, Yelp, StumbleUpon e Foursquare engasgaram, e aplicações Java baseadas em Hadoop e Elasticsearch travaram em loop de CPU a 100%.
Por que existe um segundo a mais
A Terra não gira em velocidade perfeitamente constante, então o dia solar real diverge, aos poucos, do tempo marcado por relógios atômicos de césio — a referência oficial desde 1955. Para os dois não se desalinharem, o Bureau Internacional de Pesos e Medidas (BIPM) criou em 1972 o segundo bissexto: sempre que a diferença ameaça passar de 0,9 segundo, um segundo extra é inserido no UTC, em geral no fim de junho ou dezembro.
Onde a conta não fechou
O problema não foi o segundo em si, mas o “23:59:60” que ele cria. Muitos sistemas Linux tratam hora como contagem estritamente crescente e não sabem o que fazer com um valor que o relógio nunca deveria repetir. Em 2012, uma condição de corrida no kernel Linux fez threads de kernel entrarem em busy-loop assim que o segundo extra era aplicado, consumindo 100% de um núcleo até alguém reiniciar o processo ou aplicar o patch. Mozilla chegou a publicar, em tempo real, que “o Java está engasgando com o leap second”.
Por que isso ainda importa em 2026
O mesmo tipo de falha já havia aparecido em 2008 e voltaria a incomodar operadoras de NTP em ajustes seguintes, o que tornou o segundo bissexto um problema recorrente para quem mantém servidores de tempo, bancos de dados distribuídos e qualquer serviço que dependa de timestamps monotônicos. A pressão de operadoras de nuvem e bolsas de valores — que preferem “esticar” o segundo ao longo do dia (como fazem Google e Amazon com o leap smear) a arriscar um travamento — levou o BIPM a votar, em 2022, o fim do recurso. A resolução final define maio de 2027 como a data em que o segundo bissexto deixa de ser aplicado, antes mesmo do prazo original de 2035.
Conclusão
Até lá, qualquer ambiente que sincronize hora via NTP — de um controlador de domínio a um cluster Kubernetes — ainda pode receber um segundo bissexto pela frente. Vale conferir se o servidor de tempo da infraestrutura usa leap smear ou aplicação direta, porque é exatamente essa escolha que decide se a madrugada da inserção passa em branco ou vira chamado de plantão.
