Мисля, че разликата между Дата на SQL и .NET типовете данни произтичат от факта, че datetime на SQL Server тип данни, минималните и максималните стойности и прецизността му са много по-стари от типа данни DateTime на .NET.
С появата на .NET екипът реши, че типът данни Datetime трябва да има по-естествен минимална стойност и 01/01/0001 изглежда доста логичен избор и със сигурност от език за програмиране , а не база данни от гледна точка, тази стойност е по-естествена.
Между другото, със SQL Server 2008 има редица нови типове данни, базирани на дата (Date, Time, DateTime2, DateTimeOffset), които всъщност предлагат увеличен обхват и прецизност и се съпоставят тясно с типа данни DateTime в .NET. Например типът данни DateTime2 има диапазон от дати от 0001-01-01 до 9999-12-31.
Стандартният тип данни "datetime" на SQL Server винаги е имал минимална стойност от 01/01/1753 (и наистина все още има!). Трябва да призная, че и аз бях любопитен относно значението на тази стойност, така че направих и малко копаене. Това, което открих, беше следното:
През периода между 1 и днес западният свят всъщност е използвал два основни календара:Юлианския календар на Юлий Цезар и Григорианския календар на папа Григорий XIII. Двата календара се различават само по едно правило:правилото за определяне на това какво е високосна година. В Юлианския календар всички години, делими на четири, са високосна. В григорианския календар всички години, делими на четири, са високосна, с изключение на това, че годините, делими на 100 (но не и на 400), не са високосна. Така годините 1700, 1800 и 1900 са високосна в юлианския календар, но не и в григорианския, докато годините 1600 и 2000 са високосна и в двата календара.
Когато папа Григорий XIII представи своя календар през 1582 г., той също така нареди дните между 4 октомври 1582 г. и 15 октомври 1582 г. да бъдат пропуснати – тоест той каза, че денят след 4 октомври трябва да бъде 15 октомври. Много страни забавено преминаване обаче. Англия и нейните колонии не преминават от юлианско към григорианско изчисление до 1752 г., така че за тях пропуснатите дати са между 4 септември и 14 септември 1752 г. Други държави преминават през друго време, но 1582 и 1752 са съответните дати за СУБД, които обсъждаме.
По този начин възникват два проблема с аритметиката за дати, когато човек се върне много години назад. Първото е, трябва ли високосните години преди смяната да се изчисляват според юлианските или григорианските правила? Вторият проблем е кога и как трябва да се обработват пропуснатите дни?
Ето как големите осем СУБД се справят с тези въпроси:
Преструвайте се, че няма превключвател. Това изглежда изисква SQL стандартът, въпреки че стандартният документ е неясен:той просто казва, че датите са „ограничени от естествените правила за дати, използващи григорианския календар“ — каквито и „естествени правила“ да са. Това е опцията, която DB2 избра. Когато има претенция, че правилата на един календар винаги са се прилагали дори за моменти, когато никой не е чувал за календара, техническият термин е, че е в сила „пролептичен“ календар. Така, например, можем да кажем, че DB2 следва пролептичен григориански календар.
Избягвайте напълно проблема. Microsoft и Sybase задават своите минимални стойности за дата на 1 януари 1753 г., безопасно след времето, когато Америка смени календара. Това може да се защити, но от време на време се появяват оплаквания, че тези две СУБД нямат полезна функционалност, която другите СУБД имат и която SQL стандартът изисква.
Изберете 1582. Това направи Oracle. Потребител на Oracle ще открие, че аритметичният израз за дата 15 октомври 1582 минус 4 октомври 1582 дава стойност от 1 ден (тъй като 5-14 октомври не съществува) и че датата 29 февруари 1300 е валидна (защото Юлианският скок- се прилага правилото за годината). Защо Oracle си създаде допълнителни проблеми, когато SQL стандартът изглежда не го изисква? Отговорът е, че потребителите може да го изискват. Историци и астрономи използват тази хибридна система вместо пролептичен григориански календар. (Това също е опцията по подразбиране, която Sun избра при внедряването на класа GregorianCalendar за Java — въпреки името, GregorianCalendar е хибриден календар.)
Този по-горе цитат е взет от следния линк:
Настройка на производителността на SQL:Дати в SQL
