SQLと.NETの日付の違いだと思います データ型は、SQLServerの日時という事実に由来します。 データ型、最小値と最大値、および精度は.NETのDateTimeデータ型よりもはるかに古いです。
.NETの登場により、チームは日時データ型をより自然なものにする必要があると判断しました。 最小値であり、01/01/0001はかなり論理的な選択のようであり、確かにプログラミング言語からです。 、データベースではなく 視点から見ると、この値はより自然です。
ちなみに、SQL Server 2008には、実際に範囲と精度が向上し、.NETのDateTimeデータ型に密接に対応する新しい日付ベースのデータ型（Date、Time、DateTime2、DateTimeOffset）がいくつかあります。たとえば、DateTime2データ型の日付範囲は0001-01-01から9999-12-31です。
SQL Serverの標準の「datetime」データ型の最小値は常に01/01/1753でした（実際にはまだあります！）。認めざるを得ません。私もこの値の重要性に興味があったので、掘り下げました。私が見つけたのは次のとおりです。
西暦1年から今日までの期間、西側世界では実際に2つの主要な暦が使用されていました。ユリウス暦のユリウス暦と教皇グレゴリウス13世のグレゴリオ暦です。 2つのカレンダーは、うるう年を決定するためのルールという1つのルールのみが異なります。ユリウス暦では、4で割り切れるすべての年がうるう年です。グレゴリオ暦では、100で割り切れる年（ただし400で割り切れない年）がうるう年ではないことを除いて、4で割り切れるすべての年はうるう年です。したがって、1700年、1800年、および1900年は、ユリウス暦ではうるう年ですが、グレゴリオ暦ではありません。一方、1600年と2000年は、両方の暦でうるう年です。
教皇グレゴリウス13世が1582年に彼のカレンダーを紹介したとき、彼はまた、1582年10月4日から1582年10月15日までの日をスキップするように指示しました。ただし、切り替えが遅れました。イングランドとその植民地は1752年までジュリアンからグレゴリオ暦に切り替わっていなかったため、スキップされた日付は1752年9月4日から9月14日の間でした。私たちが議論しているDBMS。
したがって、1つが何年も前に戻ると、日付演算で2つの問題が発生します。 1つ目は、切り替えがジュリアンまたはグレゴリオ暦の規則に従って計算される前に、うるう年を計算する必要があるかどうかです。 2番目の問題は、スキップされた日をいつ、どのように処理する必要があるかということです。
これは、BigEightDBMSがこれらの質問を処理する方法です。
スイッチがなかったふりをします。これはSQL標準が要求しているように思われますが、標準ドキュメントは明確ではありません。日付は「グレゴリオ暦を使用する日付の自然規則によって制約される」とだけ書かれています。「自然規則」が何であれ。これは、DB2が選択したオプションです。誰もカレンダーのことを聞いていないときでも、単一のカレンダーの規則が常に適用されているというふりをする場合、専門用語は「プロレプティック」カレンダーが有効であるということです。したがって、たとえば、DB2は先発グレゴリオ暦に従っていると言えます。
問題を完全に回避します。 MicrosoftとSybaseは、アメリカがカレンダーを切り替えた時刻を安全に過ぎた1753年1月1日に最小日付値を設定しました。これは防御可能ですが、これら2つのDBMSには、他のDBMSが持つ有用な機能がなく、SQL標準が必要とするという苦情が時々表面化します。
1582を選択してください。これはOracleが行ったことです。 Oracleユーザーは、1582年10月15日から1582年10月4日を引いた日付算術式が1日の値を生成し（10月5〜14日が存在しないため）、1300年2月29日が有効である（ジュリアンうるう年のため）ことがわかります。年の規則が適用されます）。 SQL標準がそれを必要としないように見えるのに、なぜOracleは余分な問題を抱えたのですか？答えは、ユーザーがそれを必要とするかもしれないということです。歴史家や天文学者は、先発グレゴリオ暦の代わりにこのハイブリッドシステムを使用しています。 （これは、Java用のGregorianCalendarクラスを実装するときにSunが選択したデフォルトのオプションでもあります。名前にもかかわらず、GregorianCalendarはハイブリッドカレンダーです。）
この上記の引用は、次のリンクから引用したものです：
SQLパフォーマンスチューニング：SQLの日付