我认为SQL和.NET的Date种数据类型源于这样一个事实:SQL Server的datetime种数据类型、最小值和最大值，以及它的精度都比SQL Server旧得多.NET的日期时间数据类型.
随着新技术的出现.NET中，团队决定Datetime数据类型的最小值应该大于natural，01/01/0001似乎是一个相当合理的 Select ，当然从programming language而不是database的Angular 来看，这个值更自然.
顺便说一句，在SQL Server 2008中，有许多新的基于日期的数据类型(Date、Time、DateTime2、DateTimeOffset)，它们确实提供了更大的范围和精度，并与中的日期时间数据类型紧密地对应.网例如，DateTime2数据类型的日期范围为0001-01-01到9999-12-31.
SQL Server的标准"datetime"数据类型的最小值始终为01/01/1753(事实上仍然如此！).我必须承认，我也很好奇这个价值观的意义，所以进行了一些挖掘..我的发现如下:
从公元1年到今天，西方世界实际上使用了两种主要的历法:朱利叶斯·凯撒的儒略历和教皇格里高利十三世的格里高利历.这两种历法只有一条规则不同:决定闰年的规则.在儒略历法中，所有可被四除的年份都是闰年.在公历中，所有被四整除的年份都是闰年，但被100整除(但不能被400整除)的年份不是闰年.因此，1700年、1800年和1900年在儒略历中是闰年，但在公历中不是，而1600年和2000年在这两种历法中都是闰年.
1582年，教皇格雷戈里十三世提出他的日历时，他还指示应跳过1582年10月4日至1582年10月15日之间的日期，也就是说，10月4日之后的一天应为10月15日.不过，许多国家推迟了转型.英格兰和她的殖民地直到1752年才从朱利安清算改为格里高利清算，所以对他们来说，跳过的日期是1752年9月4日至9月14日.其他国家在其他时间切换，但1582年和1752年是我们正在讨论的DBMS的相关日期.
因此，当一个问题追溯到多年前时，日期算法会出现两个问题.第一个问题是，转换前的闰年应该按照朱利安规则还是格里高利规则计算？第二个问题是，何时以及如何处理跳过的天数？
这就是八 Big Data 库管理系统处理这些问题的方式:
假装没有switch .这似乎是SQL标准的要求，尽管标准文档并不清楚:它只是说日期"受公历日期的自然规则约束"——不管"自然规则"是什么.这是DB2 Select 的选项.当有人假装一个日历的规则总是适用于甚至没有人听说过日历的时候，技术术语是"proleptic"日历生效.例如，我们可以说DB2遵循公历.
完全避免这个问题.Microsoft and Sybase set their minimum date values at January 1, 1753, safely past the time that America switched calendars. This is defendable, but from time to time complaints surface that these two DBMSs lack a useful functionality that the other DBMSs have and that the SQL Standard requires.
Select 1582.这就是甲骨文所做的.Oracle用户会发现，日期算术表达式10月15日1582减go 10月4日1582得出的值为1天(因为10月5日至14日不存在)，日期2月29日1300有效(因为朱利安闰年规则适用).当SQL标准似乎不需要Oracle时，为什么Oracle会遇到额外的麻烦？答案是用户可能需要它.历史学家和天文学家使用这种混合系统，而不是公历.(这也是Sun在为Java实现GregorianCalendar类时 Select 的默认选项，尽管名称不同，GregorianCalendar是一种混合日历.)
以上引文摘自以下链接: