解释的时间太长了，但为了好奇，这里有一些片段。

> http://blogs.msdn.com/b/ericlippert/archive/2003/09/16/53013.aspx
> http://www.joelonsoftware.com/items/2006/06/16.html

1900 wasn’t a leap year.

“It’s a bug in Excel!” I exclaimed.

“Well,not really,” said Ed. “We had to do it that way because we need to be able to import Lotus 123 worksheets.”

“So,it’s a bug in Lotus 123?”

“Yeah,but probably an intentional one. Lotus had to fit in 640K. That’s not a lot of memory. If you ignore 1900,you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That’s really fast and easy. The Lotus guys probably figured it didn’t matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months,so they moved the epoch one day back.”

> http://www.cpearson.com/excel/datetime.htm

Actually,this number is one greater than the actual number of days. This is because Excel behaves as if the date 1900-Feb-29 existed. It did not. The year 1900 was not a leap year (the year 2000 is a leap year). In Excel,the day after 1900-Feb-28 is 1900-Feb-29. In reality,the day after 1900-Feb-28 was 1900-Mar-1 . This is not a “bug”. Indeed,it is by design. Excel works this way because it was truly a bug in Lotus 123. When Excel was introduced,123 has nearly the entire market for spreadsheet software. Microsoft decided to continue Lotus’ bug,in order to fully compatible. Users who switched from 123 to Excel would not have to make any changes to their data. As long as all your dates later than 1900-Mar-1,this should be of no concern.