Bug 3Oitão: o limite do MySQL que termina em 2038

Em 19 de janeiro de 2038, às 03:14:07 UTC, o tipo TIMESTAMP do MySQL alcançará seu último segundo representável. Um segundo depois, a coluna não terá espaço para registrar o novo instante dentro do intervalo que a documentação atual do banco oferece. O problema não está em todas as datas do MySQL, nem em todo computador moderno. Ele está em uma escolha específica de representação temporal que ainda vive em schemas, bibliotecas e integrações.

Podemos chamar esse problema de Bug 3Oitão. O nome tem humor suficiente para ser lembrado, mas o risco é sério. Sistemas de contratos, assinaturas, financiamentos, seguros, agendas, certificados, retenção de dados e projeções podem tentar gravar datas posteriores a 2038 muitos anos antes da virada. Para esses produtos, o bug não começa na madrugada de 2038. Ele começa quando o horizonte do negócio atravessa o limite técnico.

A tese deste artigo é simples: o Bug 3Oitão deve ser tratado como dívida de modelagem, não como uma futura emergência de calendário. Trocar TIMESTAMP por DATETIME pode fazer parte da resposta, mas não basta executar um ALTER TABLE e torcer para o relógio colaborar. É preciso entender o significado de cada campo, preservar fusos horários, revisar aplicações e integrações, planejar a migração de tabelas grandes e testar datas de fronteira.

O Bug do Milênio deixou uma lição que a memória popular costuma inverter. A virada de 2000 foi relativamente tranquila não porque o risco era imaginário, mas porque houve inventário, orçamento, conversão, simulação e contingência. O melhor destino do Bug 3Oitão é igualmente pouco cinematográfico: ser corrigido cedo o bastante para parecer que nunca existiu.

O Unix tradicional conta segundos a partir de 1970-01-01 00:00:00 UTC, o chamado Unix Epoch. Quando esse contador é representado por um inteiro assinado de 32 bits, um bit indica o sinal e os outros 31 guardam o valor. O maior número positivo possível é 2.147.483.647. Convertido em data, ele aponta para 2038-01-19 03:14:07 UTC.

Essa aritmética aparece diretamente no MySQL. A documentação do MySQL 8.4 define o intervalo de TIMESTAMP entre 1970-01-01 00:00:01 UTC e 2038-01-19 03:14:07 UTC. Já DATETIME aceita valores de 1000-01-01 00:00:00 a 9999-12-31 23:59:59.

Os tamanhos acima são os valores base para tabelas criadas desde o MySQL 5.6.4. Precisão fracionária pode acrescentar de zero a três bytes, conforme a tabela oficial de requisitos de armazenamento. Portanto, migrar de TIMESTAMP para DATETIME não é gratuito, sobretudo em tabelas e índices com bilhões de registros. Ainda assim, economizar um byte por valor é um benefício pequeno quando o preço futuro pode ser a incapacidade de representar o dado correto.

Também é importante separar camadas. O kernel Linux substituiu interfaces antigas cujo campo de segundos transborda em arquiteturas de 32 bits, recomendando estruturas de 64 bits. A documentação de timekeeping do Linux registra explicitamente essa transição. Porém, atualizar kernel, linguagem ou processador não amplia por mágica o intervalo de uma coluna TIMESTAMP definida pelo MySQL. O mesmo nome, "timestamp", pode esconder representações diferentes em cada camada.

O problema de 2038 revela uma confusão anterior: usar um tipo temporal sem decidir que espécie de tempo o campo representa.

Um instante é um ponto único na linha do tempo. O pagamento confirmado às 15h em São Paulo e às 18h em UTC é o mesmo evento. Uma data civil tem outra natureza. "Consulta em 10 de março às 9h" pode depender do fuso da clínica, das regras locais de horário e até de mudanças políticas futuras. Aniversário, vencimento puramente civil e competência contábil pedem ainda outras escolhas.

No MySQL, TIMESTAMP converte o valor do fuso da sessão para UTC ao gravar e faz a conversão inversa ao ler. DATETIME não executa essa conversão. Essa diferença, descrita na documentação dos tipos temporais, explica por que uma migração ingênua pode conservar os números visíveis e alterar o instante real, ou conservar o instante e surpreender quem esperava o horário civil original.

Uma modelagem mais explícita costuma seguir estas perguntas:

1. O campo representa apenas uma data, um horário civil ou um instante global?

2. O fuso original precisa ser preservado como contexto de negócio?

3. Haverá datas anteriores a 1970 ou posteriores a 2038?

4. O valor participa de ordenação, expiração, auditoria, assinatura ou cálculo financeiro?

5. Qual camada é responsável por converter para UTC e apresentar no fuso do usuário?

Para instantes duráveis, uma opção é usar DATETIME(6) normalizado em UTC e impor essa convenção na aplicação, na documentação e nos testes. Para compromissos civis futuros, pode ser necessário armazenar o DATETIME local e também um identificador de fuso, como America/Sao_Paulo, pois um deslocamento numérico isolado não contém as regras históricas e futuras daquela região. Para um dia sem horário, DATE comunica melhor a intenção.

DATETIME não é um TIMESTAMP maior. Ele troca automação de fuso por alcance e por uma semântica diferente. A solução correta começa no domínio, não na preferência pessoal do desenvolvedor.

Relógios de criação, como created_at, podem continuar funcionando por mais de uma década. Campos de futuro não têm esse luxo. Em agosto de 2026, qualquer operação com horizonte superior a aproximadamente onze anos e meio já pode atravessar janeiro de 2038.

Considere um contrato assinado hoje com vigência de quinze anos. Sua data final cai em 2041. Um produto pode calcular corretamente esse vencimento na aplicação e falhar ao persistir o resultado em TIMESTAMP. Dependendo do modo SQL, do driver e do tratamento de erros, a consequência pode ser uma rejeição visível, uma data inválida, um valor substituído ou uma transação inteira desfeita. O comportamento exato precisa ser testado na configuração real, não presumido.

Os primeiros sinais tendem a aparecer em campos como:

• expires_at de credenciais, concessões e assinaturas;
• matures_at de produtos financeiros;
• valid_until de contratos, licenças e garantias;
• scheduled_at de agendas e manutenções de longo prazo;
• datas de retenção, descarte ou revisão documental;
• projeções de previdência, seguro, infraestrutura e ativos de longa duração.

Há ainda um risco menos visível. Uma equipe pode migrar o banco principal e deixar o limite em uma réplica, data warehouse, fila, API, cache, arquivo de exportação ou SDK. A gravação passa no serviço de origem e falha no destino. Em arquitetura distribuída, a menor representação temporal do caminho define o horizonte efetivo do produto.

O Bug 3Oitão é, portanto, um problema de cadeia. O schema é apenas o lugar mais fácil de enxergar. Contratos OpenAPI, serializadores, conversores de epoch, bibliotecas nativas, dispositivos embarcados e consumidores externos também precisam aceitar e preservar datas além da fronteira.

Essa antecipação muda a pergunta de gestão. Em vez de "quantos anos faltam para 2038?", a organização deveria perguntar: "qual é a maior data que nosso negócio pode tentar representar hoje?"

O Bug do Milênio, ou Y2K, nasceu principalmente da representação do ano com dois dígitos. O valor 00 podia ser interpretado como 1900 em vez de 2000. O Bug 3Oitão nasce do limite de um contador binário assinado de segundos. As causas matemáticas são diferentes, mas o padrão de engenharia é familiar: uma economia local de armazenamento vira uma restrição sistêmica quando o software vive mais do que o horizonte imaginado em sua criação.

A comparação também tem limites. O Y2K atingia tecnologias e setores muito diversos na mesma mudança de calendário. O problema de 2038 é mais seletivo. Sistemas com representações de 64 bits ou tipos temporais de maior alcance podem atravessar a data normalmente, enquanto um único campo legado ou dispositivo de 32 bits pode falhar. Essa seletividade torna o inventário mais difícil e favorece a falsa sensação de que "nossa infraestrutura já é 64 bits" resolve tudo.

No Brasil, a preparação para 2000 oferece um roteiro concreto. O Relatório de Atividades e Gestão de 1998 do Serpro descreveu etapas de levantamento, análise de impacto, conversão, simulação e certificação. Registrou ainda R$ 9,3 milhões em gastos de adequação naquele ano. Em dezembro de 1998, 99,3% das linhas identificadas haviam sido convertidas, mas apenas 7,61% dos sistemas estavam certificados. Converter código e demonstrar que o ecossistema funciona eram entregas diferentes.

No setor elétrico, a ANEEL informou em dezembro de 1999 que auditorias haviam examinado 18 mil sistemas suscetíveis, envolvendo 78 concessionárias, além de simulações no sistema interligado. O fato de a virada ter sido tranquila não prova exagero. Mostra que prevenção coordenada pode produzir um evento sem manchetes.

Internacionalmente, a escala continua instrutiva. Em 2024, o Debian anunciou uma transição de time_t para 64 bits em arquiteturas de 32 bits que envolvia mais de 1.200 pacotes de bibliotecas. O anúncio técnico do projeto Debian mostra que o problema não é uma curiosidade de mainframe abandonado. Ainda exige trabalho de compatibilidade em ecossistemas atuais.

Depois do Y2K, o U.S. Government Accountability Office destacou lições de gestão, coordenação, verificação e continuidade aplicáveis a outros desafios de tecnologia. O ponto permanece atual: riscos transversais não são resolvidos por uma equipe isolada no último trimestre.

O impacto técnico mais óbvio é a falha de escrita. Mas há consequências mais sutis: ordenação incorreta, filtros que excluem registros, expirações antecipadas, tarefas que nunca são executadas, assinaturas consideradas inválidas e trilhas de auditoria com cronologia incoerente. Um erro de data pode continuar parecendo um valor plausível, o que o torna mais perigoso do que uma indisponibilidade clara.

No plano econômico, o custo não vem apenas da mudança do tipo. Ele inclui varrer schemas, localizar SQL embutido, atualizar modelos de ORM, rever índices e particionamentos, reprocessar integrações, testar backups e negociar janelas operacionais. Segundo a documentação de Online DDL do MySQL 8.4, alterar o tipo de uma coluna requer cópia da tabela e não permite DML concorrente pelo mecanismo nativo dessa operação. Em uma tabela pequena, isso pode ser aceitável. Em uma tabela crítica e volumosa, um ALTER direto pode se tornar o próprio incidente que a migração tentava evitar.

O adiamento concentra risco. Quanto mais registros, consumidores e contratos surgirem até a correção, maior será a superfície de compatibilidade. A organização economiza agora e compra uma migração mais cara depois, provavelmente competindo com prioridades comerciais mais urgentes.

No Brasil, a Lei Geral de Proteção de Dados não menciona 2038. Ainda assim, o problema pode alcançar obrigações existentes quando datas pessoais são corrompidas. O artigo 6º da LGPD inclui o princípio da qualidade dos dados, com garantia de exatidão, clareza, relevância e atualização. O artigo 46 exige medidas técnicas e administrativas contra perda, alteração e tratamento inadequado, observadas desde a concepção do produto. Isso não transforma toda coluna TIMESTAMP em infração. Significa que conhecer um limite capaz de alterar dados relevantes e não tratá-lo pode deixar de ser apenas uma escolha interna de arquitetura.

Há também uma questão ética. Datas controlam acesso a benefícios, cobranças, prescrições, contratos, direitos e deveres. Quando o modelo temporal falha, o impacto não se distribui igualmente. Quem depende de um serviço público, de um pagamento ou de uma autorização pode sofrer antes de a organização classificar o evento como incidente de banco de dados.

A correção segura começa por inventário. O catálogo INFORMATION_SCHEMA.COLUMNS, documentado pelo próprio MySQL, permite localizar as colunas declaradas como TIMESTAMP:

SELECT
    TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_TYPE,
    IS_NULLABLE, COLUMN_DEFAULT, EXTRA
FROM INFORMATION_SCHEMA.COLUMNS
WHERE DATA_TYPE = 'timestamp'
  AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema',
                           'performance_schema', 'sys')
ORDER BY TABLE_SCHEMA, TABLE_NAME, ORDINAL_POSITION;

Essa consulta produz uma lista, não um diagnóstico completo. Cada coluna deve receber uma classificação semântica e operacional: instante ou horário civil, passado ou futuro, indexada ou não, replicada ou não, pequena ou volumosa, interna ou exposta por contrato.

Escolha do tipo de destino

Em tabelas grandes, uma estratégia de coluna paralela costuma reduzir o risco: adicionar uma coluna nova, preencher em lotes, escrever nos dois campos durante a transição, comparar valores, mover as leituras e só então retirar o campo antigo. Ao converter TIMESTAMP para DATETIME, a sessão e a regra de fuso precisam ser explícitas. O MySQL 8.4 permite projetar um TIMESTAMP como DATETIME UTC com AT TIME ZONE:

SELECT
    created_at,
    CAST(created_at AT TIME ZONE INTERVAL '+00:00' AS DATETIME) AS created_at_utc
FROM orders
WHERE id = 123;

Esse exemplo serve para demonstrar a semântica, não como receita universal de produção. A migração real precisa preservar precisão fracionária, NULL, defaults, ON UPDATE, índices, chaves, particionamentos, triggers, replicação e carga de escrita. Ferramentas de alteração online ou rotinas próprias também precisam ser homologadas na versão e na topologia usadas pela empresa.

O teste de fronteira deve existir em mais de uma camada. Vale validar pelo menos o último segundo aceito, o primeiro rejeitado pelo tipo antigo, uma data como 2040, outra após 2100, fusos positivos e negativos e uma transição de horário local relevante. Também é necessário percorrer o trajeto completo: API, aplicação, banco, evento, consumidor, exportação, restauração de backup e relatório.

Por fim, a correção deve ganhar um critério de conclusão verificável. "Mudamos a coluna" não basta. O resultado esperado é conseguir criar, persistir, transmitir, recuperar e comparar datas posteriores a 2038 sem perda de instante, precisão ou contexto civil.

Hoje, o maior impacto do Bug 3Oitão está nas decisões de arquitetura e no horizonte dos produtos. Uma API criada em 2026 pode permanecer ativa em 2038. Um contrato registrado agora pode vencer depois do limite. Um equipamento comprado para operar vinte anos pode carregar firmware, biblioteca ou protocolo que ainda conta tempo em 32 bits. O futuro já entra no banco como dado antes de chegar ao calendário.

Para equipes de desenvolvimento, isso muda a definição de pronto. Novas tabelas não deveriam receber TIMESTAMP por hábito. Revisões de schema podem exigir uma pergunta explícita sobre alcance e semântica temporal. Testes automatizados precisam abandonar amostras concentradas no presente e incluir fronteiras de representação.

Para lideranças técnicas e de negócio, o tema merece um item no registro de riscos, com responsáveis, inventário, criticidade e prazo de remediação. A prioridade deve ser calculada pelo maior horizonte de data aceito por cada processo, não apenas pela proximidade de 2038. Produtos financeiros, governamentais, industriais e de identidade digital podem precisar agir antes de aplicações cujo único uso temporal é registrar eventos recentes.

Para o mercado, há uma oportunidade pouco comentada. A correção pode melhorar a modelagem temporal inteira. Ao perguntar o que cada campo realmente significa, a empresa descobre conversões implícitas, fusos perdidos, nomes ambíguos, retenções indefinidas e integrações que já produzem inconsistência hoje. O Bug 3Oitão pode financiar uma higiene arquitetural que o simples argumento de "boas práticas" nunca conseguiu priorizar.

Qual é a data mais distante que seus sistemas conseguem receber hoje, e essa resposta foi testada ou apenas presumida?

Se o banco principal aceita 2040, todos os serviços, dispositivos, conectores e arquivos no caminho também aceitam? Se uma data for deslocada algumas horas durante a migração, quem perceberá primeiro: o monitoramento, a auditoria ou o cliente?

Existe outra pergunta desconfortável. Por que organizações conseguem planejar contratos, concessões e ativos por vinte anos, mas tratam tipos de dados como decisões temporárias? A vida útil do software raramente coincide com a gestão que aprovou sua primeira versão. Quem fica responsável por limites que não cabem no ciclo trimestral?

O nome Bug 3Oitão pode pegar porque transforma um número distante em algo conversável. Mas o apelido só terá valor se abrir inventários, testes e decisões. Caso contrário, será apenas uma piada contando os segundos até deixar de ser engraçada.

O limite de 2038 do TIMESTAMP no MySQL é conhecido, preciso e testável. Isso elimina a desculpa da surpresa. Nem todo sistema será afetado, mas qualquer produto que use esse tipo para datas futuras ou que dependa de uma cadeia temporal limitada precisa ser examinado antes que o horizonte do negócio encontre a fronteira técnica.

A resposta não é uma substituição mecânica. É uma revisão de semântica: distinguir instante, horário civil e data; escolher uma representação com alcance adequado; preservar fuso e precisão; migrar sem interromper tabelas críticas; testar toda a cadeia; e provar que os dados continuam corretos depois da mudança.

O Bug do Milênio ensinou que uma virada tranquila pode ser o resultado visível de anos de trabalho invisível. O Bug 3Oitão oferece a mesma oportunidade, com uma vantagem rara em tecnologia: sabemos o segundo exato do limite e já temos alternativas.

Se o apelido pegar, ótimo. Melhor ainda será se a correção pegar primeiro.

Fontes consultadas para criação

• Oracle. MySQL 8.4 Reference Manual: The DATE, DATETIME, and TIMESTAMP Types. Disponível em: <https://dev.mysql.com/doc/refman/8.4/en/datetime.html>.
• Oracle. MySQL 8.4 Reference Manual: Data Type Storage Requirements. Disponível em: <https://dev.mysql.com/doc/refman/8.4/en/storage-requirements.html>.
• Oracle. MySQL 8.4 Reference Manual: The INFORMATION_SCHEMA COLUMNS Table. Disponível em: <https://dev.mysql.com/doc/refman/8.4/en/information-schema-columns-table.html>.
• Oracle. MySQL 8.4 Reference Manual: Online DDL Operations. Disponível em: <https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-operations.html>.
• Linux Kernel Documentation. ktime accessors and deprecated time interfaces. Disponível em: <https://docs.kernel.org/core-api/timekeeping.html>.
• Debian Project, Steve Langasek. 64-bit time_t transition in progress. 2024. Disponível em: <https://lists.debian.org/debian-devel-announce/2024/02/msg00000.html>.
• Serpro. Relatório de Atividades e Gestão 1998: Projeto Ano 2000. 1998. Disponível em: <https://www.transparencia.serpro.gov.br/acesso-a-informacao/contas-anuais/1998/relatorio-de-gestao-1998.pdf>.
• Agência Nacional de Energia Elétrica. Bug do Milênio: o setor elétrico está pronto. 1999. Disponível em: <https://www2.aneel.gov.br/aplicacoes_liferay/noticias_area/arquivo.cfm?idAreaNoticia=425%2F1000&idNoticia=278&tipo=PDF>.
• U.S. Government Accountability Office. Year 2000 Computing Challenge: Lessons Learned Can Be Applied to Other Management Challenges. 2000. Disponível em: <https://www.gao.gov/products/aimd-00-290>.
• Brasil. Lei nº 13.709, de 14 de agosto de 2018: Lei Geral de Proteção de Dados Pessoais. Disponível em: <https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm>.