Opretholdelse af kompatibilitet med Lotus 1-2-3 dengang, som havde en fejl, idet den troede, at år 1900 var et skudår (eller foregav?).
Forklaringen er for lang til at citere, men for nysgerrighedens skyld er her nogle uddrag.
-
http://blogs.msdn.com/b/erilippert/archive/2003/09/16/53013.aspx
-
http://www.joelonsoftware.com/items/2006/06/16.html
1900 var ikke et skudår.
"Det er en fejl i Excel!" udbrød jeg.
"Nå, egentlig ikke," sagde Ed. "Vi var nødt til at gøre det på den måde, fordi vi skal være i stand til at importere Lotus 123-regneark."
"Så det er en fejl i Lotus 123?"
"Ja, men sandsynligvis en bevidst en. Lotus skulle passe ind i 640K. Det er ikke meget hukommelse. Hvis du ignorerer 1900, kan du finde ud af, om et givet år er et skudår, bare ved at se om de to længst til højre bits er nul. Det er virkelig hurtigt og nemt. Lotus-fyrene tænkte nok, at det ikke gjorde noget at tage fejl for de to måneder tidligere. Det ser ud til, at Basic-fyrene ville være anale om de to måneder, så de flyttede epoke en dag tilbage."
- http://www.cpearson.com/excel/datetime.htm
Faktisk er dette tal én større end det faktiske antal dage. Dette skyldes, at Excel opfører sig, som om datoen 1900-29-feb eksisterede. Det gjorde den ikke. Året 1900 var ikke et skudår (året 2000 er et skudår). I Excel er dagen efter 1900-28-feb 1900-29-feb. I virkeligheden var dagen efter 1900-28. februar 1900-mars-1. Dette er ikke en "bug". Det er faktisk ved design. Excel fungerer på denne måde, fordi det virkelig var en fejl i Lotus 123. Da Excel blev introduceret, havde 123 næsten hele markedet for regnearkssoftware. Microsoft besluttede at fortsætte Lotus' fejl for at blive fuldt kompatibel. Brugere, der skiftede fra 123 til Excel, skulle ikke foretage ændringer i deres data. Så længe alle dine datoer er senere end 1900-mar-1, bør dette ikke være til bekymring.