1753年1月1日（1753-01-01）をSQL Serverの日時の最小日付値として使用する決定は、その Sybase origins に戻ります。
日付自体の重要性は、この男に起因する可能性があります。
フィリップ・スタンホープ、第4チェスターフィールド伯爵。誰が Calendar（New Style）Act 1750 を英国議会で操縦したか。これは、イギリスとその植民地にグレゴリオ暦を採用するために制定されました。
最終的にユリウス暦から調整が行われた1752年の英国暦には、いくつかの 欠落日 がありました。 1752年9月3日から1752年9月13日までが失われました。
Kalen Delaney explained この選択方法
では、12日間の損失で、どのように日付を計算できますか？たとえば、1492年10月12日から1776年7月4日までの日数をどのように計算できますか？不足している12日間を含めますか？この問題の解決を避けるために、元のSybase SQL Server開発者は、1753年より前の日付を許可しないことを決定しました。文字フィールドを使用して以前の日付を保存できますが、文字で保存する以前の日付で日時関数を使用することはできませんフィールド。
多くのカトリック諸国 がイギリスの実施の170年前にカレンダーを使用していたため（175教会による反対）。逆に、多くの諸国では、ロシアの1918年よりずっと後までカレンダーを変更しませんでした。実際、1917年の10月革命はグレゴリオ暦の下で11月7日に始まりました。
datetimeと Joeのanswer で言及されている新しいdatetime2データ型は両方とも、これらのローカルの違いを考慮せず、単にグレゴリオ暦。
datetime2の範囲を広げると
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)
返品
Sep 8 1752 12:00AM
datetime2データ型の最後のポイントは、 予測グレゴリオ暦 を使用することです。過去の日付の処理における限定的な使用。
これは、Java Gregorian Calendar クラスなどの他のソフトウェア実装とは対照的です。 1582年は、新しいグレゴリオ暦の1582年10月15日にジャンプします。その日付の前のうるう年のユリウスモデルとその日付の後のグレゴリオモデルを正しく処理します。カットオーバー日は、呼び出し元がsetGregorianChange()を呼び出すことで変更できます。
カレンダーの採用に関するいくつかの特徴 を議論するかなり面白い記事は、ここ にあります。
SQL Server 2008にアップグレードし、 DateTime2 データ型を使用する必要があります。これは、0001-01-01から9999-12-31までの範囲の日付をサポートします。
1752年は、イギリスがユリウス暦からグレゴリオ暦に切り替えた年です。その結果、1752年9月の2週間が起こったことは一度もないと私は信じています。
説明： http://uneasysilence.com/archive/2007/08/12008/ （ インターネットアーカイブ版 ）
これは、日付の問題がどのように発生し、Big DBMSがこれらの問題をどのように処理したかをまとめたものです。
西暦1月1日から今日までの間、西欧諸国は実際には2つの主なカレンダーを使用してきました。ユリウス・シーザーのユリウス暦と教皇グレゴリー13世のグレゴリオ暦です。 2つのカレンダーは、1つのルール、つまりうるう年が何であるかを決定するためのルールに関してのみ異なります。ユリウス暦では、4で割り切れる年はすべてうるう年です。グレゴリオ暦では、4で割り切れる年はすべてうるう年です。ただし、100で割り切れる（ただし400で割り切れない）年はうるう年ではありません。したがって、1700年、1800年、および1900年はユリウス暦ではうるう年ですがグレゴリオ暦ではありませんが、1600年および2000年は両方のカレンダでうるう年です。
1582年に教皇グレゴリー13世が彼のカレンダーを発表したとき、彼はまた1582年10月4日と1582年10月15日の間の日はスキップされるべきであると指示しました。しかし、切り替えを遅らせた。イングランドと彼女の植民地は、1752年までユリウスからグレゴリオ暦への切り替えを行わなかったので、それらについては、スキップされた日付は1752年9月4日から9月14日の間でした。我々が議論しているDBMS。
したがって、1つが何年も前にさかのぼるとき、2つの問題が日付の算術演算で発生します。 1つ目は、ユリウス暦またはグレゴリオ則に従ってスイッチが計算されるまでの閏年を計算する必要があるかどうかです。 2番目の問題は、スキップされた日がいつ、どのように処理されるべきかということです。
これがBig DBMSがこれらの質問を処理する方法です。
- スイッチがなかったふりをします。これは標準SQLでは要求されているように思われますが、標準文書は明確ではありません。日付は「グレゴリオ暦を使用した日付の自然な規則によって制約される」ということです。これはDB2が選択したオプションです。誰もそのカレンダーを聞いたことがないときにも、単一のカレンダーのルールが常に適用されているというふりがある場合、専門用語は「proleptic」カレンダーが有効であるということです。そのため、例えば、DB2はプロレプティックグレゴリオ暦に従っていると言えます。
- 問題を完全に避けてください。 MicrosoftとSybaseは、1753年1月1日に、アメリカがカレンダーを切り替えた時点を安全に過ぎて、最小日付値を設定しました。これは防御できますが、時折、これら2つのDBMSには他のDBMSが持っていて、SQL標準が要求する有用な機能が欠けているという不満が出てきます。
- 1582を選択してください。これはOracleがしたことです。 Oracleユーザーは、1582年10月15日から1582年10月4日を引いた日付算術式の値が1日になり（10月5日から14日は存在しないため）、日付は2900年2月29日に有効であることがわかります。年の規則が適用されます。標準SQLで要求されていないと思われるのに、なぜOracleが特別な問題に直面したのでしょうか。答えはユーザーがそれを要求するかもしれないということです。歴史家や天文学者たちは、このグレゴリオ暦の代わりにこのハイブリッドシステムを使っています。 （これは、GregorianCalendarクラスをJava用に実装するときにSunが選んだデフォルトのオプションでもあります。GregorianCalendarはハイブリッドカレンダーです。）
ちなみに、Windowsは、過去の年月の3月/ 4月または10月/ 11月の特定の日付について、UTCを米国の現地時間に正しく変換する方法を認識しなくなりました。これらの日付からのUTCベースのタイムスタンプは今やいくらか無意味です。米国政府の最新のDST規則より前のタイムスタンプを処理することをOSが単純に拒否するのは、OSにとって非常に厄介なことになるでしょう。 SQL Serverは、1753年より前の日付を処理することを拒否します。これは、それらを正しく処理するために多くの特別なロジックが必要になり、間違った処理をしたくないためです。