Nos últimos anos do século passado, o famigerado “Bug do ano 2000” causou preocupações em todo o mundo. Muitos acreditavam num caos apocalíptico e no colapso da civilização, causado pela falha dos computadores, dos sistemas públicos, dos bancos e de qualquer dispositivo que tivesse algum chip a calcular datas com apenas 2 dígitos no ano.
O Y2K, ou “Bug do Ano 2000”, foi uma dor de cabeça para milhares de informáticos e responsáveis de IT no fim do século passado. O famigerado bug ameaçava atacar qualquer computador que usasse um formato de data com dois dígitos para o ano — por exemplo, “17/01/97”.
Este formato, que para minimizar o uso da memória dos computadores assumia um 19 antes do ano, era usado pelos primeiros programadores informáticos — que, algures pelos anos 50 e 60 do século passado, não sonhavam que os sistemas informáticos que estavam a criar poderiam vir a ter um tempo de vida mais longo que o esperado e sobreviver até ao ano 2000. Ou, no formato que usavam, até ao ano 00.
O problema é que, ao bater da meia noite de 31/12/99, os computadores passavam a assumir que a data corrente era 01/01/00 – ou seja, o primeiro dia de janeiro de 1900.
Este comportamento poderia causar os mais variados problemas, pequenos e grandes — desde bancos a calcular juros negativos, equipamentos hospitalares a desligar-se porque não era dia de estarem a funcionar, registos de pessoas vivas com idades negativas porque “só iam nascer” daí a 97 anos… Os problemas poderiam repercutir-se em grande escala.
O método usado para resolver o problema a longo prazo foi reescrever todos os componentes dos sistemas de programação, bancos de dados e código fonte, para que usassem datas com ano de quatro dígitos — o que demorou tempo e custou dinheiro. Milhares de programadores e empresas passaram anos a reescrever código e trocar sistemas por novas versões com um formato de 4 dígitos para o ano.
Porém, nem todos os responsáveis de IT escolheram resolver definitivamente o problema. Alguns, usaram uma solução rápida que simplesmente o adiou para 2020. E quando todos pensávamos que tínhamos sobrevivido ao Bug do Ano 2000, revela o New Scientist, uma série de incidentes veio colocar à vista um novo problema: o Y2020.
A solução rápida para o bug do Y2K escolhida por alguns programadores foi usar uma técnica de “windowing”, colocando subrotinas no código de modo a que, sempre que o ano fosse “menor que 20”, o sistema assumia um 20 antes. Ou seja, à última badalada de 31/12/(20)19, alguns sistema regressaram a… 01/01/1900.
A técnica que muitos programadores usaram em 2000 para solucionar o bug do Y2K, informalmente chamada de “ano central”, causa problemas semelhantes aos do ano 2000. No sistema de dados de dois dígitos, “20” torna-se o ano central.
Isso significa que os dados que contêm um ano de dois dígitos entre “00-20” serão tratados como pós-2000, enquanto os anos entre 20-99 serão interpretados como referentes ao século anterior. Os sistemas que usam o “ano central” acreditam agora que estamos de volta a 1920.
O problema já se fez sentir. Os parquímetros em Nova Iorque, por exemplo, recusaram pagamentos com cartão de crédito depois de um software desatualizado ter desativado a opção de pagamento no Ano Novo. O Departamento de Transportes, diz a ZDNet, ainda está a percorrer a cidade para atualizar manualmente os 14 mil parquímetros, um por um.
Há vinte anos, 2020 parecia suficientemente distante para que muitos programadores ainda escolhessem 20 como “o ano central”, assumindo que a maioria dos sistemas e códigos seria substituída entretanto.
Até agora, os sistemas afetados estão a ser reparados rapidamente e algumas empresas enviaram correções antes do Ano Novo. Porém, há cada vez menos especialistas capazes de intervir nestes sistemas, e cada vez mais os paradigmas de programação se afastam da forma como estas linguagens antigas eram implementadas.
Assim, para os que apenas empurraram o assunto durante um par de décadas, os problemas acabaram de recomeçar. Quanto aos outros todos, nenhum deverá estar por cá no dia 31 de dezembro de 9999.
