Was ist die Bedeutung von 1/1/1753 in SQL Server?

Question

Warum 1753? Was haben sie gegen 1752? Mein Ur-Ur-Ur-Ur-Ur-Ur-Ur-Großvater wäre sehr beleidigt.

Answer 1

Die Entscheidung, den 1. Januar 1753 (1753-01-01) als den minimalen Datumswert für ein datetime in SQL Server zu verwenden, geht auf seine Sybase-Ursprünge zurück.

Die Bedeutung des Datums selbst lässt sich jedoch auf diesen Mann zurückführen.

Philip Stanhope, 4. Graf von Chesterfield. Der das Kalenderreformgesetz von 1750 durch das britische Parlament leitete. Dies legte die Einführung des Gregorianischen Kalenders für Großbritannien und seine damaligen Kolonien fest.

Es gab einige fehlende Tage _{(Internetarchiv-Link)} im britischen Kalender im Jahr 1752, als die Umstellung vom Julianischen Kalender endlich stattfand. Der 3. September 1752 bis zum 13. September 1752 gingen verloren.

Kalen Delaney erklärte die Wahl auf diese Weise

Also, mit 12 verlorenen Tagen, wie können Sie Daten berechnen? Zum Beispiel, wie können Sie die Anzahl der Tage zwischen 12. Oktober 1492 und 4. Juli 1776 berechnen? Beziehen Sie diese fehlenden 12 Tage mit ein? Um zu vermeiden, dieses Problem lösen zu müssen, entschieden die ursprünglichen Entwickler von Sybase SQL Server, keine Datumsangaben vor 1753 zuzulassen. Sie können frühere Daten in Zeichenfeldern speichern, aber Sie können keine datetime-Funktionen verwenden mit den früheren Daten, die Sie in den Zeichenfeldern speichern.

Die Wahl von 1753 scheint jedoch etwas englisch-zentriert zu sein, da viele katholische Länder in Europa den Kalender bereits 170 Jahre früher verwendet hatten als die britische Implementierung (ursprünglich aufgrund des Widerspruchs der Kirche verzögert). Andererseits reformierten viele Länder ihre Kalender erst viel später, 1918 in Russland. Tatsächlich begann die Oktoberrevolution von 1917 am 7. November nach dem Gregorianischen Kalender.

Sowohl datetime als auch der neue datetime2 Datentyp, erwähnt in Joes Antwort, versuchen nicht, diese lokalen Unterschiede zu berücksichtigen und verwenden einfach den Gregorianischen Kalender.

Also mit dem größeren Bereich von datetime2

SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)

Ergebnis

8. Sep 1752 00:00

Ein letzter Punkt beim Datentyp datetime2 ist, dass er den proleptischen Gregorianischen Kalender verwendet, der rückwirkend projiziert wird, lange bevor er tatsächlich erfunden wurde, und daher nur begrenzt nützlich ist, um mit historischen Daten umzugehen.

Dies steht im Gegensatz zu anderen Softwareimplementierungen wie der Java-Gregorian Calendar-Klasse, die standardmäßig dem Julianischen Kalender für Daten bis zum 4. Oktober 1582 folgt und dann zum 15. Oktober 1582 im neuen Gregorianischen Kalender wechselt. Sie behandelt das julianische Modell des Schaltjahres vor diesem Datum korrekt und das gregorianische Modell nach diesem Datum. Das Umstelldatum kann vom Aufrufer durch Aufruf von setGregorianChange() geändert werden.

Ein recht unterhaltsamer Artikel, der einige weitere Eigenheiten bei der Einführung des Kalenders bespricht, finden Sie hier.

Answer 2

Dein Ur-Ur-Ur-Ur-Ur-Ur-Ur-Großvater sollte auf SQL Server 2008 aufrüsten und den DateTime2 Datentyp verwenden, der Datumsangaben im Bereich von 0001-01-01 bis 9999-12-31 unterstützt.

Answer 3

1752 war das Jahr, in dem Großbritannien vom julianischen zum gregorianischen Kalender wechselte. Ich glaube, dass sich als Folge davon zwei Wochen im September 1752 nie ereignet haben, was Auswirkungen auf Daten in diesem allgemeinen Bereich hat.

Eine Erklärung: (Internet-Archiv-Version)

Answer 4

Dies ist die ganze Geschichte, wie das Datumsproblem war und wie die großen DBMSs diese Probleme behandelt haben.

In der Zeit zwischen 1 n. Chr. und heute hat die westliche Welt tatsächlich zwei Hauptkalender verwendet: den Julianischen Kalender von Julius Caesar und den Gregorianischen Kalender von Papst Gregor XIII. Die beiden Kalender unterscheiden sich nur in einer Regel: der Regel zur Bestimmung eines Schaltjahres. Im Julianischen Kalender sind alle durch vier teilbaren Jahre Schaltjahre. Im Gregorianischen Kalender sind alle durch vier teilbaren Jahre Schaltjahre, außer dass Jahre, die durch 100 teilbar sind (aber nicht durch 400), keine Schaltjahre sind. Daher sind die Jahre 1700, 1800 und 1900 im Julianischen Kalender Schaltjahre, aber nicht im Gregorianischen Kalender, während die Jahre 1600 und 2000 in beiden Kalendern Schaltjahre sind.

Als Papst Gregor XIII. im Jahr 1582 seinen Kalender einführte, wies er auch an, dass die Tage zwischen dem 4. Oktober 1582 und dem 15. Oktober 1582 übersprungen werden sollten - das heißt, er sagte, dass der Tag nach dem 4. Oktober der 15. Oktober sein sollte. Viele Länder verzögerten jedoch die Umstellung. England und ihre Kolonien wechselten erst 1752 vom Julianischen zum Gregorianischen Kalender, sodass für sie die übersprungenen Daten zwischen dem 4. und dem 14. September 1752 lagen. Andere Länder wechselten zu anderen Zeiten, aber 1582 und 1752 sind die relevanten Daten für die DBMSs, über die wir sprechen.

Daher ergeben sich zwei Probleme bei der Datumsarithmetik, wenn man viele Jahre zurückgeht. Das erste ist, sollten Schaltjahre vor der Umstellung nach den julianischen oder den gregorianischen Regeln berechnet werden? Das zweite Problem ist, wann und wie sollten die übersprungenen Tage behandelt werden?

So handhaben die großen DBMSs diese Fragen:

• Tun so, als gäbe es keinen Wechsel. Das ist es, was der SQL-Standard anscheinend verlangt, obwohl das Standarddokument unklar ist: Es sagt nur, dass Daten "durch die natürlichen Regeln für Daten unter Verwendung des Gregorianischen Kalenders" eingeschränkt sind - was auch immer "natürliche Regeln" sind. Dies ist die Option, für die sich DB2 entschieden hat. Wenn so getan wird, als ob die Regeln eines einzigen Kalenders immer gelten würden, auch in Zeiten, in denen niemand von diesem Kalender gehört hat, lautet der Fachbegriff "proleptischer" Kalender. Wir könnten also zum Beispiel sagen, dass DB2 einem proleptischen gregorianischen Kalender folgt.
• Umgehen Sie das Problem vollständig. Microsoft und Sybase setzen ihre Mindestdatumswerte auf den 1. Januar 1753, sicherlich nachdem Amerika die Kalender gewechselt hat. Das ist vertretbar, aber gelegentlich werden Beschwerden laut, dass diese beiden DBMSs eine nützliche Funktionalität fehlen, die die anderen DBMSs haben und die der SQL-Standard verlangt.
• Wählen Sie 1582. Das ist es, was Oracle gemacht hat. Ein Oracle-Benutzer würde feststellen, dass der Datum-Arithmetik-Ausdruck 15. Oktober 1582 minus 4. Oktober 1582 einen Wert von 1 Tag ergibt (weil es vom 5. bis 14. Oktober nicht gibt) und dass das Datum 29. Februar 1300 gültig ist (weil die julianische Schaltjahresregel gilt). Warum hat Oracle diesen zusätzlichen Aufwand betrieben, wenn der SQL-Standard dies anscheinend nicht verlangt? Die Antwort ist, dass Benutzer es möglicherweise benötigen. Historiker und Astronomen verwenden dieses Hybrid-System anstelle eines proleptischen gregorianischen Kalenders. (Dies ist auch die Standardeinstellung, die Sun gewählt hat, als die GregorianCalendar-Klasse für Java implementiert wurde - trotz des Namens handelt es sich bei GregorianCalendar um einen Hybridkalender.)

Quelle 1 und 2

Answer 5

Übrigens weiß Windows nicht mehr, wie man UTC korrekt in US-amerikanische Ortszeit für bestimmte Termine im März/April oder Oktober/November vergangener Jahre umrechnet. UTC-basierte Zeitstempel von diesen Daten sind jetzt etwas unsinnig. Es wäre sehr unangenehm, wenn das Betriebssystem einfach die Handhabung von Zeitstempeln vor den neuesten DST-Regeln der US-Regierung ablehnen würde, daher behandelt es einfach einige von ihnen falsch. SQL Server weigert sich, Daten vor 1753 zu verarbeiten, weil viel zusätzliche spezielle Logik erforderlich wäre, um sie korrekt zu behandeln, und es will sie nicht falsch behandeln.