Fim do Segundo Intercalar em 2027: O Que Muda no UTC e no Seu Código

Olá HaWkers, no dia 15 de outubro de 2026, em Versalhes, a 28ª Conferência Geral de Pesos e Medidas (CGPM) aprovou a resolução que encerra o segundo intercalar. A partir de 20 de maio de 2027, o Tempo Universal Coordenado (UTC) passa a correr de forma contínua, sem aquele segundo extra que, desde 1972, foi inserido 27 vezes no relógio oficial do planeta.

Parece notícia de astronomia, e é. Mas quem já viu um servidor travar à meia-noite de um 30 de junho sabe que o segundo intercalar sempre foi um problema de software. Será que o seu sistema ainda carrega alguma gambiarra pensada para ele? Neste artigo você vai entender o que a CGPM decidiu, por que a rotação da Terra forçou a decisão, quais bugs famosos o segundo extra causou e, principalmente, o que revisar no seu código e na sua infraestrutura antes de maio de 2027.

O Que é o Segundo Intercalar e Por Que Ele Existia

O mundo tem duas formas de medir o tempo. Uma é atômica: o segundo é definido pela oscilação do átomo de césio, e o Tempo Atômico Internacional (TAI) é a média de centenas de relógios atômicos espalhados pelo planeta. A outra é astronômica: o UT1 acompanha a rotação real da Terra, que não é perfeitamente regular.

O UTC é o meio-termo entre as duas. Ele anda no ritmo dos relógios atômicos, mas era mantido a menos de 0,9 segundo do UT1. Sempre que a diferença chegava perto desse limite, o Serviço Internacional de Rotação da Terra e Sistemas de Referência (IERS) anunciava, no seu Boletim C, que um segundo seria adicionado no fim de junho ou de dezembro. O relógio então marcava 23:59:60 antes de virar o dia.

Alguns números para situar:

1972: ano do primeiro ajuste, quando a diferença entre TAI e UTC foi fixada em 10 segundos.
27: total de segundos intercalares inseridos desde então, todos positivos.
37 segundos: diferença atual entre TAI e UTC.
31 de dezembro de 2016: data do último segundo intercalar aplicado.

Repare no último item. Faz quase dez anos que nenhum segundo é adicionado, e isso tem explicação.

Por Que a Decisão Saiu Agora: A Terra Está Girando Mais Rápido

Durante décadas, a Terra girou um pouco mais devagar que o relógio atômico, e por isso todos os ajustes foram para adicionar tempo. Nos últimos anos, a tendência se inverteu: a rotação acelerou levemente. Um artigo de Duncan Agnew publicado na revista Nature em março de 2024 projetou que seria necessário remover um segundo por volta de 2029, e um workshop de 2025 do comitê consultivo de tempo e frequência com o IERS estimou em 30% a chance de um segundo intercalar negativo até 2035.

Um segundo negativo nunca foi aplicado. Nenhum sistema em produção foi testado de verdade com um minuto de 59 segundos, e o histórico dos segundos positivos mostra que a indústria mal aguentava o caso "fácil".

A trajetória da decisão foi esta:

Novembro de 2022: a 27ª CGPM decidiu abolir o segundo intercalar até 2035, sem fixar a data.
Janeiro de 2026: o rascunho da Resolução C propôs 20 de maio de 2027 como data de início.
15 de outubro de 2026: a 28ª CGPM aprovou a resolução "sobre as ações técnicas necessárias para garantir a continuidade do UTC".

A nova regra permite que a diferença entre UTC e UT1 cresça até 3.600 segundos, ou seja, uma hora. Na prática, especialistas estimam que nenhuma correção seja necessária por um longo tempo, então o limite funciona como precaução. O BIPM, o IERS e os serviços de distribuição de tempo trabalham agora para a transição de maio de 2027.

Os Bugs Que o Segundo Intercalar Deixou na História

Se você trabalha com infraestrutura, provavelmente já ouviu falar de pelo menos um destes casos.

Reddit e o Kernel Linux em 2012

