Question

更多是出于好奇而不是任何真正的问题;这个问题今天出现了，我知道我已经看到1899-12-30用作Access中的“默认”日期和零日期以及较旧的SQL Server应用程序。只是想知道为什么 - 它来自哪里，为什么不使用1899-12-31？

Answer 1

当天维持与Lotus 1-2-3的兼容性，这有一个错误，因为它认为1900年是闰年（或假装？）。

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

1900年不是闰年。

“这是Excel中的一个错误！”我大声说道。
     “嗯，不是真的，”艾德说。 “我们必须这样做，因为我们需要能够导入Lotus 123工作表。”

“那么，它是Lotus 123中的一个错误？”

“是的，但可能是故意的。莲花必须适合640K。这不是很多记忆。如果你忽略了1900年，你可以通过查看是否只是看看是否一年是一个闰年最右边的两位是零。这真的很快又简单。莲花家伙可能认为过去这两个月的方式并不重要。看起来那些基本的家伙想要在那两个月做肛门，所以他们有一天回到了这个时代。“

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

实际上，这个数字比实际天数大一个。这是因为Excel的行为就像1900年2月29日的日期一样。它没。 1900年不是闰年（2000年是闰年）。在Excel中，1900年2月28日之后的那一天是1900年2月29日。实际上，1900年至2月28日的那一天是1900年3月1日。这不是一个“错误”。确实，这是设计上的。 Excel以这种方式工作，因为它确实是Lotus 123中的一个错误。当引入Excel时，123几乎拥有电子表格软件的整个市场。微软决定继续使用Lotus的bug，以便完全兼容。从123切换到Excel的用户不必对其数据进行任何更改。只要你的所有日期都晚于1900年3月1日，这应该是无关紧要的。

Answer 2

如果SQL Server无法联系到其定义的时间源，则SQL Server似乎将此日期作为默认日期返回。

当我的生物识别考勤系统正在运行/正在使用时，我在群集故障转移事件期间发生了这种情况。

为了打败本地时钟操作，有人进入，我问SQL集群实例现在是什么时候。

它无法获得有效的有效时间来源并返回此日期。

对我来说，通过在我的GetServerTime Sub中检查此日期并使用本地PC时间（如果此默认＆＃39;归还。

我已经通过SQL 2000/2005/2008看到了这一切，都通过ADO和VB6。

Answer 3

据我所知，“旧SQL Server”中不存在日期类型。它是在SQL Server 2008中引入的，具有对应于0001/01/01的零日期值。

select cast(0x000000 as date),cast(CONVERT(date, '0001/01/01') as varbinary(max)) 
----------     --------
--0001-01-01   0x000000

问题陈述没有意义。如果日期类型存在于“较旧的SQL Server”中，则会暗示SQL Server 2008中日期类型的向后兼容性已损坏。

对于未定义或定义不正确的问题，回答（和upvote帖子）没有意义。

为什么1899-12-30是Access / SQL Server中的零日期而不是12/31？

3 个答案: