SQL Serverにおける1/1/1753の意味は何ですか？
回答:
1753年1月1日（1753-01-01）をSQL Serverの日時の最小日付値として使用するという決定は、Sybaseの起源に戻ります。
日付自体の重要性はこの男に帰することができます。
フィリップ・スタンホープ、チェスターフィールドの第4伯爵。誰が英国議会を通じてカレンダー（新式）法1750を運営したか。これはイギリスとその当時の植民地のためのグレゴリオ暦の採用のための法律でした。
1752年のイギリスのカレンダーでは、ユリウス暦からようやく調整が行われた日がいくつかありました（インターネットアーカイブリンク）。1752年9月3日から1752年9月13日までに亡くなりました。
では、12日が失われた場合、日付をどのように計算できますか？たとえば、1492年10月12日から1776年7月4日までの日数をどのように計算できますか？欠落している12日間を含めますか？この問題を解決する必要がないように、元のSybase SQL Server開発者は1753より前の日付を許可しないことを決定しました。文字フィールドを使用して以前の日付を保存できますが、文字に保存した以前の日付の日付時刻関数は使用できません。田畑。
1753年の選択はややアングロセントリックのように見えますが、ヨーロッパの多くのカトリック国がイギリスの実装より前に170年間カレンダーを使用していたため（当初は教会の反対により遅れていました）。逆に、多くの国では、1918年にロシアでカレンダーが改定されました。実際、1917年の10月の革命は、グレゴリオ暦の下で11月7日に始まりました。
両方datetimeと、ジョーの回答でdatetime2述べられている新しいデータ型は、これらのローカルな違いを考慮せず、単にグレゴリオ暦を使用します。
したがって、より広い範囲で datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)戻り値
Sep 8 1752 12:00AMdatetime2データ型の最後のポイントの1つは、実際に発明される前にさかのぼって前向きに予測されたグレゴリオ暦のカレンダーを使用することです。
これは、1582年10月4日までの日付のユリウス暦をデフォルトで追跡し、新しいグレゴリオ暦で1582年10月15日にジャンプするJava Gregorian Calendarクラスなどの他のソフトウェア実装とは対照的です。それはその日付の前のうるう年のユリウスモデルとその日付の後のグレゴリオモデルを正しく処理します。カットオーバー日付は、発信者がを呼び出して変更できますsetGregorianChange()。
カレンダーの採用に伴ういくつかの特殊性について論じているかなり面白い記事はここにあります。
あなたの偉大な偉大な偉大な偉大な偉大な祖父はSQL Server 2008にアップグレードし、0001-01-01から9999-12-31の範囲の日付をサポートするDateTime2データ型を使用する必要があります。
1752年はイギリスがユリウス暦からグレゴリオ暦に切り替わった年でした。結果として、1752年9月の2週間は決して起こらなかったと思います。これは、その一般的な領域の日付に影響を与えます。
説明：http : //uneasysilence.com/archive/2007/08/12008/（インターネットアーカイブバージョン）
これは、日付の問題がどのように発生し、Big DBMSがこれらの問題をどのように処理したかについての全体像です。
西暦1年から今日までの期間、西側世界では2つの主要な暦が使用されました。ジュリアスシーザーのユリウス暦と教皇グレゴリー13世のグレゴリオ暦です。2つのカレンダーは、うるう年とは何かを決定するための規則という1つの規則のみが異なります。ユリウス暦では、4で割り切れる年はすべてうるう年です。グレゴリオ暦では、4で割り切れる年はすべてうるう年です。ただし、100で割り切れる年（400で割り切れない年）はうるう年ではありません。したがって、1700年、1800年、および1900年は、ユリウス暦ではうるう年ですが、グレゴリオ暦ではありませんが、1600年と2000年は両方の暦でうるう年です。
教皇グレゴリー13世が1582年に彼のカレンダーを導入したとき、彼はまた、1582年10月4日から1582年10月15日までの日はスキップされるべきであると指示しました。しかし、乗り換えが遅れた。イングランドとその植民地は1752年までジュリアンからグレゴリオ暦に切り替わらなかったため、スキップされた日付は1752年9月4日から9月14日の間でした。他の国は他の時期に切り替わりましたが、1582年と1752年がこれから説明するDBMS。
したがって、何年も前に遡ると、日付演算に2つの問題が発生します。1つ目は、切り替えの前のうるう年をユリウス暦またはグレゴリオ暦に従って計算する必要があるかどうかです。2番目の問題は、スキップされた日をいつ、どのように処理する必要があるかです。
Big DBMSがこれらの質問を処理する方法は次のとおりです。
- スイッチがなかったふりをします。これは、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はハイブリッドカレンダーです。）