Lê-se muito ultimamente sobre Windows 2000, Office 2000 e até mesmo sobre o bug do ano 2000, esse sim, o problema da moda. Enquanto os sistemas da Microsoft passam a usar o 2000 como identificação, mais por marketing do que por necessidade, o Y2K é inquestionavelmente um grande problema, erroneamente chamado de bug.
Na verdade, não é um bug, mas um problema gerado pela crença do passado de que, antes do ano 2000, todos os sistemas seriam recodificados. E não foram. Este problema está, basicamente, na codificação de ano com dois dígitos.
Diria um eventual usuário de micro: ‘‘Que besteira! Sei facilmente a que ano se refere o documento pelo contexto. Além disso, basta mudar para quatro dígitos’’.
Mas não é tão simples assim. Primeiro, a sensibilidade ao contexto serve bem ao humano, mas carece de cuidados especiais a sistemas informatizados. Segundo: mudar não é tão fácil quanto parece. Vejamos. Quem nasceu antes, o ovo ou a galinha?
A primeira e mais fácil ocorrência do problema se apresenta em aplicações que exigem do usuário entrar em uma data usando um campo de dois dígitos para o ano, historicamente para reduzir o espaço de memória necessário para armazenar dados ou o número de toques para digitar esses dados.
Isso resulta na inabilidade dos sistemas para distinguir entre 1900 e 2000, e faz com que o uso subsequente dessa data em funções matemáticas falhe inesperadamente.
Como decorrência, a codificação do campo ‘‘data’’ fica com seis dígitos. Isso é muito comum em sistemas de informações administrativas, planejamento, recursos humanos, financeiro e faturamento. Por exemplo: 9 de março de 1948, codificado usando seis dígitos tipo ‘‘YYMMDD’’ (ano, mês e dia), resulta em ‘‘480309’’.
A grande vantagem da forma ‘‘YYMMDD é para ordenação de datas e comparações. Um único teste e podemos determinar a ordem. Mas veja só o que causará. O dia 22 novembro de 1999 (991122) seria declarado incorretamente como mais recente do que 3 de fevereiro de 2001 (010203).
Quem não se lembra dos marcadores de fim de dados com 99, em particular o famoso 9/9/99? Pois é. Temos aí um novo problema. Mais raro de encontrar nos dias de hoje, mas ainda encontrado nos aplicativos de muitas empresas grandes. Veja: em 9 de setembro do ano que vem já começam os problemas...
As falhas de sistemas decorrentes das operações com data poderão permitir quebra de segurança, abrindo informações antes da data, podendo ainda fazer com que sensores industriais operem incorretamente.
A fórmula usada atualmente para determinar ano bissexto é incorreta para anos posteriores a 2000 e isso certamente criará problemas na determinação de datas futuras, principalmente nos programas de cobrança. Sem contar o monte de programas que inserem os dígitos ‘‘19’’ na frente do
ano automaticamente...
Algué diria: ‘‘Ora, a solução continua simples! Basta mudar os programas e base de dados para operar com data usando ano com quatro dígitos’’. Verdade cristalina. Mudar os programas é a parte mais simples. O problema está em determinar quais programas devem ser modificados.
É absolutamente inacreditável o número de programas com esse problema numa empresa. Se o leitor acredita que a sua está livre disso, que se prepare para as surpresas dentro de menos de um ano e meio. Nem mesmo as bios dos micros caseiros escapam... No mínimo, isso significará acertar a data do micro ‘‘na mão’’, diariamente.Arquivo FolhaVítimasComputadores domésticos e equipamentos de sistemas corporativos preocupam usuários de todo o mundo; conhecido como bug, o Y2K promete dores de cabeçaAgência O Globo

mockup