No dia 30 de junho de 2012, o Reddit ficou fora do ar por cerca de 30 a 40 minutos. A causa foi um bug no subsistema de temporizadores de alta resolução (hrtimer) do kernel Linux: a mudança de horário confundiu o kernel, e as máquinas travaram com a CPU em 100%. O mesmo segundo derrubou ou degradou serviços de várias empresas naquela noite.

Cloudflare e o Go em 2017

Na virada de 2016 para 2017, o servidor de DNS da Cloudflare (o RRDNS, escrito em Go) calculou um tempo de resposta negativo depois que o relógio voltou um segundo. Esse valor foi parar em rand.Int63n(), que entra em pânico com argumento negativo. No pico, cerca de 0,2% das consultas de DNS falharam, e a correção levou 6 horas e 45 minutos para ser distribuída. Pouco depois, o Go 1.9 passou a incluir um relógio monotônico no runtime, para que diferenças de tempo nunca mais ficassem negativas quando o relógio de parede volta.

A Gambiarra Que Virou Padrão: o "Smear"

Para não lidar com um 23:59:60, as grandes nuvens passaram a espalhar o segundo extra ao longo de várias horas. O Google faz isso desde 2008: durante 24 horas, de meio-dia a meio-dia em UTC, os relógios rodam 11,6 partes por milhão mais devagar. A AWS adotou o mesmo esquema de 24 horas, e a Meta usa uma janela de 17 horas.

O problema é que cada empresa espalha de um jeito. Durante a janela, um relógio "espalhado" pode estar até meio segundo longe do UTC oficial, e dois servidores que usam fontes de tempo diferentes discordam entre si. Para quem compara timestamps de sistemas distintos, isso é uma fonte silenciosa de inconsistência.

O Que o Seu Código Faz com `23:59:60`

A primeira coisa que vale saber é que a maior parte das linguagens simplesmente não representa o segundo 60. O tempo Unix conta segundos como se todo dia tivesse exatamente 86.400, e as bibliotecas padrão seguem essa ficção. Teste você mesmo no Node.js:

// Node.js 24: como o Date lida com o segundo intercalar de 2016

// Uma string ISO com o segundo 60 não é aceita: o resultado é NaN
const parsed = Date.parse('2016-12-31T23:59:60Z');
console.log(parsed); // NaN

// Já o Date.UTC aceita 60 segundos, mas "transborda" para o minuto seguinte
const overflow = new Date(Date.UTC(2016, 11, 31, 23, 59, 60));
console.log(overflow.toISOString()); // 2017-01-01T00:00:00.000Z

// Conclusão: o segundo intercalar some do seu sistema.
// Se um log externo trouxer "23:59:60", trate antes de parsear.
function parseWithLeapSecond(iso) {
  const leap = iso.replace(/T(\d{2}):(\d{2}):60/, 'T$1:$2:59.999');
  return new Date(leap);
}

console.log(parseWithLeapSecond('2016-12-31T23:59:60Z').toISOString());
// 2016-12-31T23:59:59.999Z

O Python é ainda mais direto: datetime.fromisoformat('2016-12-31T23:59:60+00:00') lança ValueError: second must be in 0..59. Se você consome dados de equipamentos, satélites ou sistemas financeiros que registram o segundo 60, esse erro já pode estar escondido em algum pipeline de ingestão.

Com o fim do segundo intercalar, esse caso deixa de aparecer em dados novos a partir de 2027. Os dados históricos, porém, continuam lá. Se você processa logs ou séries temporais antigas, o tratamento acima continua necessário.

Meça Duração com Relógio Monotônico, Sempre

A lição mais importante do caso da Cloudflare não depende do segundo intercalar. O relógio de parede (Date.now(), time.time(), System.currentTimeMillis()) pode voltar ou pular por vários motivos: ajuste do NTP, correção manual, suspensão de VM, migração de máquina. Medir duração com ele é um bug esperando para acontecer.

// Errado: Date.now() é relógio de parede e pode andar para trás
function measureWrong(fn) {
  const start = Date.now();
  fn();
  return Date.now() - start; // pode ser negativo se o relógio for ajustado
}

