Welche Bedeutung hat der 1.1.1753 in SQL Server?

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

Die Entscheidung, den 1. Januar 1753 ( 1753-01-01) als Mindestdatum für eine Datums- / Uhrzeitangabe in SQL Server zu verwenden, geht auf die Sybase-Ursprünge zurück .

Die Bedeutung des Datums selbst kann diesem Mann jedoch zugeschrieben werden.

Philip Stanhope, 4. Earl of Chesterfield. Wer steuerte den Calendar (New Style) Act 1750 durch das britische Parlament. Dies sah die Verabschiedung des Gregorianischen Kalenders für Großbritannien und seine damaligen Kolonien vor.

Es gab einige fehlende Tage _{(Link zum Internetarchiv)} im britischen Kalender im Jahr 1752, als die Anpassung schließlich aus dem julianischen Kalender vorgenommen wurde. 3. September 1752 bis 13. September 1752 gingen verloren.

Kalen Delaney erklärte die Wahl auf diese Weise

Wie können Sie nach 12 verlorenen Tagen Daten berechnen? Wie können Sie beispielsweise die Anzahl der Tage zwischen dem 12. Oktober 1492 und dem 4. Juli 1776 berechnen? Schließen Sie die fehlenden 12 Tage ein? Um dieses Problem nicht lösen zu müssen, haben die ursprünglichen Sybase SQL Server-Entwickler beschlossen, keine Daten vor 1753 zuzulassen. Sie können frühere Daten mithilfe von Zeichenfeldern speichern, jedoch keine Datums- / Uhrzeitfunktionen mit den früheren Daten, die Sie in Zeichen speichern Felder.

Die Wahl von 1753 scheint jedoch etwas anglozentrisch zu sein, da viele katholische Länder in Europa den Kalender vor der britischen Umsetzung 170 Jahre lang verwendet hatten (ursprünglich aufgrund des Widerstandes der Kirche verzögert ). Umgekehrt haben viele Länder ihre Kalender erst viel später, 1918 in Russland, reformiert. Tatsächlich begann die Oktoberrevolution von 1917 am 7. November nach dem Gregorianischen Kalender.

Beide datetimeund der datetime2in Joes Antwort erwähnte neue Datentyp versuchen nicht, diese lokalen Unterschiede zu berücksichtigen, und verwenden einfach den Gregorianischen Kalender.

Also mit der größeren Reichweite von datetime2

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

Kehrt zurück

Sep  8 1752 12:00AM

Ein letzter Punkt beim datetime2Datentyp ist, dass er den proleptischen Gregorianischen Kalender verwendet, der weit vor seiner Erfindung rückwärts projiziert wurde, sodass er im Umgang mit historischen Daten nur begrenzt von Nutzen ist.

Dies steht im Gegensatz zu anderen Software-Implementierungen wie der Java- Gregorianischen Kalenderklasse , die standardmäßig dem Julianischen Kalender für Daten bis zum 4. Oktober 1582 folgt und dann im neuen Gregorianischen Kalender zum 15. Oktober 1582 springt. Es behandelt das julianische Modell des Schaltjahres vor diesem Datum und das gregorianische Modell nach diesem Datum korrekt. Das Stichtag kann vom Anrufer telefonisch geändert werden setGregorianChange().

Einen ziemlich unterhaltsamen Artikel über einige weitere Besonderheiten bei der Annahme des Kalenders finden Sie hier .

Ihr Ur-Ur-Ur-Ur-Ur-Ur-Großvater sollte ein Upgrade auf SQL Server 2008 durchführen und den Datentyp DateTime2 verwenden, der Daten im Bereich von 0001-01-01 bis 9999-12-31 unterstützt.

1752 wechselte Großbritannien vom julianischen zum gregorianischen Kalender. Ich glaube, zwei Wochen im September 1752 sind nie passiert, was Auswirkungen auf die Daten in diesem allgemeinen Bereich hat.

Eine Erklärung: http://uneasysilence.com/archive/2007/08/12008/ ( Internet Archive Version )

Dies ist die ganze Geschichte, wie das Datumsproblem war und wie große DBMS mit diesen Problemen umgingen.

