Upprätthålla kompatibilitet med Lotus 1-2-3 förr i tiden, som hade en bugg i att den trodde att år 1900 var ett skottår (eller låtsades?).
Förklaringen är för lång för att citeras, men för nyfikenhetens skull kommer här några utdrag.
-
http://blogs.msdn.com/b/ericlippert/archive/2003/09/16/53013.aspx
-
http://www.joelonsoftware.com/items/2006/06/16.html
1900 var inget skottår.
"Det är en bugg i Excel!" utbrast jag.
"Tja, inte riktigt," sa Ed. "Vi var tvungna att göra det på det sättet eftersom vi måste kunna importera Lotus 123-kalkylblad."
"Så, det är en bugg i Lotus 123?"
"Ja, men förmodligen en avsiktlig sådan. Lotus var tvungen att passa in 640K. Det är inte mycket minne. Om du ignorerar 1900 kan du ta reda på om ett givet år är ett skottår bara genom att se om de två högra bitarna är noll. Det är väldigt snabbt och enkelt. Lotus-killarna trodde förmodligen att det inte spelade någon roll att ha fel för de två månaderna tidigare. Det ser ut som att Basic-killarna ville vara anala om dessa två månader, så de flyttade epok en dag sedan."
- http://www.cpearson.com/excel/datetime.htm
Detta antal är faktiskt en större än det faktiska antalet dagar. Detta beror på att Excel beter sig som om datumet 1900-29 februari existerade. Det gjorde det inte. År 1900 var inget skottår (år 2000 är ett skottår). I Excel är dagen efter 1900-28 februari 1900-29 februari. I verkligheten var dagen efter 1900-28 februari 1900-mars-1. Detta är inte en "bugg". Det är faktiskt designat. Excel fungerar på det här sättet eftersom det verkligen var en bugg i Lotus 123. När Excel introducerades hade 123 nästan hela marknaden för kalkylprogram. Microsoft beslutade att fortsätta Lotus bugg, för att vara helt kompatibel. Användare som bytte från 123 till Excel skulle inte behöva göra några ändringar i sina data. Så länge alla dina datum är senare än 1900-mars-1, borde detta inte vara något problem.