Introdução

Edição arquivada


Embora o problema do Bug do Milênio tenha passado sem transtornos em janeiro de 2000, conservamos este artigo devido seu valor histórico. Publicado no pânico do Bug do Milênio pela mídia, este artigo é memorável pela frase "na realidade, nada acontecerá". Seguindo o retrospecto dos acontecimentos, esta frase mostrou-se completamente correta, mas em janeiro de 1999 não era este o retrato que pintavam nos meios de comunicação. HowStuffWorks recebeu alguns e-mails elogiando esta simples previsão.

Você ouvirá falar sobre o “Bug do Milênio" constantemente na mídia este ano. E você perceberá que há muitas informações conflitantes. Há também uma boa dose de retórica do "fim do mundo" que roda pela Internet. Em que você deve acreditar?

Neste artigo discutiremos sobre o Bug do Milênio para que você compreenda exatamente o que está acontecendo e o que está sendo feito a respeito. Você pode também explorar vários links relacionados ao tema. A partir destas informações, poderá tirar suas próprias conclusões sobre o assunto.

O que é o Bug do Milênio?
Sua causa é simples. Até pouco tempo, os programadores de computador tinham o hábito de usar dois dígitos para a posição do ano nos campos de data em seus programas. Por exemplo, a data de validade para uma apólice de seguros ou cartão de crédito é armazenada em um arquivo de computador no formato DD/MM/AA (por exemplo - 31/08/99). Os programadores fazem isso por uma série de razões:

  • é assim que a maioria das pessoas faz diariamente. Quando você assina um cheque à mão e usa o formato de "barras” para a data, você escreve desta maneira; 
  • é necessário menos espaço para armazenar 2 dígitos ao invés de 4 (o que hoje não é grande coisa, já que os discos rígidos estão muito baratos, mas fazia diferença em equipamentos mais antigos);
  • as agências regulamentadoras não recomendavam o formato de 4 dígitos para o campo de data até recentemente;
  • ninguém esperava que estes programas tivessem um tempo de vida tão longo. As pessoas que escreveram o programa em 1970 não tinham nenhuma razão para acreditar que tais programas ainda estariam em uso 30 anos depois.
O formato de ano de dois dígitos cria um problema para a maioria dos programas quando "00" é inserido como ano. O software não sabe se deve interpretar "00" como "1900" ou "2000". Assim, a maioria dos programas utiliza 1900 como padrão. Isto é, o código desenvolvido pela maioria dos programadores adiciona automaticamente o "19" na frente do ano de dois dígitos ou não faz nenhuma suposição de século. Isto não seria um problema, a não ser pelo fato de que os programas executam vários cálculos baseados em datas. Por exemplo, para calcular sua idade, um programa irá considerar a data de hoje e subtrairá dela a sua data de nascimento. A subtração funciona muito bem para datas com ano de dois dígitos enquanto a data de hoje e a data do seu nascimento estiverem no mesmo século. Caso contrário, o cálculo deixa de funcionar. Por exemplo, se o programa pensar que a data de hoje é 01/01/00 e que a sua data de nascimento é 01/01/65, é possível que o cálculo resulte em uma idade de -65 anos ao invés de 35. Conseqüentemente, cálculos de data fornecem dados errôneos e o software deixa de funcionar ou acaba produzindo resultados incorretos.

Porém, o problema não passa disso. Isso é o Bug do Milênio. Muitos programadores utilizaram o formato de 2 dígitos para ano em seus programas e seus cálculos de data não produzirão respostas corretas em 01/01/2000, nada além disso.

A solução é reparar os programas de modo que eles funcionem corretamente. Existem algumas soluções padrão:

  • reprograme o software de modo que ele entenda os anos 00, 01, 02, etc. como sendo os anos 2000, 2001, 2002, etc.;
  • "repare o problema de verdade" utilizando 4 dígitos para os anos e reprogramando o software por inteiro para que ele entenda as datas de 4 dígitos.

Questão interessante: por que usar quatro dígitos para o ano? Por que não usar cinco ou mesmo seis? Porque a maioria das pessoas acredita que ninguém estará usando tal programa daqui a 8 mil anos, o que parece ser uma suposição razoável. Agora você pode ver como chegamos ao bug do milênio.

Estes reparos são, conceitualmente, fáceis de serem feitos. Entra-se no código, encontra-se cada cálculo de data e faz-se a alteração para que eles sejam realizados corretamente. O problema é que há milhões de lugares dentro do software que têm de ser reparados, sendo que cada reparo tem de ser realizado à mão e testado. Por exemplo, uma empresa de seguros pode ter 20 ou 30 milhões de linhas de código que executam os cálculos do seguro. Dentro do código pode haver 100.000 ou 200.000 cálculos de datas. Dependendo de como o código foi escrito, os programadores deverão entrar no código e modificar à mão cada parte do programa que utiliza data e depois testar cada mudança. Na maioria dos casos o teste é a parte mais difícil, podendo tomar muito tempo.