O segundo extra que os computadores nunca foram feitos para amar
Relógios atômicos, a base da marcação de tempo moderna, marcam com precisão inabalável. A rotação da Terra, no entanto, é tudo menos constante, desacelerando e acelerando de forma imprevisível. Para reconciliar essa incompatibilidade, leap seconds (segundos bissextos) foram historicamente inseridos no Coordinated Universal Time (UTC), mantendo-o dentro de 0,9 segundos do ritmo celestial do planeta.
Desde sua introdução em 1972, 27 leap seconds positivos foram adicionados. Nessas raras ocasiões, o relógio progride de 23:59:59 para um inédito 23:59:60, antes de finalmente virar para a meia-noite. Esse segundo extra representa um desafio único para sistemas de computador.
Unix time, uma medida fundamental, assume essencialmente que cada dia contém precisamente 86.400 segundos, não oferecendo representação nativa para 23:59:60. Sistemas operacionais como Linux tradicionalmente resolvem isso repetindo um segundo, efetivamente atrasando o relógio para reproduzir 23:59:59 duas vezes.
Esse ajuste de tempo "não monotônico", onde o horário do relógio parece momentaneamente retroceder, viola uma suposição central em inúmeras aplicações de software. Tais interrupções desencadearam repetidamente falhas críticas, incluindo a infame queda do Reddit em 2012, destacando a fragilidade inerente de um sistema construído sobre um segundo que os computadores nunca foram projetados para amar.
Como um segundo repetido colocou o Reddit de joelhos
Um exemplo clássico dessa cascata ocorreu em 30 de junho de 2012. Naquele dia, uma inserção de leap second desencadeou um bug crítico no kernel do Linux. Em vez de ajustar graciosamente, o código hrtimer do kernel, interagindo com temporizadores futex, fez com que os processos acordassem repetidamente e instantaneamente. Isso elevou a utilização da CPU para 100%, efetivamente travando os sistemas.
O Reddit, uma grande plataforma online, sofreu o impacto desse ajuste sutil de tempo. Seus serviços ficaram indisponíveis por aproximadamente 30 a 40 minutos, demonstrando como um único segundo repetido poderia se propagar pela infraestrutura de produção e colocar uma aplicação amplamente utilizada de joelhos.
Este incidente, e outros semelhantes, destacaram uma lição fundamental de engenharia: wall-clock time (tempo do relógio) nem sempre é monotônico. Ele pode saltar para frente, retroceder ou repetir, desafiando a suposição implícita em grande parte do software de que o tempo sempre progride linearmente.
Para sistemas robustos, os desenvolvedores devem projetar lógica para tempo decorrido e ordenação de eventos que não dependa cegamente de time.Now(). Em vez disso, eles devem levar em conta possíveis descontinuidades. Isso envolve o uso de monotonic clocks para medições de duração e o gerenciamento cuidadoso de sequências de eventos onde o tempo pode parecer retroceder.
O pânico de tempo negativo da Cloudflare — e a solução de contorno 'smear'
Um leap second diferente, no dia de Ano Novo de 2017, paralisou o DNS da Cloudflare. Seu código Go calculava durações de consulta DNS subtraindo um timestamp inicial de um timestamp final. Quando o relógio retrocedeu, o cálculo resultou em uma duração negativa, que uma função que esperava um argumento não negativo recebeu, desencadeando um pânico fatal.
Este incidente destacou uma falha fundamental: muitos sistemas de software assumem que o tempo sempre avança, uma suposição violada pelo ajuste padrão do leap second. Como a Cloudflare explicou, o "tempo de resolução percebido será negativo", levando a falhas inesperadas. Para mais detalhes, veja How and why the leap second affected Cloudflare DNS.
Para contornar tais saltos abruptos de tempo, grandes operadoras como Google e Meta empregam uma técnica chamada leap smearing. Em vez de inserir um segundo inteiro de uma vez, eles diminuem sutilmente a velocidade dos relógios de seus sistemas ao longo de várias horas, distribuindo gradualmente o segundo extra. Isso garante que o tempo nunca pareça retroceder para seus sistemas internos.
O smearing evita a descontinuidade acentuada que faz com que o software quebre, mas introduz um novo desafio. Organizações diferentes podem usar cronogramas de smearing diferentes, fazendo com que seus sistemas divirjam temporariamente nas leituras do relógio. Isso requer uma coordenação cuidadosa das fontes de tempo para manter a consistência em toda a infraestrutura distribuída.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Os leap seconds estão com os dias contados — mas o tempo ainda precisa de cuidado
Órgãos internacionais de metrologia decidiram eliminar o leap second, com a mudança prevista para entrar em vigor até ou antes de 2035. Essa mudança monumental permite uma divergência maior entre o Coordinated Universal Time (UTC) e o tempo de rotação da Terra, encerrando meio século desses ajustes disruptivos. A decisão reflete um consenso crescente de que os riscos superam os benefícios.
Um fator crítico para essa mudança é a recente rotação ligeiramente acelerada da Terra. Isso levantou o espectro sem precedentes de um negative leap second, onde um segundo precisaria ser removido do UTC. Tal ajuste, nunca antes implementado, representaria desafios ainda maiores para softwares que historicamente lutaram com a adição de um segundo.
Para desenvolvedores, isso significa que a ameaça imediata dos leap seconds eventualmente diminuirá, mas os princípios fundamentais de uma cronometragem robusta permanecem. Sempre use monotonic clocks para medir durações e timeouts, que garantem que o tempo apenas avance. Mantenha os timestamps civis, frequentemente vinculados ao UTC, distintos das medições de tempo decorrido.
Finalmente, teste rigorosamente todas as suposições sobre o comportamento do relógio. Mesmo sem leap seconds, os sistemas ainda podem encontrar:
- Falhas de sincronização de tempo
- Latência de rede
- Ajustes manuais de relógio
O design e a validação cuidadosos continuam sendo fundamentais para sistemas distribuídos confiáveis.
Perguntas Frequentes
O que é um leap second?
Um leap second é um segundo extra ocasionalmente adicionado ao UTC para mantê-lo aproximadamente alinhado com a rotação irregular da Terra.
Por que um leap second pode quebrar o software?
Alguns sistemas repetem ou ajustam um segundo do relógio, interrompendo softwares que assumem que o tempo sempre avança ou que todo dia tem exatamente 86.400 segundos.
O que causou o problema de DNS da Cloudflare em 2017?
Um ajuste de relógio para trás produziu uma duração negativa em um código que esperava um valor não negativo, desencadeando um pânico em uma função de números aleatórios.
Os desenvolvedores ainda devem usar monotonic clocks?
Sim. Use monotonic clocks para medir o tempo decorrido; os wall clocks ainda podem ser ajustados e são mais adequados para timestamps e tempo de calendário.