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

与Lotus1-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年不是闰年。

“这是Excel中的错误!”我大声喊道。

“嗯,不是真的,”Ed说,“我们必须这样做,因为我们需要能够导入Lotus123工作表。”

“那么,这是Lotus123中的一个bug?”

“是的,但可能是故意的。莲花需要640K的内存,内存不够。如果忽略1900,您可以通过查看最右边的两位是否为零来判断给定年份是否为闰年。这真的很快很容易。在过去的两个月里,荷花人可能认为错误并不重要。这两个月来,基本的人似乎都想做一个肛门手术,所以有一天他们又重新开始了新纪元。”

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

实际上,这个数字比实际天数大一个。这是因为Excel的行为就像1900-Feb-29的日期一样。它没有。1900年不是闰年(2000年是闰年)。在excel中,1900-feb-28之后的一天是1900-feb-29。实际上,1900年2月28日之后的一天是1900年3月1日。这不是一个“错误”。的确,这是设计出来的。Excel是这样工作的,因为它确实是Lotus123中的一个bug。当推出Excel时,123几乎占据了电子表格软件的整个市场。为了完全兼容,微软决定继续使用Lotus的bug。从123切换到Excel的用户不必对其数据进行任何更改。只要你所有的日期都迟于1900年3月1日,这应该是没有关系的。

据我所知,“旧的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中日期类型的向后兼容性已被破坏。

对于定义不明确或不正确的问题,回答(和投票)毫无意义。

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

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

为了击败本地时钟操作,有人打卡进来,我询问了SQL集群实例的时间。

它无法获取有效的活动时间源并返回此日期。

我的解决方法是直接在我的 GetServerTime 如果返回此“默认值”,则使用本地PC时间。

我在SQL 2000/2005/2008中看到过这个,都是通过ADO和VB6实现的。