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


Odpowiedzi:


831

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

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:00AM

Ostatni 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 .


68
+1 za wspaniały portret nie obrażonego pra pra pra pra pra pradziadka. Również inne lśniące atrybuty tej odpowiedzi.
Smandoli

83
+1 za odpowiedź zarówno techniczną, jak i historyczną. Na tablicy często uczęszczanych przez leworęcznych jest to przyjemna lektura. I tak, poszedłem na studia humanistyczne.
Matt Hamsmith,

1
Jeśli chodzi o ten link : wyobraź sobie kogoś urodzonego w Szwecji 30 lutego 1712 r. - nigdy by się nie zestarzał! : P A także, co u licha robili Litwa i Łotwa przez cały ten czas !?
Isaac Reefman,

Link „ brakujące dni ” jest zepsuty.
Venkat

1
@Venkat - naprawione teraz z linkiem do archiwum internetowego
Martin Smith

99

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.


40
@CRMay: Powiedz mu, że planujesz rozpocząć prace nad zgodnością Y10K w czwartek, 5000-01-02; to pozostawia niecałe 5 tysięcy lat, aby to naprawić.
Jonathan Leffler

8
mm Zgaduję, że ktoś przegapił odpowiedź na pytanie: dlaczego 1753 , przez wszystkie lata?
patrz

7
... a pytanie brzmiało
V4Vendetta

1
Tak ... ale spróbuj przeprowadzić tę zmianę typu danych w firmie, która ma ogromnie zainstalowaną bazę baz danych SQL Server i więcej linii obrony przed przerażającą ZMIANĄ wroga niż USA przeciwko rosyjskim ICBM u szczytu Zimna wojna ...
SebTHU

1
Myślę, że to lepsza odpowiedź, ponieważ zwięźle i opowiadając rozwiązanie zamiast historii,
zapytałbyś


19

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.)

Źródło 1 i 2


8

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ć.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.