Jakie jest znaczenie 1/1/1753 w SQL Server?

Twój прапрапрапрапрапрадедушка musi przejść na SQL Server 2008 i użyć typu danych DateTime2, który obsługuje daty w zakresie od 0001-01-01 do 9999-12-31.

Rok 1752 był rokiem przejścia Wielkiej Brytanii z kalendarza juliańskiego na gregoriański. Wydaje mi się, że dwa tygodnie we wrześniu 1752 roku nigdy się nie wydarzyły, co ma wpływ na daty w tym ogólnym obszarze.

Wyjaśnienie: http://uneasysilence.com/archive/2007/08/12008/ ( Internet Archive version )

To cała historia, jak problem z datą i jak duży DBMSs poradził sobie z tymi problemami.

W okresie od 1 n. e. do dziś świat zachodni ma właściwie używane dwa główne kalendarze: Kalendarz juliański Juliusza Cezara i kalendarza gregoriańskiego papieża Grzegorza XIII. dwa kalendarze różnią się w odniesieniu do tylko jednej zasady: zasady decydowania o tym, co rok przestępny. W kalendarzu juliańskim wszystkie lata podzielne przez cztery to lata przestępne. W gregoriańskim kalendarza, wszystkie lata podzielne przez cztery są lat przestępnych, z tym że lata podzielne przez 100 (ale nie podzielne przez 400) nie są latami przestępnymi. Tak więc lata 1700, 1800 i 1900 to skok lat w kalendarzu juliańskim, ale nie w kalendarzu gregoriańskim, podczas gdy lata 1600 i 2000 to lata przestępne w obu kalendarzach.

Kiedy papież Grzegorz XIII wprowadził swój kalendarz w 1582 roku, również w dniach od 4 października 1582 do 15 października 1582, należy pominąć-czyli, powiedział, że dzień po 4 października powinien być 15 października. Jednak wiele krajów opóźniło zmianę. Anglia a jej kolonie nie zamieniły się z juliańskiego na gregoriańskie do 1752 roku, więc dla nich pominięte daty przypadały na 4 września i 14 września 1752. Inne kraje zamieniły się w innym czasie, ale 1582 i 1752 to odpowiednie daty Dla DBMSs, że jesteśmy dyskusja.

Tak więc, dwa problemy z arytmetyką daty, gdy jeden wraca wiele lat. Pierwszym jest, czy lata przestępne przed zmianą należy obliczyć według reguł Juliańskich czy gregoriańskich? Drugi problem to, kiedy i jak należy postępować z pominiętymi dniami?

Tak wielki DBMSs radzi sobie z tymi pytaniami:

• udawaj, że nie ma przełącznika. Tak wygląda Standard SQL wymagać, chociaż standardowy dokument jest niejasny: po prostu mówi, że daty są " ograniczone naturalnymi regułami dla dat przy użyciu Gregorian kalendarz" - niezależnie od "naturalnych zasad". To jest opcja ten DB2 wybrał. Gdy istnieje pozór, że pojedynczy kalendarz jest zasady zawsze obowiązywały nawet w czasach, gdy nikt nie słyszał o kalendarza, termin techniczny jest taki, że kalendarz "proleptyczny" jest w Siła. Tak więc, na przykład, możemy powiedzieć, że DB2 podąża za proleptykiem Kalendarz gregoriański.
• unikaj problemu całkowicie. Microsoft i Sybase ustawić ich minimalne wartości daty na 1 stycznia 1753 roku, bezpiecznie po czasie że Ameryka zamieniła kalendarze. Jest to możliwe do obrony, ale od czasu do reklamacje czasu, że te dwa DBMSs brakuje użytecznego funkcjonalności, które mają inne DBMSs i że Standard SQL wymaga.
Wybierz 1582. To właśnie zrobiła Wyrocznia. Użytkownik Oracle mógłby find that the date-wyrażenie arytmetyczne October 15 1582 minus October 4 1582 daje wartość 1 dnia (bo 5-14 października nie istnieje) i że data 29 lutego 1300 jest ważna (ponieważ juliański rok przestępny obowiązuje zasada). Dlaczego Oracle miał dodatkowe problemy, gdy SQL Standard tego nie wymaga? Odpowiedź jest taka, że użytkownicy mogą wymagaj tego. Historycy i astronomowie używają tego hybrydowego systemu zamiast według proleptycznego kalendarza gregoriańskiego. (Jest to również opcja domyślna że Słońce wybrało podczas realizacji klasy GregorianCalendar dla Java - wbrew nazwie, GregorianCalendar jest kalendarzem hybrydowym.)

Źródło 1 oraz 2

Nawiasem mówiąc, System Windows nie wie już, jak poprawnie przekonwertować czas UTC na czas lokalny USA dla pewnych dat w marcu/kwietniu lub październiku/listopadzie minionych lat. Znaczniki czasu UTC z tych dat są teraz nieco bezsensowne. Byłoby bardzo nieprzyjemne dla systemu operacyjnego, aby po prostu odmówić obsługi znaczników czasu przed najnowszym zestawem reguł DST rządu USA, więc po prostu obsługuje niektóre z nich źle. SQL Server odmawia przetwarzania dat przed 1753, ponieważ wiele dodatkowych logiki specjalnej byłoby wymagane, aby obsługiwać je poprawnie i nie chce obsługiwać ich źle.