// Certo: performance.now() é monotônico, só anda para frente
function measureRight(fn) {
  const start = performance.now();
  fn();
  return performance.now() - start;
}

// No Node.js, para precisão de nanossegundos, use process.hrtime.bigint()
function measureNs(fn) {
  const start = process.hrtime.bigint();
  fn();
  return process.hrtime.bigint() - start; // BigInt em nanossegundos
}

console.log(`${measureRight(() => JSON.stringify({ a: 1 })).toFixed(3)} ms`);

Em Python, a regra é a mesma: time.monotonic() ou time.perf_counter() para duração, time.time() só para registrar quando algo aconteceu. Em Go, desde a versão 1.9, time.Since(start) já usa a leitura monotônica embutida no time.Time, desde que você não remova essa leitura com operações como t.Round(0) ou serialização.

O fim do segundo intercalar reduz os saltos previstos no relógio de parede, mas não elimina os outros. Código que mede duração com relógio monotônico não liga para nenhum deles.

Onde o Segundo Intercalar Mora na Sua Infraestrutura

O segundo intercalar não aparece só em código de aplicação. Ele vive em três lugares que valem uma revisão.

1. O Arquivo `leap-seconds.list`

O banco de dados de fusos horários (tzdata) e o IERS distribuem o arquivo leap-seconds.list, que traz cada ajuste e uma data de expiração. Vários daemons de NTP e PTP leem esse arquivo, e alguns reclamam quando ele expira. Este script lê o arquivo e mostra o deslocamento atual entre TAI e UTC:

# Lê o leap-seconds.list e mostra o deslocamento TAI-UTC e a validade
from datetime import datetime, timezone
from pathlib import Path

# Época do NTP (1900-01-01) em relação à época Unix (1970-01-01)
NTP_TO_UNIX = 2_208_988_800

def ntp_to_datetime(ntp_seconds: int) -> datetime:
    return datetime.fromtimestamp(ntp_seconds - NTP_TO_UNIX, tz=timezone.utc)

def read_leap_seconds(path: str):
    entries, expires = [], None
    for line in Path(path).read_text().splitlines():
        if line.startswith('#@'):
            # Linha especial com a data de expiração do arquivo
            expires = ntp_to_datetime(int(line.split()[1]))
        elif line and not line.startswith('#'):
            ntp, offset = line.split()[:2]
            entries.append((ntp_to_datetime(int(ntp)), int(offset)))
    return entries, expires

entries, expires = read_leap_seconds('/usr/share/zoneinfo/leap-seconds.list')
last_date, offset = entries[-1]
print(f'Último ajuste: {last_date:%Y-%m-%d} | TAI-UTC = {offset}s')
print(f'Arquivo válido até: {expires:%Y-%m-%d}')

O caminho muda conforme o sistema (no Debian e no Ubuntu costuma ficar em /usr/share/zoneinfo/). A saída esperada hoje é TAI-UTC = 37s, com o último ajuste em 1º de janeiro de 2017. Depois de maio de 2027, esse número deve congelar em 37 de vez.

2. O Daemon de NTP

Se você usa o chrony, que é o padrão em várias distribuições, a configuração de como reagir a um segundo intercalar fica no chrony.conf. É uma boa hora para saber o que o seu servidor faria:

# /etc/chrony/chrony.conf (trecho)

# Como tratar um segundo intercalar anunciado:
#   system -> deixa o kernel inserir o segundo (padrão)
#   slew   -> espalha o ajuste, sem salto no relógio
#   step   -> dá o salto de uma vez
#   ignore -> não faz nada
leapsecmode slew

# Velocidade máxima de correção em ppm (1000 ppm corrige 1 s em ~17 min)
maxslewrate 1000

# Lê os segundos intercalares do tzdata, útil se a fonte NTP não os anuncia
leapsectz right/UTC

E para conferir o estado atual na máquina:

# O chrony mostra "Leap status: Normal" quando não há ajuste pendente
chronyc tracking | grep -i leap

# No systemd, confira se o relógio está sincronizado
timedatectl show --property=NTPSynchronized

