SqlDateTime.Параметр minvalue!= значение datetime.Параметр minvalue, почему?

Я думаю, что разница между SQL и .NET дата типы данных проистекают из того факта, что SQL Server datetime тип данных, это минимальные и максимальные значения, и это точность намного старше, чем тип данных DateTime .NET.

с появлением .NET команда решила, что тип данных Datetime должен иметь больше естественные минимальное значение, и 01/01/0001 кажется довольно логичным выбором, и, конечно, с Программирование язык, а не база данных перспектива, это значение более естественно.

кстати, в SQL Server 2008 существует ряд новых типов данных на основе дат (дата,времени,тип 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 годы являются високосными годами в обоих календарях.

таким образом, две проблемы возникают с арифметикой даты, когда один возвращается много лет назад. Во-первых, должны ли високосные годы до перехода быть рассчитаны в соответствии с Юлианскими или Григорианскими правилами? Вторая проблема заключается в том, когда и как следует обрабатывать пропущенные дни?

вот как Большая восьмерка СУБД обрабатывает эти вопросы:

• притворись, что выключателя не было. Это что, по-видимому, требует стандарт SQL, хотя стандартный документ неясен: он просто говорит, что даты "ограничены естественными правилами для дат с использованием григорианского календаря" - каковы бы ни были "естественные правила". Это вариант, который выбрала DB2. Когда есть предположение, что правила одного календаря всегда применялись даже к тем временам, когда никто не слышал о календаре, технический термин заключается в том, что действует "пролептический" календарь. Так, например, мы могли бы сказать, что DB2 следует преждевременно Григорианский календарь.

• полностью избежать проблем. Microsoft и Sybase установили свои минимальные значения даты на 1 января 1753 года, благополучно миновав время, когда Америка переключила календари. Это можно защитить, но время от времени появляются жалобы на то, что эти две СУБД не имеют полезной функциональности, которую имеют другие СУБД, и что требуется стандарт SQL.

• выбрать 1582. Вот что сделал Оракул. Пользователь Oracle найдет что арифметическое выражение даты 15 октября 1582 минус 4 октября 1582 дает значение 1 день (потому что 5-14 октября не существует) и что дата 29 февраля 1300 действительна (потому что применяется правило юлианского високосного года). Почему Oracle пошел на дополнительные проблемы, когда стандарт SQL, похоже, не требует этого? Ответ заключается в том, что пользователи могут потребовать его. Историки и астрономы используют эту гибридную систему вместо пролептического григорианского календаря. (Это также опция по умолчанию, которую Солнце выбрало, когда реализация класса GregorianCalendar для Java-несмотря на название, GregorianCalendar является гибридным календарем.)

эта цитата выше взята из следующей ссылки:

настройка производительности SQL: даты в SQL