SQL Server中1/1/1753的意义是什么？
为什么1753？ 他们对1752有什么反应？ 我伟大伟大伟大伟大伟大的祖父会非常冒犯。
在SQL Server中使用1753年1月1日（ 1753-01-01 ）作为date时间的最小date值的决定可以追溯到它的Sybase起源 。
date本身的意义虽然可以归因于这个人。
菲利普·斯坦霍普，切斯特菲尔德的第四伯爵。 谁通过英国议会指导了1750年日历（新风格）法案 。 这为英国及其当时的殖民地通过了公历。
1752年英国历法上有一些失踪的日子 ，最后是从朱利安日历中作出调整。 1752年9月3日至1752年9月13日失踪。
Kalen Delaney 解释了这种select
所以，如果丢失了12天，你怎么计算date呢？ 例如，你如何计算1492年10月12日到1776年7月4日的天数？ 你包括那些失踪的12天吗？ 为了避免必须解决这个问题，原来的Sybase SQL Server开发人员决定不允许在1753年以前的date。您可以通过使用字符字段来存储更早的date，但是不能使用任何date时间函数与存储在字符中的较早date领域。
1753年的select似乎有些偏颇，但是由于欧洲的许多天主教国家在英国实施之前已经使用了170年的历法（最初由于教会的反对而推迟了 ）。 相反，许多国家直到1918年晚些时候才在俄罗斯改革日历。 事实上，1917年十月革命是在公历十一月七日开始的。
乔的答案中提到的datetime和新的datetime2数据types都不会考虑这些局部差异，只需使用公历。
所以有了更大的datetime2范围
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)
返回
Sep 8 1752 12:00AM
使用datetime2数据types的最后一点是，它使用预测的公历日历向后计算，以便在实际发明之前，因此在处理历史date方面的用处有限。
这与其他软件实现形成了鲜明对比，例如Java Gregorian Calendar类，它在默认情况下遵循Julian日历，直到1582年10月4日，然后跳到1582年10月15日的新Gregorian日历。 它正确地处理了那个date之前的闰年的朱利安模型和那个date之后的格里高利模型。 调用者可以通过调用setGregorianChange()来改变转换date。
在这里可以find一个相当有趣的文章，讨论通过日历的一些更多的特点。
你伟大的伟大伟大伟大伟大的祖父应该升级到SQL Server 2008，并使用DateTime2数据types，它支持date范围：0001-01-01到9999-12-31。
1752年是英国从朱利安切换到公历的一年。 我相信1752年9月的两个星期从来没有发生过，这对整个地区的date都有影响。
解释： http : //uneasysilence.com/archive/2007/08/12008/ （ 互联网档案版本 ）
这就是date问题的全貌，Big DBMS如何处理这些问题。
从公元一世纪到今天，西方世界实际上使用了两个主要日历：朱利叶斯·凯撒的儒略历和格列高利十三世的公历。 两个日历只有一个规则不同：决定什么是闰年的规则。 在儒略历中，可以被四整除的年份都是闰年。 在公历中，可以被四除的所有年份都是闰年，但可以被100除尽（但不能被400整除）的年份不是闰年。 因此，1700年，1800年和1900年是茱利亚历法上的闰年，而不是公历中的闰年，而1600年和2000年是两个历法上的闰年。
当教宗格列高利十三世在1582年介绍他的历法时，他还指示1582年10月4日至1582年10月15日之间的日子应该被跳过 – 也就是说，10月4日之后的那天应该是10月15日。但是延迟了。 英格兰和她的殖民地没有从朱利安到格里高利的转换，直到1752年，所以对他们来说，这些跳跃date是在1752年9月4日到9月14日之间。其他国家在其他时间转换，但1582年和1752年是相关date我们正在讨论的DBMS。
因此，当人们回溯多年时，数据算术会出现两个问题。 首先是应该按照朱利安或格里高利的规则计算闰年？ 第二个问题是，何时以及如何处理跳过的日子？
这就是大DBMS处理这些问题的方式：
- 假装没有开关。 这就是SQL标准所要求的，尽pipe标准文件还不清楚：它只是说date“受到公历使用date的自然规则的约束” – 不pipe“自然规则”是什么。 这是DB2select的选项。 假如一个日历的规则总是适用于没有人听说日历的时候，那么这个技术术语就是“预示性日历”正在生效。 所以，举例来说，我们可以说DB2遵循了一个格雷戈里的日历。
- 完全避免这个问题。 Microsoft和Sybase在1753年1月1日设置了最低date值，安全地超过了美国切换日历的时间。 这是可以防范的，但是时不时的投诉表明，这两个DBMS缺乏其他DBMS具有的且SQL标准所要求的有用function。
- select1582.这是Oracle做的。 Oracle用户会发现，1582年10月15日减去1582年10月4日的date – 算术expression式的值为1天（因为10月5日至14日不存在），并且2月29日1300date是有效的（因为Julian跳跃 – 年规则适用）。 为什么Oracle在SQL标准似乎并不需要的时候会遇到额外的麻烦？ 答案是用户可能需要它。 历史学家和天文学家使用这个混合系统，而不是一个预先格雷戈里日历。 （这也是Sun在实现Java的GregorianCalendar类时select的默认选项 – 尽pipe名称是GregorianCalendar，但它是混合日历。）
来源1和2
顺便说一句，在过去几年的三月/四月或十月/十一月，Windows不再知道如何将UTC正确转换为美国当地时间。 这些date的UTC时间戳现在有点荒谬。 如果操作系统在美国政府最新的DST规则之前拒绝处理任何时间戳，那将是非常恶劣的，所以它只是简单地处理了一些错误。 SQL Server拒绝在1753年之前处理date，因为需要大量额外的特殊逻辑来正确处理它们，并且不想处理它们错误。
