Do Bug do Milênio ao Ano 2038: o próximo limite do relógio dos computadores

Às 03:14:07 do horário universal (UTC) de 19 de janeiro de 2038 — 00:14:07 em Brasília, pelo fuso oficial atual — uma parte dos computadores do planeta vai chegar ao último segundo que consegue contar. Nesse instante, o relógio interno desses sistemas marcará 2.147.483.647 segundos desde a meia-noite de 1º de janeiro de 1970. É o maior número que cabe num inteiro de 32 bits com sinal, exatamente 2³¹ − 1. No segundo seguinte, sem correção, o contador dá a volta e passa a indicar 20:45:52 UTC de 13 de dezembro de 1901.

O fenômeno tem nome — Problema do Ano 2038, ou Y2038 — e um parentesco evidente com o Bug do Milênio, que mobilizou governos e empresas na virada para 2000. Os dois nascem do mesmo vício: guardar o tempo num espaço finito e torcer para que o futuro demore.

O relógio que conta segundos desde 1970

Sistemas da família Unix — incluindo o Linux, presente em servidores, roteadores e celulares Android — não guardam a data como “19/01/2038”. Eles guardam um único número: quantos segundos se passaram desde um marco zero, a chamada Era Unix (epoch), fixada em 1º de janeiro de 1970, 00:00:00 UTC. O padrão POSIX chama esse valor de “segundos desde a Epoch”; a tela só converte o número em dia, mês e hora.

O Bug do Milênio, 26 anos depois

Para entender por que 2038 preocupa, vale voltar ao Bug do Milênio. Nas décadas de 1950 e 1960, a memória dos computadores era cara, e programadores economizavam cada caractere. Uma das economias foi gravar o ano com dois dígitos: 1965 virava “65”. Como registrou a revista Time, o formato servia para minimizar o uso de memória, então uma mercadoria cara. Na virada do século, “00” poderia ser lido como 1900, e cálculos de juros, idades e prazos sairiam errados.

A correção virou um dos maiores mutirões da história da tecnologia. Segundo o relatório final do comitê especial do Senado dos Estados Unidos sobre o tema, publicado em 29 de fevereiro de 2000, o Departamento de Comércio americano estimou que governo e empresas do país gastaram cerca de US$ 100 bilhões; o escritório de orçamento da Casa Branca (OMB) calculou US$ 8,34 bilhões só no governo federal. O mesmo documento cita estimativas mais altas: de US$ 150 bilhões a US$ 225 bilhões nos EUA, segundo o Gartner Group, e US$ 320 bilhões no mundo, segundo a IDC. No dia 1º de janeiro de 2000, John Koskinen, coordenador do esforço na Casa Branca, falou em cerca de US$ 200 bilhões gastos no planeta, metade deles pelos americanos.

E o que aconteceu na virada? Pouca coisa. Houve falhas pontuais: uma locadora de vídeo cobrou um século de multa por atraso e uma usina nuclear no Tennessee registrou um mau funcionamento, segundo a Time. O comitê do Senado concluiu que a maioria dos incidentes foi pequena, localizada e de curta duração.

A calmaria alimentou um debate que dura até hoje: o Y2K foi exagero ou sucesso da prevenção? O Senado americano tomou partido. No relatório final, o comitê afirmou que o nível de esforço foi justificado e o gasto, necessário, porque as consequências de não agir seriam graves demais. A crítica oposta nunca sumiu, até porque é impossível provar um desastre que não aconteceu.

Uma evolução do mesmo erro

O Bug do Milênio e o Problema de 2038 são variações de um mesmo tema: a representação finita do tempo. No Y2K, o limite era decimal — dois dígitos só vão até 99. Em 2038, o limite é binário — 32 bits com sinal só vão até 2.147.483.647. E a sequência continua. Se o contador for de 32 bits sem sinal (sem números negativos), o estouro é adiado para 06:28:15 UTC de 7 de fevereiro de 2106. Com 64 bits, a conta chega a cerca de 292 bilhões de anos.

Há diferenças importantes. O Y2K estava sobretudo em programas de bancos, governos e grandes empresas, visíveis em telas e relatórios. O Y2038 está mais escondido: em firmware, sistemas embarcados, bancos de dados, formatos de arquivo e protocolos. Outra diferença: o estouro pode aparecer antes de 2038, sempre que um sistema calcula uma data futura que ultrapassa o limite.

O que já foi corrigido

Computadores e servidores modernos de 64 bits já usam, em geral, um contador de 64 bits. O desafio está nos sistemas de 32 bits e em tudo o que grava datas em campos de tamanho fixo.

Sistema operacional e bibliotecas

• Kernel Linux: chamadas de sistema com tempo de 64 bits para máquinas de 32 bits (as “time64”) chegaram na versão 5.1. Em janeiro de 2020, o desenvolvedor Arnd Bergmann escreveu que o Linux 5.6 deveria ser a primeira versão capaz de servir de base para um sistema de 32 bits projetado para funcionar depois de 2038, com ressalvas.
• glibc: a biblioteca C do projeto GNU, base da maioria das distribuições Linux, passou a oferecer na versão 2.34, de agosto de 2021, um time_t de 64 bits em plataformas de 32 bits, ativado pela opção _TIME_BITS=64 (junto com _FILE_OFFSET_BITS=64). O padrão continuou sendo 32 bits; o programa precisa ser recompilado.
• Ubuntu 24.04 LTS: segundo as notas oficiais, resolveu o problema na arquitetura armhf (ARM de 32 bits), com mais de mil pacotes atualizados para contar o tempo em 64 bits.
• Debian 13 “trixie”, lançado em 9 de agosto de 2025: todas as arquiteturas, exceto i386, passaram a usar time_t de 64 bits. As notas de lançamento alertam que software de terceiros em armel e armhf precisa ser recompilado e verificado quanto a possível perda silenciosa de dados.

Bancos de dados e arquivos

• MySQL: a documentação oficial (versão 8.4) mantém o tipo TIMESTAMP limitado a datas entre 1970-01-01 00:00:01 e 2038-01-19 03:14:07 UTC. O tipo DATETIME vai até o ano 9999.
• MariaDB: a versão 11.5.1, de maio de 2024, ampliou o limite do TIMESTAMP para 2106-02-07 06:28:15 UTC, sem mudar o formato de gravação — por ora, apenas em plataformas de 64 bits.
• ext4: inodes pequenos, de 128 bytes, têm datas de 32 bits que estouram em janeiro de 2038; com inodes maiores, a documentação do kernel indica que as datas só estouram em maio de 2446.
• XFS: o recurso “bigtime”, enviado para o Linux 5.10 em 2020, estende as datas até o ano 2486; por compatibilidade, o recurso não vinha ativado por padrão quando foi lançado.

Onde mora o risco

O problema remanescente está no que não se atualiza com facilidade. Equipamentos com processadores de 32 bits e software gravado de fábrica — roteadores, câmeras, controladores industriais, módulos eletrônicos de veículos, sensores de internet das coisas — podem continuar em uso por décadas. Se o fabricante sumiu ou não oferece atualização, ninguém sabe ao certo como cada aparelho reagirá.

Vale cautela, não pânico. Nem todo sistema de 32 bits usa a contagem Unix, e a experiência de 2000 mostra que o diagnóstico precoce funciona: o comitê do Senado americano registrou que a taxa de falhas em chips embarcados foi bem menor que a prevista. O risco real costuma estar na combinação de três fatores — aparelho antigo, sem fabricante ativo e responsável por algo crítico.

Faltam pouco mais de 11 anos para 19 de janeiro de 2038. A lição de 2000 é que o desfecho tranquilo não acontece sozinho: ele é resultado de inventário, teste e troca de equipamentos feitos com antecedência.

Ano 2038Bug do MilênioInfraestruturaSoftware