1752年，英国从儒略历转向了公历。我相信1752年9月的两周从未发生过，这对该地区的日期有影响。

一个解释: http://uneasysilence.com/archive/2007/08/12008/(互联网档案版)

对于那些真正想要一个巨大的惊喜的人。

如果您使用的是基于Linux/Unix的系统，那么您可以尝试以下包含cal命令的命令(如果它本身被使用，它将显示今天的日期)

cal 9 1752 ; cal

在线Linux终端，请点击这里。

使用1753年1月1日(1753-01-01)作为SQL Server中datetime的最小日期值的决定可以追溯到Sybase起源。

然而，这个日期本身的意义可以归结于这个人。

菲利普·斯坦霍普，切斯特菲尔德伯爵第四世。他带领英国议会通过了1750年日历(新风格)法案。这为英国及其当时的殖民地采用公历制定了法律。

在1752年英国日历中有一些缺失的日子(互联网档案链接)，当时终于对儒略历进行了调整。1752年9月3日至1752年9月13日失守。

卡伦·德莱尼是这样解释这个选择的

所以，浪费了12天，你怎么能 计算日期?比如，怎么能 计算两者之间的天数 1492年10月12日，1776年7月4日?做 你把失踪的12天也算进去了吗?来 避免解决这个问题， 最初的Sybase SQL Server 开发者决定不允许日期 在1753年之前。你可以提前存储 日期使用字符字段，但是 你不能使用任何datetime函数 你储存的较早的日期 在字符字段中。

选择1753年的日历似乎有点以英国为中心，因为在英国实施之前，许多欧洲天主教国家已经使用了170年的日历(最初由于教会的反对而推迟)。相反，许多国家直到1918年俄国才改革他们的历法。事实上，1917年十月革命是在公历的11月7日开始的。

Joe的回答中提到的datetime和新的datetime2数据类型都没有试图考虑这些本地差异，而是简单地使用公历。

datetime2的范围更大

SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)

返回

Sep  8 1752 12:00AM

关于datetime2数据类型的最后一点是，它使用向后投射到实际发明之前的预期公历，因此在处理历史日期方面用处有限。

这与其他软件实现形成对比，例如Java的公历类，默认遵循儒略历直到1582年10月4日，然后在新的公历中跳到1582年10月15日。它正确地处理了闰年日期之前的朱利安模型和该日期之后的格里高利历模型。调用者可以通过调用setGregorianChange()来更改转换日期。

在这里可以找到一篇相当有趣的文章，讨论了采用日历的更多特点。

Incidentally, Windows no longer knows how to correctly convert UTC to U.S. local time for certain dates in March/April or October/November of past years. UTC-based timestamps from those dates are now somewhat nonsensical. It would be very icky for the OS to simply refuse to handle any timestamps prior to the U.S. government's latest set of DST rules, so it simply handles some of them wrong. SQL Server refuses to process dates before 1753 because lots of extra special logic would be required to handle them correctly and it doesn't want to handle them wrong.

这是关于日期问题的整个故事，以及大型dbms如何处理这些问题。

During the period between 1 A.D. and today, the Western world has actually used two main calendars: the Julian calendar of Julius Caesar and the Gregorian calendar of Pope Gregory XIII. The two calendars differ with respect to only one rule: the rule for deciding what a leap year is. In the Julian calendar, all years divisible by four are leap years. In the Gregorian calendar, all years divisible by four are leap years, except that years divisible by 100 (but not divisible by 400) are not leap years. Thus, the years 1700, 1800, and 1900 are leap years in the Julian calendar but not in the Gregorian calendar, while the years 1600 and 2000 are leap years in both calendars. When Pope Gregory XIII introduced his calendar in 1582, he also directed that the days between October 4, 1582, and October 15, 1582, should be skipped—that is, he said that the day after October 4 should be October 15. Many countries delayed changing over, though. England and her colonies didn't switch from Julian to Gregorian reckoning until 1752, so for them, the skipped dates were between September 4 and September 14, 1752. Other countries switched at other times, but 1582 and 1752 are the relevant dates for the DBMSs that we're discussing. Thus, two problems arise with date arithmetic when one goes back many years. The first is, should leap years before the switch be calculated according to the Julian or the Gregorian rules? The second problem is, when and how should the skipped days be handled? This is how the Big DBMSs handle these questions: Pretend there was no switch. This is what the SQL Standard seems to require, although the standard document is unclear: It just says that dates are "constrained by the natural rules for dates using the Gregorian calendar"—whatever "natural rules" are. This is the option that DB2 chose. When there is a pretence that a single calendar's rules have always applied even to times when nobody heard of the calendar, the technical term is that a "proleptic" calendar is in force. So, for example, we could say that DB2 follows a proleptic Gregorian calendar. Avoid the problem entirely. 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. Pick 1582. This is what Oracle did. An Oracle user would find that the date-arithmetic expression October 15 1582 minus October 4 1582 yields a value of 1 day (because October 5–14 don't exist) and that the date February 29 1300 is valid (because the Julian leap-year rule applies). Why did Oracle go to extra trouble when the SQL Standard doesn't seem to require it? The answer is that users might require it. Historians and astronomers use this hybrid system instead of a proleptic Gregorian calendar. (This is also the default option that Sun picked when implementing the GregorianCalendar class for Java—despite the name, GregorianCalendar is a hybrid calendar.)

来源1和2

1752年，英国从儒略历转向了公历。我相信1752年9月的两周从未发生过，这对该地区的日期有影响。

一个解释: http://uneasysilence.com/archive/2007/08/12008/(互联网档案版)