SqlDateTime.MinValue != DateTime.MinValue，為什麼？
我想知道，為什麼 SqlDateTime.MinValue 與 DateTime.MinValue 不一樣？
我認為 SQL 和 .NET 的Date數據類型之間的差異源於 SQL Server 的datetime數據類型，它的最小值和最大值，以及它的精度比 .NET 的 DateTime 數據類型老得多。
隨著 .NET 的出現，團隊決定 Datetime 數據類型應該有一個更自然的 最小值，而 01/01/0001 似乎是一個相當合乎邏輯的選擇，當然從程式語言而不是數據庫的角度來看，這個值是更自然。
順便說一句，在 SQL Server 2008 中，有許多新的基於日期的數據類型（Date、Time、DateTime2、DateTimeOffset）實際上確實提供了更大的範圍和精度，並且與 .NET 中的 DateTime 數據類型緊密映射。例如，DateTime2 數據類型的日期範圍為 0001-01-01 到 9999-12-31。
SQL Server 的標準“日期時間”數據類型的最小值始終為 1753 年 1 月 1 日（實際上仍然如此！）。我必須承認，我也很好奇這個值的意義，所以做了一些探勘。我發現如下：
從公元 1 年到今天，西方世界實際上使用了兩種主要的曆法：凱撒大帝的儒略歷和教皇格列高利十三世的公曆。兩種曆法的不同之處僅在於一條規則：決定閏年的規則。在儒略歷中，所有能被四整除的年份都是閏年。在公曆中，所有能被 4 整除的年份都是閏年，除了能被 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。
因此，當一個回溯多年時，日期算術會出現兩個問題。第一個是，轉換前的閏年應該按照儒略規則還是公曆規則計算？第二個問題是，應該何時以及如何處理跳過的天數？
這就是八大 DBMS 處理這些問題的方式：
- 假裝沒有開關。這似乎是 SQL 標準所要求的，儘管標准文件不清楚：它只是說日期“受使用公曆日期的自然規則的約束”——無論“自然規則”是什麼。這是 DB2 選擇的選項。如果假裝單一日曆的規則始終適用於沒有人聽說過該日曆的時間，則技術術語是“預測”日曆有效。因此，例如，我們可以說 DB2 遵循一個預測的公曆。
- 完全避免這個問題。 Microsoft 和 Sybase 將它們的最小日期值設置為 1753 年 1 月 1 日，安全地超過了美國切換日曆的時間。這是可以辯護的，但有時會出現抱怨，這兩個 DBMS 缺乏其他 DBMS 所具有的有用功能，而 SQL 標準要求這些功能。
- 選擇 1582。這就是 Oracle 所做的。Oracle 使用者會發現日期算術表達式 1582 年 10 月 15 日減去 1582 年 10 月 4 日得出的值為 1 天（因為 10 月 5 日至 14 日不存在）並且日期 1300 年 2 月 29 日是有效的（因為儒略閏-年規則適用）。當 SQL 標準似乎沒有要求時，為什麼 Oracle 還要額外麻煩？答案是使用者可能需要它。歷史學家和天文學家使用這種混合系統而不是預測的公曆。（這也是 Sun 在為 Java 實現 GregorianCalendar 類時選擇的預設選項——儘管名稱如此，但 GregorianCalendar 是一個混合日曆。）
以上引文摘自以下連結：