出于好奇心而不是任何真正的问题;这个问题今天出现了，我知道我已经看到1899-12-30用作Access中的“默认”日期和零日期以及较旧的SQL Server应用程序。只是想知道为什么 – 它来自哪里，为什么不使用1899-12-31？
解决方法
在当天保持与Lotus 1-2-3的兼容性，这有一个错误，它认为1900年是闰年(或假装？)。
解释的时间太长了，但为了好奇，这里有一些片段。
> 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.
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
