2038: o bug do milênio atacará novamente

Entre os grandes medos que pairavam a informática nos anos 90, o Bug do Milênio possuía lugar privilegiado na primeira fila. O emblemático problema aconteceria na passagem do ano de 1999 para 2000 em sistemas mais antigos, que traziam datas armazenadas com apenas dois dígitos finais.

Dessa forma, quando o calendário fosse modificado para 2000, o medo era de que os sistemas na linguagem COBOL ou semelhantes simplesmente retornassem ao ano 1900. Com isso, os efeitos seriam devastadores, com clientes de banco aparecendo como devedores, boletos emitidos com datas 100 anos anteriores, juros e muito mais.

O pânico foi tão grande que empresas e pessoas correram para atualizar seus softwares e hardwares, permitindo que as que vendiam serviços e equipamentos eletrônicos lucrassem uma pequena fortuna vendendo seus produtos.

Entretanto, o que se viu foram falhas pequenas, fáceis de serem corrigidas. O grande Bug do Milênio chegou e passou sem maiores problemas, e todo o pânico acabou por cair por terra, já que mísseis nucleares não foram lançados aleatoriamente, aviões continuaram nos céus e os sistemas seguiram funcionando sem nenhuma complicação.

Enquanto alguns ainda preconizam que o Bug não aconteceu exatamente por causa da renovação dos sistemas, outros ainda se perguntam se o grande problema era, de fato, um grande problema.

Mais um à vista

Se você acha que todo o drama já passou, está mais do que enganado. A próxima falha deve acontecer no ano de 2038, quando um novo bug pode causar erros em programas de computadores.

Chamado de Bug do Milênio Unix, o Y2K38, Y2.038K ou S2G tem data marcada para o dia 19 de janeiro. Da mesma forma que a falha do ano 2000, esta também aparece na contagem de datas, trazendo dificuldades de cálculo a partir de 2038. O bug deve acontecer a todos os softwares desenvolvidos na linguagem C, ou seja, aqueles em que a data é calculada pelo número de segundos desde o dia 1 de janeiro de 1970, ao meio dia.

Essa data inicial conta com valor zero e, a partir dela, todos os outros valores de tempo são expressos em segundos. Ao subtrair quaisquer dois valores por esse sistema, o valor final é sempre a diferença entre esses mesmos dois números, facilitando a contagem e determinação entre dois momentos distintos no tempo.

No formato padrão de 4 bytes, usado por esses sistemas, o número máximo a que se podem chegar em números positivos é de 2.147.483.64 (03:14:07 pelo código UTC - Coordinate Universal Time), ou seja, a data de 19 de janeiro de 2038.

A partir daí, o tempo começa a ser armazenado em números negativos, algo que os sistemas devem interpretar como a data de 13 de dezembro de 1901 (curiosamente, uma sexta-feira 13), em vez da data real em que estaremos. O contador fica sem números usáveis e começa a contar do número máximo negativo, retornando novamente ao zero.

Como resolver?

Em sistemas que não trabalham com datas futuras, o problema só deve aparecer perto do ano 2038. Entretanto, para programas que usam contagem de tempo no futuro, ou seja, usam datas mais à frente para organização, é preciso pensar em resoluções antes do novo bug.

Porém, diferente das correções necessárias em 2000, este problema é bem mais simples de resolver. No caso de sistemas bem escritos, basta programá-lo para uma nova versão, que utilize valores de 8 bytes para armazenar datas.

Transformar o tipo de datação de 32 bits para sistemas de 64 bits é uma alternativa que provou-se funcionar, uma vez que se utiliza de datas mais elásticas – no caso,  292 bilhões de anos no futuro.

Entretanto, a mudança de definição dos sistemas de 32 para 64 bits pode prejudicar a compatibilidade binária de softwares. Todavia, trocar sistemas para os que suportam a arquitetura de 64 bits (descartando o de 32 bits) deve acontecer antes da data fatídica chegar, já que esses sistemas são cada vez mais comuns, tanto em computadores pessoais quanto em servidores.

Claro, muitos sistemas embarcados ainda podem não ser substituídos até a data prevista. Além disso, alguns arquivos codificados em formato 32 bits (como o ZIP) continuam a todo o vapor, deixando o problema ali mesmo depois da vida útil dos computadores em si.

Existem outras alternativas para resolver a falha,  entre elas a inclusão de armazenamento de datas em milissegundos ou microssegundos. Essa opção traz um mínimo de 300.000 anos antes que os números inteiros cheguem a uma contagem negativa.

Datas diferentes para sistemas diferentes

A data limite de 2038 varia de acordo com qual é o valor zero utilizado para iniciar a contagem de tempo. No Windows NT, que se utiliza de inteiro de 64 bits, com nanossegundos como contagem e data inicial de 1 de janeiro de 1601, o problema deve aparecer apenas no ano de 2184.

Já em computadores que iniciam seu ponto de partida zero em 1 de janeiro de 1980, os números inteiros devem se esgotar apenas em 2116, mesmo que usem inteiros de 32 bits. A Apple, entretanto, diz que só terá problemas semelhantes no ano de 29.940, ou seja, tempo mais do que suficiente para novas tecnologias darem conta do recado.

Para saber detalhes mais técnicos sobre o assunto, você pode acessar a página do Project 2038 ou do The Year 2038 Bug (ambas em inglês), que trazem informações detalhadas sobre o assunto, incluindo códigos que podem ser usados por desenvolvedores para resolver o problema.

O que vale comentar é que esse problema não traz motivos para um pânico desenfreado, como aconteceu em 2000. Além de ser uma situação mais simples, o espaço de tempo para uma resolução é ainda maior, suficiente inclusive para que novas tecnologias surjam e não tragam maiores problemas para o armazenamento e contagem de data.