Anteriores:
< Trilha Zero >

Agora, há que ter cuidado: o terreno é escorregadio. Se você espera problemas no que toca ao bug do ano 2000, o mais provável é que eles apareçam na seara dos programas. A razões são tantas e tão variadas que para discuti-las seria preciso uma série inteira, por isto nos restringiremos apenas a algumas.

A mais óbvia, evidentemente, é a que diz respeito aos velhos programas DOS (muitos deles desenvolvidos em Clipper ou similar) concebidos e compilados para tratar o ano com apenas dois algarismos. Há, literalmente, dezenas de milhares deles rodando por aí, desde o indefectível controle de locadora de vídeo desenvolvido pelo primo do colega da namorada do vizinho, um garoto que "mexia com computador" e fazia programas nas horas vagas no final dos anos 80 e que hoje ninguém sabe por onde anda, até produtos robustos de controle financeiro e administrativo de empresas de porte médio desenvolvidos por softhouses sérias. Neles, os campos de entrada de dados têm espaço apenas para dois algarismos. Mesmo que o Clipper, internamente, seja capaz de manejar datas além de 2000 (as versões 5.1 e mais recentes são), a crítica de validação da data cabe ao programador. Resultado: a maioria destes programas interpretará os anos como iniciando sempre por "19". E não tem jeito de consertar a não ser alterar o código fonte e recompilar o programa.

Há também um problema do qual raramente nos damos conta: mesmo os programas preparados para aceitar anos além de 2000 terão que adotar algum critério para interpretar as datas que lhes são fornecidas com anos de dois dígitos. Um exemplo? Carregue o Excel (eu estou presumindo que sua versão já está atualizada para o ano 2000 com o "patch" fornecido pela MS), escolha uma célula qualquer e entre com a data "01/01/30", assim mesmo, usando apenas dois dígitos para o ano. Acesse a opção "Células" do menu "Formatar" e escolha um formato de data que exiba o ano com quatro algarismos. Repare: o ano é 1930. Pois bem: em uma nova célula, entre com a véspera daquele dia, ou seja: "31/12/29". Repita o procedimento e mude o formato do ano para quatro dígitos. Surpresa: você esperava recuar um dia e acabou avançando um século, pois agora o Excel exibe orgulhosamente o ano de 2029. Isto ocorre porque é preciso fixar um limiar para decidir os anos que pertencem a um século ou a outro. Os programadores do Excel decidiram que o ano transcorreu neste século se seus dois algarismos finais formam um número igual ou superior a 30, do contrário transcorrerá no próximo. E olhe que eu disse do Excel, porque os do Outlook, um programa do mesmo pacote do Excel (o Office), decidiram diferente. E, pior, conceberam diferentemente datas inseridas em diferentes campos do programa. Por exemplo: entre com "01/01/05" para um compromisso e a data será interpretada como pertencendo ao ano de 2005. Faça o mesmo em um campo "aniversário" e ela pertencerá a 1995. E até já ouço os murmúrios: "ora, Piropo, francamente! Reclamando de que? O programa é inteligente e sabe que não se marca compromisso para o passado nem aniversário para o futuro". Eu, pressuroso, concordaria, não fosse o caso do Outlook retornar o ano de 2004 para um aniversário em "31/12/04" e 1991 para um compromisso em "01/01/91". Portanto, o melhor é adotar o hábito saudável de entrar sempre anos com quatro dígitos.

Há outros exemplos. Como a técnica de janelamento ("windowing"), lembrada pelo Júlio Botelho. Que consiste no seguinte: alguns programas armazenam datas como a soma de intervalos de tempo decorridos a partir de uma certa origem (sim, você conhece algo semelhante: se acompanha esta série, lembra que é exatamente assim que o DOS trata datas). Em princípio, não há nada de intrinsecamente errado com ela. Exceto o fato de que o espaço de memória destinado a conter o número de intervalos de tempo decorridos desde a origem é limitado. No caso do DOS, como vimos, ele corresponde a quatro bytes, os intervalos são de 0,055 segundos e a origem é 01/01/1981. Ora, evidentemente a coisa somente funcionará enquanto o número de intervalos decorridos "couber" nos quatro bytes. Cada programa que adota esta técnica usa origens e intervalos de tempo diferentes. E são verdadeiras bombas relógio: exceto seus programadores, ninguém sabe quando "explodirão".

Pois é isso. Agora já conhecemos (parte) dos problemas. Semana que vem começaremos a discutir as soluções.

B. Piropo