Mantendo a compatibilidade com o Lotus 1-2-3 no passado, que tinha um bug em que pensava que o ano de 1900 era um ano bissexto (ou fingido?).
A explicação é muito longa para citar, mas por uma questão de curiosidade, aqui estão alguns trechos.
-
http://blogs.msdn.com/b/ericlippert/archive/2003/09/16/53013.aspx
-
http://www.joelonsoftware.com/items/2006/06/16.html
1900 não foi um ano bissexto.
"É um bug no Excel!" exclamei.
"Bem, na verdade não", disse Ed. "Tivemos que fazer assim porque precisamos importar planilhas do Lotus 123."
"Então, é um bug no Lotus 123?"
"Sim, mas provavelmente intencional. Lotus teve que caber em 640K. Isso não é muita memória. Se você ignorar 1900, você pode descobrir se um determinado ano é um ano bissexto apenas olhando para ver se os dois bits mais à direita são zero. Isso é muito rápido e fácil. Os caras da Lotus provavelmente acharam que não importava estar errado naqueles dois meses no passado. Parece que os caras do Basic queriam ser anal sobre esses dois meses, então eles mudaram o época um dia atrás."
- http://www.cpearson.com/excel/datetime.htm
Na verdade, esse número é um a mais do que o número real de dias. Isso ocorre porque o Excel se comporta como se a data 1900-Fev-29 existisse. Não. O ano de 1900 não foi bissexto (o ano de 2000 é bissexto). No Excel, o dia após 28 de fevereiro de 1900 é 29 de fevereiro de 1900. Na realidade, o dia seguinte a 28 de fevereiro de 1900 foi 1 de março de 1900. Isso não é um "bug". Na verdade, é por design. O Excel funciona dessa maneira porque era realmente um bug no Lotus 123. Quando o Excel foi lançado, o 123 tinha quase todo o mercado de software de planilhas. A Microsoft decidiu continuar com o bug da Lotus, a fim de ser totalmente compatível. Os usuários que mudaram de 123 para Excel não precisariam fazer nenhuma alteração em seus dados. Contanto que todas as suas datas sejam posteriores a 1º de março de 1900, isso não deve ser motivo de preocupação.
