O bug do milênio ocorre quando qualquer programa, por exibir, armazenar ou aceitar a digitação de datas utilizando apenas dois dígitos para o ano, falha na ordenação de datas ou no cálculo de dias entre duas datas, pois ele considerará qualquer ano a partir de 2000 como pertencente a este século (por exemplo, assumirá 2000 como 1900). Os resultados podem ser relativamente inócuos: exibir uma ordem de compra de 01/01/2000 antes de uma ordem de compra de 30/12/1999 em um relatório pode não ter qualquer conseqüência exceto pela estética.
Mas os resultados também podem ser "catastróficos": se o índice do banco de dados colocar a ordem de compra do ano 2000 antes da ordem do ano 1999, qualquer busca por uma ordem do ano 2000 irá falhar como se a ordem não existisse. Se a ordem de compra previa pagamento à prazo, o sistema pode calcular juros com um século de dias, levando a dívida para as nuvens, ou pode calcular juros negativos, deixando o cliente muito feliz mas o vendedor com um tremendo prejuízo.
Portanto, o bug afeta qualquer software que manipule datas. Sistemas que somente exibem datas (por exemplo, uma agenda de telefones que armazena o dia do seu aniversário) não terão problema algum ou terão problemas meramente estéticos. Mas se o software compara datas, ordena datas ou gera novas datas, existe o bug. Os softwares afetados variam desde BIOS de hardware diversos até aplicativos de folha de pagamento, controle de estoque, passando pelos sistemas operacionais e suites de aplicativos. O Windows 98 e o Office 97 são alguns dos softwares que apresentam bugs do ano 2000.
A solução é corrigir os programas. Muitos fornecedores tem correções (patches) gratuitas, outros dizem simplesmente que você tem que comprar a última versão do software, e alguns produtos não tem correção, tendo que ser substituído por outros programas equivalentes. Até aqui o problema é puramente financeiro: o custo de upgrade do hardware e software afetados.
Temos ainda os sistemas desenvolvidos internamente pelas empresas, e aqui que o bug se torna sério. Não é complexo, mas é demorado depurar qualquer programa para localizar manifestações de bug e corrigi-las. Muitos programas levarão meses neste processo, e a maioria das empresas tem vários sistemas desenvolvidos internamente. Alguns desses programas são caixas-pretas, o programador já foi embora faz anos, e ninguém mais sabe programar na linguagem utilizada originalmente.
Por outro lado, comprar outro programa não é simples. O programa comprado pode exigir customização, treinamento, novo hardware, etc. Ou seja, o bug do milênio é um grande abacaxi para as empresas: envolve muito tempo e dinheiro para corrigir. (Fernando Lozano)
Parece algo trivial, mas testar um PC ou um programa quanto ao problema do ano 2000 pode ser complicado. Existem 5 testes básicos:
- Rodar o programa com a data do sistema depois de 01/01/2000
- Mudar o relógio do sistema para poucos minutos antes de 0:00 do dia 01/01/2000 e ver o que acontece na virada
- Salvar arquivos antes e depois da virada, e ver se o programa consegue relacionar os arquivos corretamente (qual é a versão mais recente)?
- Idem ao 3, mas com dados do arquivo (ex: células com datas no Excel, campos timestamp no Acess)
- Testar se o programa projeta corretamente datas futuras (ex: parcelar um pagamento em três meses iniciando em dezembro de 1999).
Cada um destes testes tem variações para cada programa, de acordo com cada situação em que ele utiliza datas. Como se vê, facilmente o trabalho envolvido se torna muito grande para uma pessoa. Por isso, é melhor confiar nos testes realizados pelos fabricantes ou por empresas independentes. Quanto à correção, você não pode fazer nada. Ou o fabricante fornece uma correção gratuita ou ele te obriga a comprar uma nova versão do programa. (Fernando Lozano)
