Jakie jest znaczenie 1/1/1753 w SQL Server?
Odpowiedzi:
Decyzja o użyciu 1 stycznia 1753 r. ( 1753-01-01) Jako minimalnej wartości daty dla daty i godziny w SQL Server powraca do początków Sybase .
Znaczenie samej daty można jednak przypisać temu człowiekowi.
Philip Stanhope, 4. hrabia Chesterfield. Kto kierował ustawą o kalendarzu (nowy styl) 1750 za pośrednictwem parlamentu brytyjskiego. Stanowiło to prawo do przyjęcia kalendarza gregoriańskiego dla Wielkiej Brytanii i jej ówczesnych kolonii.
Było kilka brakujących dni (internet Link archiwum) w brytyjskim kalendarzu w 1752 roku, gdy regulacja została ostatecznie wykonana z kalendarza juliańskiego. 3 września 1752 r. Do 13 września 1752 r. Zaginęły.
Kalen Delaney wyjaśnił w ten sposób wybór
Więc, po 12 dniach straconych, jak możesz obliczyć daty? Jak na przykład obliczyć liczbę dni między 12 października 1492 r. A 4 lipca 1776 r.? Czy uwzględnisz te brakujące 12 dni? Aby uniknąć konieczności rozwiązania tego problemu, pierwotni programiści Sybase SQL Server postanowili nie zezwalać na daty przed 1753 r. Możesz przechowywać wcześniejsze daty za pomocą pól znaków, ale nie możesz używać żadnych funkcji datetime z wcześniejszymi datami, które przechowujesz w charakterze pola.
Wybór z 1753 roku wydaje się nieco anglocentryczny, jednak wiele krajów katolickich w Europie używało kalendarza przez 170 lat przed brytyjską implementacją (początkowo opóźnione z powodu sprzeciwu Kościoła ). I odwrotnie, wiele krajów zreformowało swoje kalendarze dopiero znacznie później, w 1918 r. W Rosji. Rzeczywiście rewolucja październikowa w 1917 r. Rozpoczęła się 7 listopada zgodnie z kalendarzem gregoriańskim.
Zarówno datetimenowy datetime2typ danych wymieniony w odpowiedzi Joe nie próbują uwzględniać tych lokalnych różnic i po prostu używają kalendarza gregoriańskiego.
Więc z większym zakresem datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)Zwroty
Sep 8 1752 12:00AMOstatni punkt dotyczący tego datetime2typu danych polega na tym, że korzysta z proleptycznego kalendarza gregoriańskiego rzutowanego wstecz na długo przed jego faktycznym wynalezieniem, więc ma on ograniczone zastosowanie w przypadku dat historycznych.
Kontrastuje to z innymi implementacjami oprogramowania, takimi jak klasa kalendarza gregoriańskiego Java, która domyślnie śledzi kalendarz juliański dla dat do 4 października 1582 r., A następnie przeskakuje do 15 października 1582 r. W nowym kalendarzu gregoriańskim. Prawidłowo obsługuje Juliański model roku przestępnego przed tą datą i model gregoriański po tej dacie. Data przełączenia może zostać zmieniona przez dzwoniącego setGregorianChange().
Dość zabawny artykuł omawiający pewne osobliwości związane z przyjęciem kalendarza można znaleźć tutaj .
Twój pra-pra-pra-pra-pra-pra-pra-pra-pra-dziadek powinien dokonać aktualizacji do SQL Server 2008 i użyć typu danych DateTime2 , który obsługuje daty z zakresu: 0001-01-01 do 9999-12-31.
1752 był rokiem przejścia Wielkiej Brytanii z kalendarza juliańskiego na kalendarz gregoriański. Uważam, że dwa tygodnie we wrześniu 1752 r. Nigdy się nie wydarzyły, co ma wpływ na daty w tej ogólnej dziedzinie.
Wyjaśnienie: http://uneasysilence.com/archive/2007/08/12008/ ( wersja archiwum internetowego )
To cała historia, jak problem z datą i jak duże DBMS poradziły sobie z tymi problemami.
W okresie od 1 AD do dzisiaj świat zachodni faktycznie używał dwóch głównych kalendarzy: kalendarza juliańskiego Juliusza Cezara i kalendarza gregoriańskiego papieża Grzegorza XIII. Dwa kalendarze różnią się tylko jedną regułą: regułą decydującą o tym, jaki jest rok przestępny. W kalendarzu juliańskim wszystkie lata podzielne przez cztery są latami przestępnymi. W kalendarzu gregoriańskim wszystkie lata podzielne przez cztery są latami przestępnymi, z wyjątkiem lat podzielnych przez 100 (ale niepodzielnych przez 400) nie są latami przestępnymi. Zatem lata 1700, 1800 i 1900 są latami przestępnymi w kalendarzu juliańskim, ale nie w kalendarzu gregoriańskim, natomiast lata 1600 i 2000 to lata przestępne w obu kalendarzach.
Kiedy papież Grzegorz XIII wprowadził swój kalendarz w 1582 r., Zalecił również, aby dni między 4 października 1582 r. A 15 października 1582 r. Zostały pominięte - to znaczy, że dzień po 4 października powinien przypadać na 15 października. Wiele krajów jednak opóźnione przejście na inny. Anglia i jej kolonie przeszły z rozliczeń juliańskich na gregoriańskie do 1752 r., Więc dla nich pominięte daty przypadały między 4 września a 14 września 1752 r. Inne kraje zmieniły się w innym czasie, ale 1582 i 1752 są odpowiednimi datami DBMS, które omawiamy.
W związku z tym pojawiają się dwa problemy z arytmetyką dat, gdy cofamy się o wiele lat. Po pierwsze, czy lata przestępne powinny zostać obliczone przed zmianą zgodnie z zasadami juliańskimi lub gregoriańskimi? Drugi problem polega na tym, kiedy i jak należy obchodzić pominięte dni?
Oto jak Big DBMS radzą sobie z tymi pytaniami:
- Udawaj, że nie było przełącznika. Tego wymaga Standard SQL, chociaż standardowy dokument jest niejasny: po prostu mówi, że daty są „ograniczone naturalnymi regułami dla dat korzystających z kalendarza gregoriańskiego” - czymkolwiek są „naturalne reguły”. Jest to opcja wybrana przez DB2. Kiedy istnieje pozór, że reguły jednego kalendarza zawsze miały zastosowanie nawet w czasach, gdy nikt nie słyszał o kalendarzu, terminem technicznym jest, że obowiązuje kalendarz „proleptyczny”. Na przykład moglibyśmy powiedzieć, że DB2 postępuje zgodnie z proleptycznym kalendarzem gregoriańskim.
- Całkowicie unikaj problemu. Microsoft i Sybase ustalili minimalne wartości dat na 1 stycznia 1753 r., Bezpiecznie po upływie czasu, kiedy Ameryka zmieniła kalendarze. Można tego bronić, ale od czasu do czasu pojawiają się skargi, że te dwa DBMS nie mają użytecznej funkcjonalności, którą mają inne DBMS i czego wymaga SQL Standard.
- Wybierz 1582. Tak właśnie zrobiła Oracle. Użytkownik Oracle stwierdziłby, że wyrażenie arytmetyczne data 15 października 1582 minus 4 października 1582 daje wartość 1 dzień (ponieważ 5–14 października nie istnieje) i że data 29 lutego 1300 jest prawidłowa (ponieważ skok Juliana obowiązuje zasada roku). Dlaczego Oracle ma dodatkowe problemy, gdy wydaje się, że SQL Standard tego nie wymaga? Odpowiedź jest taka, że użytkownicy mogą tego wymagać. Historycy i astronomowie używają tego systemu hybrydowego zamiast proleptycznego kalendarza gregoriańskiego. (Jest to również domyślna opcja wybrana przez Sun podczas wdrażania klasy GregorianCalendar dla Javy - pomimo nazwy GregorianCalendar jest kalendarzem hybrydowym.)
Nawiasem mówiąc, system Windows nie wie już, jak poprawnie konwertować UTC na czas lokalny w USA dla niektórych dat w marcu / kwietniu lub październiku / listopadzie poprzednich lat. Sygnatury czasowe oparte na UTC z tych dat są teraz nieco nonsensowne. Byłoby bardzo niegrzeczne, gdyby system operacyjny po prostu odmawiał obsługi znaczników czasu przed najnowszym zestawem reguł DST rządu USA, więc po prostu obsługuje niektóre z nich źle. Program SQL Server odmawia przetwarzania dat sprzed 1753 r., Ponieważ do ich poprawnej obsługi potrzebna będzie dodatkowa logika i nie chce się z nimi źle obchodzić.