Um cuidado importante: não misture fontes de tempo com e sem smear no mesmo cluster. Se metade das máquinas usa o servidor de tempo da sua nuvem (com smear) e a outra metade usa pool.ntp.org (sem smear), elas vão discordar durante qualquer ajuste. Com o fim do segundo intercalar esse risco diminui, mas o hábito de padronizar a fonte de tempo vale para sempre.

3. Sistemas Que Dependem de Escalas Diferentes

GPS, Galileo e outros sistemas de navegação usam escalas de tempo próprias, sem segundos intercalares. O tempo GPS, por exemplo, está 19 segundos atrás do TAI, o que hoje dá 18 segundos de diferença em relação ao UTC. Qualquer software que converte entre essas escalas tem uma tabela de ajustes em algum lugar. Depois de 2027 a tabela para de crescer, mas não pode ser apagada: os timestamps antigos continuam precisando dela.

O Que Fica Mais Simples (e o Que Não Muda) Depois de 2027

Fica mais simples:

Não haverá mais 23:59:60 em dados novos nem anúncios de ajuste a cada seis meses.
As estratégias de smear deixam de ser necessárias, e relógios de empresas diferentes param de divergir por causa delas.
O risco do primeiro segundo intercalar negativo, que nunca foi testado em produção, sai da mesa.
A conta "todo dia tem 86.400 segundos", que o tempo Unix sempre fingiu ser verdade, passa a ser verdade para o UTC daqui para frente.

Não muda:

Fusos horários e horário de verão continuam existindo e continuam mudando por decisão política. Esse sempre foi o maior problema de datas em software, e o fim do segundo intercalar não toca nele.
Dados históricos com segundos intercalares continuam exigindo tratamento.
Relógio de parede continua podendo pular por NTP, VM ou erro humano. Duração continua sendo medida com relógio monotônico.
Astrônomos, operadores de satélite e quem precisa do UT1 continuam tendo que aplicar a diferença por conta própria, e ela vai crescer devagar.

Para quem trabalha com datas no JavaScript, a mudança combina bem com a chegada da Temporal API, que separa de forma explícita instantes, datas de calendário e fusos. Se você ainda não viu, eu expliquei como ela funciona em Temporal API no ES2026: o novo jeito de lidar com datas no JavaScript.

Um Checklist Rápido Para Revisar Antes de Maio de 2027

Nada aqui é urgente, mas tudo é barato de conferir:

Procure no código medições de duração feitas com Date.now(), time.time() ou equivalentes e troque por relógio monotônico.
Verifique se algum parser de logs ou de dados de terceiros quebra com :60 no campo de segundos.
Descubra qual fonte de tempo cada ambiente usa (nuvem, pool.ntp.org, servidor interno) e padronize.
Revise configurações de chrony ou ntpd com regras específicas de segundo intercalar e documente o motivo de cada uma.
Mantenha o pacote tzdata atualizado: ele continua recebendo mudanças de fuso horário, que são muito mais frequentes que segundos intercalares.
Se você converte entre GPS, TAI e UTC, garanta que a tabela de ajustes está versionada e não vai ser "limpa" por alguém achando que virou código morto.

Perspectivas: O Relógio Mundial Escolheu a Previsibilidade

A decisão da CGPM é, no fundo, uma escolha de engenharia. Por mais de 50 anos, o relógio oficial do planeta tentou acompanhar a rotação da Terra com precisão de menos de um segundo, e o preço foi pago por toda a infraestrutura digital, um bug de cada vez. Com a Terra ameaçando exigir o primeiro segundo negativo da história, o risco ficou alto demais.

A partir de 20 de maio de 2027, o UTC passa a ser previsível: cada dia tem o mesmo número de segundos e nenhum relógio precisa saltar por causa do céu. A diferença para a rotação real vai crescer devagar, e um dia, talvez daqui a séculos, alguém vai ter que decidir o que fazer com ela. Até lá, o recado para quem escreve software é simples: trate datas como dados delicados, meça duração com relógio monotônico e não confie que o relógio de parede sempre anda para frente.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu o fim do segundo intercalar em 2027 e o que muda no UTC e no seu código, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso