O terrível Bug Y2K38 se aproxima, e não tem solução fácil!

Ninguém fala do Bug Y2K38 ainda, da mesma forma que o Bug do Milênio, vamos deixar para a última hora, empurrando com a barriga, mas esse bug é bem mais complicado de ser resolvido.

• Cuidado: não mude a data de seu iPhone para 1/1/1970 [UPDATE]
• Como a TI sobreviveu aos ataques de 11 de setembro

Milhares de anos atrás, na virada de 1999 para 2000, a imprensa promovia pânico generalizado com o Bug do Milênio. Alguns “especialistas” previram até o fim da civilização, com aviões caindo do céu, computadores falhando em cascata, desligando malhas elétricas, usinas nucleares explodindo, cães e gatos morando juntos, essas coisas.

Obviamente (spoiler) nada disso aconteceu, mas não quer dizer que o Bug do Milênio não tenha sido real. Bilhões de dólares foram gastos revisando e recertificando sistemas justamente para evitar que eles falhassem na virada do ano.

O bug era bem simples: Ele partia do princípio que memória custa caro. Quando montei meu primeiro PC, um 386 DX-4MHz, instalei 4 MB de RAM, a um custo de US$60/MB. Hoje, sem pesquisar muito, um pente de  8 GB de DDR4 custa R$109,99. Meus 4 MB de RAM custariam atualmente R$ 0.054995.

E já foi bem pior. Houve época em que o custo era de US$1 por byte, e no tempo dos computadores valvulados, bem mais.

Armazenar e processar informação custa dinheiro, então faz sentido economizar. Em sua imensa sabedoria, os gerentes (isso tem que ser idéia de gerente) de TI do passado partiram do princípio que, bem, todo mundo sabe que estamos no Século XX, então incluir espaço em banco e memória para gravar o 19 na frente de todo ano, não faz sentido.

Os computadores guardavam as datas em campos com dois caracteres, ao invés de quatro. Ao invés de “1965”, quatro bytes, o computador só guardaria “65”, economizando metade do espaço, e assim como em talões de cheques (pergunte a seus pais), os “19” seriam pré-impressos.

Em binário fica mais evidente: De 00 a 99 em binário, temos 0000000-1100011. Se fôssemos guardar um ano de quatro dígitos, que se traduziria como 0 a 9999, teríamos 00000000000000-10011100001111. Muito mais bytes.

O problema é que quando um contador de dois dígitos passa de 99, ele retorna a zero. Do ano 1999, somado um, o contador entenderia como 1900. Imagine isso num sistema de empréstimos bancários calculando juros.

Um número imenso de programas tiveram que ser alterados, e apesar do pânico vendido, sobrevivemos, mas agora o buraco é mais embaixo.

O Bug Y2K38

Digamos que você esteja na Década de 1970, cada byte conta, e você quer evitar processamento desnecessário, ao mesmo tempo precisa registrar tempo. Você pode fazer contas complicadas, para determinar a diferença entre dois momentos, mas e se der pra otimizar isso?

Ken Thompson e o povo em cargo do UNIX inventou o chamado “Unix Time”, um valor que conta o tempo em segundos desde o dia 1º de janeiro de 1970. Qual o motivo da data? Nenhum, parecia bonita, redonda, certinha.

A especificação foi aceita, e todo programa ou script em Unix podia usar o Unix Time para gerenciar o tempo, de forma prática e eficiente. Até hoje o Unix Time está presente em nossos sistemas. Se você usa Windows, abra uma janela da PowerShell e copie:

[int][double]::Parse((Get-Date -UFormat %s))

O resultado será um número como: 1672675972

Internamente a especificação definia o Unit Time como um número em formato INT, que em Unix é um dígito de 32 bits, signed. Esse valor de 32 bits atormentou muita gente, e nem por causa do Bug Y2K38. 32 bits, ou quatro bytes, é o maior endereço de memória que um processador de 32 bits consegue endereçar diretamente.

Ou seja: Ele consegue acessar valores armazenados entre 00000000000000000000000000000000 e FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF. Isso dá um total de 4.294.967.296 endereços, pouco mais de 4 GB. Por isso, mesmo com mais memória no sistema, seu Windows 32 bits não conseguia acessar a RAM extra. Na verdade, ele só acessava 3,5 GB, os endereços acima estavam reservados para drivers e outras coisas que o Windows gerencia debaixo dos panos.

Hoje em dia todo mundo roda sistemas de 64bits (menos o meu valente Raspberry Pi3) o que significa uma capacidade de endereçamento teórica de 18.446.744.073.709.551.616 bytes. 18.4 Exabytes.

Claro, ninguém usa ou programa sistemas pra trabalhar com tanta memória teórica, a Microsoft por exemplo limite o Windows Server 2016 Datacenter, sua versão com maior capacidade, a 24 Terabytes de RAM, mais que isso ela não suporta, e o Windows 10 Enterprise, só consegue acessar 6 TB de RAM, uma vergonha, Microsoft.

No caso do Bug Y2K38, o problema seria quando esse inteiro de 32 bits lotasse. Da mesma forma que o contador de dois dígitos do ano voltaria ao zero, o inteiro resetaria, mas agora, você leitor esperto e sagaz está se perguntando:

4294967296 segundos são 136 anos. Não se passou tanto tempo desde 1970. Eu acho.

Exato, pequeno gafanhoto. A virada deveria ser em 2106, certo?

Certo, exceto que o Unix Time é definido como um número INT, de 32 bits, signed, isso quer dizer que ele consegue armazenar valores negativos E positivos, indo de -2147483648 a 2147483647. E 2147483647 após 1/1/1970 é... 2038. No dia da virada, às 15h14min07seg do dia 19 de janeiro de 1938, o Unit Time resetará para 1/1/1902.

Agora a parte complicada: Temos literalmente bilhões de equipamentos de Internet das Coisas, sistemas embarcados, controladores de chão de fábrica, tudo usando chips baratos e restritos, que usam o Unix Time.

Boa parte desses equipamentos não têm suporte, muito menos um caminho fácil para atualização de firmware. Sistemas mais modernos costumam levar em conta o Bug Y2K38, e não usam mais Unix Time, ou o atualizaram para formatos como BIGINT, mas a maioria está bem presa ao hardware.

O efeito-cascata acontecerá com funções que receberão o valor do Unix Time e não saberão lidar com valores negativos.

O Unix Time é usado diretamente até em protocolos de comunicação, e microcontroladores de 32 bits como o ESP32 o utilizam também. Se muita coisa não for alterada, vai quebrar tudo.

O Bug do Milênio custou mais de US$ 300 bilhões para ser mitigado. Estima-se que o Bug Y2K38 custe bem mais que isso. Ainda mais por ninguém estar se preocupando ainda, afinal isso será só em 2038, ainda estamos 2038 - YEAR(NOW) disso ser um problema.

Enquanto isso, a solução provisória nos novos softwares é tratar o Unix Time como um inteiro de 64 bits, o que é só adiar o problema. Daqui a 292 bilhões de anos, quando o Unix Time estourar de novo, vai ser a mesma correria.