In der Zeit zwischen 1 n. Chr. Und heute hat die westliche Welt tatsächlich zwei Hauptkalender verwendet: den julianischen Kalender von Julius Cäsar und den gregorianischen Kalender von Papst Gregor XIII. Die beiden Kalender unterscheiden sich nur in einer Regel: der Regel für die Entscheidung, was ein Schaltjahr ist. Im julianischen Kalender sind alle durch vier teilbaren Jahre Schaltjahre. Im Gregorianischen Kalender sind alle durch vier teilbaren Jahre Schaltjahre, mit der Ausnahme, dass durch 100 teilbare Jahre (aber nicht durch 400 teilbare Jahre) keine Schaltjahre sind. Somit sind die Jahre 1700, 1800 und 1900 Schaltjahre im julianischen Kalender, jedoch nicht im gregorianischen Kalender, während die Jahre 1600 und 2000 Schaltjahre in beiden Kalendern sind.

Als Papst Gregor XIII. 1582 seinen Kalender vorstellte, wies er auch an, die Tage zwischen dem 4. Oktober 1582 und dem 15. Oktober 1582 zu überspringen - das heißt, der Tag nach dem 4. Oktober sollte der 15. Oktober sein. Viele Länder verzögerte Umstellung jedoch. England und seine Kolonien wechselten erst 1752 von julianischer zu gregorianischer Rechnung, so dass für sie die übersprungenen Daten zwischen dem 4. September 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, die wir diskutieren.

Somit treten zwei Probleme mit der Datumsarithmetik auf, wenn man viele Jahre zurückreicht. Die erste ist, sollten Schaltjahre bevor der Wechsel nach den julianischen oder gregorianischen Regeln berechnet wird? Das zweite Problem ist, wann und wie mit den übersprungenen Tagen umgegangen werden soll.

So behandeln die Big DBMS diese Fragen:

• Stellen Sie sich vor, es gäbe keinen Schalter. Dies scheint der SQL-Standard zu erfordern, obwohl das Standarddokument unklar ist: Es heißt nur, dass Datumsangaben "durch die natürlichen Regeln für Datumsangaben unter Verwendung des Gregorianischen Kalenders eingeschränkt werden" - was auch immer "natürliche Regeln" sind. Dies ist die Option, die DB2 ausgewählt hat. Wenn vorgetäuscht wird, dass die Regeln eines einzelnen Kalenders immer auch dann gelten, wenn niemand von dem Kalender gehört hat, lautet der Fachbegriff, dass ein "proleptischer" Kalender in Kraft ist. So könnte man zum Beispiel sagen, dass DB2 einem proleptischen Gregorianischen Kalender folgt.
• Vermeiden Sie das Problem vollständig. Microsoft und Sybase legten ihre Mindestdatumswerte auf den 1. Januar 1753 fest, sicher nach der Zeit, als Amerika den Kalender wechselte. Dies ist verteidigungsfähig, aber von Zeit zu Zeit tauchen Beschwerden auf, dass diesen beiden DBMS eine nützliche Funktionalität fehlt, über die die anderen DBMS verfügen und die der SQL-Standard erfordert.
• Wählen Sie 1582. Dies hat Oracle getan. Ein Oracle-Benutzer würde feststellen, dass der datumsarithmetische Ausdruck 15. Oktober 1582 minus 4. Oktober 1582 einen Wert von 1 Tag ergibt (weil der 5. bis 14. Oktober nicht existiert) und dass das Datum 29. Februar 1300 gültig ist (weil der julianische Sprung- Jahresregel gilt). Warum hat Oracle zusätzliche Probleme, wenn der SQL-Standard dies nicht zu erfordern scheint? Die Antwort ist, dass Benutzer es möglicherweise benötigen. Historiker und Astronomen verwenden dieses Hybridsystem anstelle eines proleptischen Gregorianischen Kalenders. (Dies ist auch die Standardoption, die Sun bei der Implementierung der GregorianCalendar-Klasse für Java ausgewählt hat. Trotz des Namens ist GregorianCalendar ein Hybridkalender.)

Quelle 1 und 2

Übrigens weiß Windows nicht mehr, wie UTC für bestimmte Daten im März / April oder Oktober / November der vergangenen Jahre korrekt in US-Ortszeit konvertiert werden kann. UTC-basierte Zeitstempel von diesen Daten sind jetzt etwas unsinnig. Es wäre sehr schwierig für das Betriebssystem, sich einfach zu weigern, Zeitstempel vor den neuesten Sommerzeitregeln der US-Regierung zu verarbeiten, sodass einige davon einfach falsch behandelt werden. SQL Server weigert sich, Daten vor 1753 zu verarbeiten, da viele spezielle Logik erforderlich wäre, um sie korrekt zu behandeln, und sie nicht falsch behandeln möchte.