Queres um truque para impressionar? Abre uma folha em branco, escreve o número 60 numa célula do Excel e formata-a como data. O Excel vai dizer-te, com toda a confiança, que esse dia é 29 de fevereiro de 1900. Agora vai a um calendário: 1900 não foi ano bissexto. Fevereiro teve 28 dias, ponto final, e o 29 de fevereiro de 1900 pura e simplesmente nunca existiu. E, no entanto, o programa mais usado do mundo empresarial tem lá esse dia fantasma e quem o mantém sabe que está errado, sabe-o há quarenta anos, e decidiu deixá-lo exatamente onde está.
Célula do Excel: porque é que 1900 não foi bissexto
A regra dos anos bissextos é mais manhosa do que parece. Um ano é bissexto se for divisível por 4, mas os anos de fim de século (os que acabam em 00) são a exceção: só contam se forem divisíveis por 400. Ora, 1900 divide por 100 mas não por 400. Resultado: apesar de ser divisível por 4, não teve dia 29 de fevereiro. É uma regra criada precisamente para apagar dias como esse. E foi esse dia apagado que acabou a viver dentro do teu Excel para sempre.
De onde veio o erro
A culpa não é sequer da Microsoft. Recua a 1983, a um programa chamado Lotus 1-2-3, a folha de cálculo que dominou as finanças das empresas nos anos 80. Na altura, os computadores tinham uma memória ridícula para os padrões de hoje, menos do que uma única foto do teu telemóvel ocupa agora. Para poupar espaço, o Lotus guardava cada data como um simples número de contagem: 1 de janeiro de 1900 era o número 1, o dia seguinte o 2, e assim por diante.
O problema eram os bissextos. Fazer a verificação completa dava trabalho ao processador, por isso os criadores do Lotus cortaram caminho: perguntavam só “o ano divide por 4?”. Era uma conta quase instantânea e acertava em praticamente todos os anos que alguém escreveria numa folha. A rara exceção era 1900, que passou como bissexto e ganhou um 29 de fevereiro que nunca lá esteve. Nascia o dia fantasma.
E a Microsoft copiou o erro… de propósito
Aqui está a parte que ainda hoje faz levantar sobrancelhas. Quando a Microsoft lançou o Excel e o quis impor no mundo empresarial, tinha um obstáculo enorme: o Lotus 1-2-3 dominava tudo. Ninguém troca a folha de cálculo onde vivem os números da empresa inteira, a não ser que a alternativa seja perfeita. E “perfeita”, aqui, queria dizer uma coisa muito específica: o Excel tinha de abrir um ficheiro do Lotus e reproduzir cada número igualzinho, até à última casa decimal.
Os engenheiros da Microsoft conheciam a regra dos bissextos na perfeição. Corrigir o erro seria trivial. Mas corrigi-lo faria as datas do Excel ficarem desalinhadas em relação a todos os ficheiros do Lotus que existiam no mundo e a compatibilidade era todo o argumento de venda. Por isso tomaram a decisão que ainda hoje se comenta: copiaram o erro de propósito. O 29 de fevereiro de 1900 ficou lá, cravado à mão, herdado por escolha.
Afinal, isto é grave?
A boa notícia é que, para 99% do que fazes numa folha de cálculo, este erro não faz absolutamente nada. Ele esconde-se porque se anula a si próprio. Se calculares os dias entre duas datas modernas, ambas carregam o mesmo desvio de um dia e, quando o Excel as subtrai, o dia a mais aparece nos dois lados e desaparece na conta. Só te morde em casos raros: trabalho histórico com datas anteriores a março de 1900, ou quando passas datas em bruto do Excel para outros sistemas que usam um calendário verdadeiro.
A Microsoft até pôs isto por escrito e defende a decisão: corrigir o erro traria mais problemas do que vantagens. E é assim que um atalho que dois programadores usaram para poupar uns bytes em 1983 é, hoje, um “defeito” oficialmente documentado que ninguém vai corrigir. Quando a correção e a compatibilidade entram em guerra, a correção quase nunca ganha.
