Myślę, że różnica między Data SQL i .NET typy danych wynikają z faktu, że datetime . serwera SQL Server typ danych, jego minimalna i maksymalna wartość, a jego precyzja jest znacznie starsza niż typ danych DateTime w .NET.
Wraz z pojawieniem się platformy .NET zespół zdecydował, że typ danych Datetime powinien mieć bardziej naturalny minimalna wartość, a 01/01/0001 wydaje się dość logicznym wyborem, i to z pewnością z języka programowania , a nie baza danych perspektywy, ta wartość jest bardziej naturalna.
Nawiasem mówiąc, w SQL Server 2008 istnieje wiele nowych typów danych opartych na Dacie (Date, Time, DateTime2, DateTimeOffset), które faktycznie oferują zwiększony zakres i precyzję oraz są ściśle odwzorowane na typ DateTime w .NET. Na przykład typ danych DateTime2 ma zakres dat od 0001-01-01 do 9999-12-31.
Standardowy typ danych "datetime" SQL Server zawsze miał minimalną wartość 01/01/1753 (i rzeczywiście nadal ma!). Muszę przyznać, że ja też byłem ciekaw znaczenia tej wartości, więc trochę kopałem.. Odkryłem:
W okresie od 1 naszej ery do dziś świat zachodni używał właściwie dwóch głównych kalendarzy:kalendarza juliańskiego Juliusza Cezara i kalendarza gregoriańskiego papieża Grzegorza XIII. Te dwa kalendarze różnią się tylko jedną zasadą:zasadą decydowania o tym, czym jest rok przestępny. W kalendarzu juliańskim wszystkie lata podzielne przez cztery to lata przestępne. W kalendarzu gregoriańskim wszystkie lata podzielne przez cztery są latami przestępnymi, z wyjątkiem tego, że lata podzielne przez 100 (ale nie podzielne przez 400) nie są latami przestępnymi. Tak więc lata 1700, 1800 i 1900 są latami przestępnymi w kalendarzu juliańskim, ale nie w kalendarzu gregoriańskim, podczas gdy lata 1600 i 2000 są latami przestępnymi w obu kalendarzach.
Kiedy papież Grzegorz XIII wprowadził swój kalendarz w 1582 r., polecił również, aby dni między 4 października 1582 a 15 października 1582 zostały pominięte — to znaczy powiedział, że dzień po 4 października powinien przypadać 15 października. Wiele krajów jednak opóźnione przejście. Anglia i jej kolonie nie przestawiły się z rachuby juliańskiej na gregoriańską do 1752 r., więc dla nich pominięte daty były między 4 września a 14 września 1752 r. Inne kraje zmieniły się w innym czasie, ale 1582 i 1752 r. są odpowiednimi datami dla DBMS, o których rozmawiamy.
W związku z tym, gdy cofa się o wiele lat, pojawiają się dwa problemy z arytmetykami dat. Po pierwsze, czy lata przestępne przed zmianą powinny być obliczane według zasad juliańskich czy gregoriańskich? Drugim problemem jest to, kiedy i jak należy obchodzić się z pominiętymi dniami?
W ten sposób Big Eight DBMS radzi sobie z tymi pytaniami:
-
Udawaj, że nie ma przełącznika. Wydaje się, że tego wymaga standard SQL, chociaż standardowy dokument jest niejasny:mówi po prostu, że daty są „ograniczone przez naturalne reguły dla dat używających kalendarza gregoriańskiego” — czymkolwiek są „naturalne reguły”. Jest to opcja, którą wybrał DB2. Kiedy istnieje udawanie, że zasady jednego kalendarza zawsze miały zastosowanie nawet do czasów, gdy nikt o kalendarzu nie słyszał, termin techniczny brzmi, że obowiązuje kalendarz „proleptyczny”. Na przykład możemy powiedzieć, że DB2 podąża za proleptycznym kalendarzem gregoriańskim.
-
Całkowicie unikaj problemu. Microsoft i Sybase ustawiły swoje minimalne wartości dat na 1 stycznia 1753 r., czyli bezpiecznie po czasie, w którym Ameryka zmieniła kalendarze. Można to obronić, ale od czasu do czasu pojawiają się skargi, że te dwa DBMS nie mają użytecznej funkcjonalności, którą mają inne DBMS i której wymaga SQL Standard.
-
Wybierz 1582. To właśnie zrobiła Oracle. Użytkownik Oracle stwierdziłby, że wyrażenie arytmetyczne według daty 15 października 1582 minus 4 października 1582 daje wartość 1 dnia (ponieważ 5–14 października nie istnieje) i że data 29 lutego 1300 jest ważna (ponieważ skok juliański obowiązuje zasada roku). Dlaczego Oracle zadał sobie dodatkowe kłopoty, skoro standard SQL wydaje się tego nie wymagać? Odpowiedź brzmi, że użytkownicy mogą tego wymagać. Historycy i astronomowie używają tego hybrydowego systemu zamiast proleptycznego kalendarza gregoriańskiego. (Jest to również domyślna opcja, którą Sun wybrał podczas implementacji klasy GregorianCalendar dla Javy — pomimo nazwy GregorianCalendar jest kalendarzem hybrydowym).
Powyższy cytat pochodzi z następującego linku:
Dostrajanie wydajności SQL:daty w SQL
