it-swarm.com.de

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.

444
Daniel

Die Entscheidung, den 1. Januar 1753 (1753-01-01) Als minimalen Datumswert für eine Datums-/Uhrzeitangabe in SQL Server zu verwenden, geht zurück auf den Sybase-Ursprung .

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

Philip Stanhope, 4th Earl of Chesterfield

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

Es gab einige fehlende Tage im britischen Kalender im Jahr 1752, als die Anpassung schließlich vom julianischen Kalender vorgenommen wurde. 3. September 1752 bis 13. September 1752 wurden verloren.

Kalen Delaney erklärt die Wahl auf diese Weise

Wie können Sie nach 12 Tagen Daten berechnen? Wie können Sie beispielsweise die Anzahl der Tage zwischen dem 12. Oktober 1492 und dem 4. Juli 1776 berechnen? Fügen Sie diese fehlenden 12 Tage hinzu? Um dieses Problem nicht lösen zu müssen, haben die ursprünglichen Entwickler von Sybase SQL Server entschieden, keine Daten vor 1753 zuzulassen. Sie können frühere Daten mithilfe von Zeichenfeldern speichern, aber Sie können keine Datums-/Uhrzeitfunktionen mit den früheren Daten verwenden, 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 170 Jahre vor der britischen Umsetzung verwendet hatte (ursprünglich wegen Widerspruchs verzögert von der Kirche ). Umgekehrt reformierten viele Länder ihre Kalender erst viel später, 1918, in Russland. In der Tat begann die Oktoberrevolution von 1917 am 7. November nach dem Gregorianischen Kalender.

Sowohl datetime als auch der in Joes Antwort erwähnte neue Datentyp datetime2 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)

Kehrt zurück

Sep  8 1752 12:00AM

Ein letzter Punkt mit dem Datentyp datetime2 Ist, dass er den proleptischen gregorianischen Kalender verwendet, der weit vor seiner eigentlichen Erfindung rückwärts projiziert wurde und daher für den Umgang mit historischen Daten von begrenztem Nutzen ist.

Dies steht im Gegensatz zu anderen Software-Implementierungen wie der Klasse Java Gregorianischer Kalender , die standardmäßig dem Julianischen Kalender für Daten bis zum 4. Oktober 1582 folgt und dann zum 15. Oktober 1582 springt Im neuen gregorianischen Kalender wird das julianische Modell des Schaltjahres vor diesem Datum und das gregorianische Modell nach diesem Datum korrekt behandelt. Das Umstellungsdatum kann vom Aufrufer durch Aufrufen von setGregorianChange() geändert werden.

Ein ziemlich unterhaltsamer Artikel, der einige weitere Besonderheiten mit der Übernahme des Kalenders bespricht hier zu finden .

799
Martin Smith

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

96
Joe Stefanelli

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 )

26
Gian

Dies ist die ganze Geschichte, wie das Datumsproblem war und wie große DBMS diese Probleme handhabten.

In der Zeit zwischen dem 1. und dem heutigen Tag wurden in der westlichen Welt zwei Hauptkalender verwendet: der Julianische Kalender von Julius Cäsar und der Gregorianische Kalender von Papst Gregor XIII. Die beiden Kalender unterscheiden sich nur in Bezug auf eine Regel: Die 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 Jahre, die durch 100 teilbar sind (aber nicht durch 400 teilbar sind), keine Schaltjahre sind. So sind die Jahre 1700, 1800 und 1900 Schaltjahre im Julianischen Kalender, nicht jedoch im Gregorianischen Kalender, während die Jahre 1600 und 2000 in beiden Kalendern Schaltjahre sind.

Als Papst Gregor XIII. 1582 seinen Kalender vorstellte, befahl er auch, 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ögertes Umrüsten. England und seine Kolonien wechselten erst 1752 von julianischen zu gregorianischen Daten. Für sie lagen die übersprungenen Daten zwischen dem 4. September und dem 14. September 1752. Andere Länder wechselten zu anderen Zeiten, aber 1582 und 1752 sind die relevanten Daten für das DBMSs, die wir diskutieren.

Somit treten bei der Datumsberechnung zwei Probleme auf, wenn man viele Jahre zurückreicht. Die erste ist, sollte der Sprung Jahre vor dem Wechsel nach den Julianischen oder den Gregorianischen Regeln berechnet werden? Das zweite Problem ist, wann und wie die übersprungenen Tage behandelt werden sollen.

So gehen die Big DBMS mit diesen Fragen um:

  • Stellen Sie sich vor, es gäbe keinen Schalter. Dies scheint der SQL-Standard zu fordern, obwohl das Standarddokument unklar ist: Er sagt lediglich, dass Datumsangaben "durch die natürlichen Regeln für Datumsangaben unter Verwendung des Gregorianischen Kalenders eingeschränkt" sind - was auch immer "natürliche Regeln" sind. Dies ist die Option, die DB2 ausgewählt hat. Wenn behauptet wird, dass die Regeln eines einzelnen Kalenders immer für Zeiten gelten, in denen niemand von dem Kalender gehört hat, ist der Fachbegriff, dass ein "proleptischer" Kalender in Kraft ist. So könnten wir beispielsweise sagen, dass DB2 einem proleptischen gregorianischen Kalender folgt.
  • Vermeiden Sie das Problem vollständig. Microsoft und Sybase haben ihre Mindestdatumswerte auf den 1. Januar 1753 festgelegt, sicher nach dem Zeitpunkt, zu dem Amerika den Kalender gewechselt hat. Dies ist verteidigbar, aber von Zeit zu Zeit tauchen Beschwerden auf, dass diesen beiden DBMS eine nützliche Funktionalität fehlt, die die anderen DBMS haben und die der SQL-Standard erfordert.
  • Wählen Sie 1582. Dies ist, was Oracle getan hat. Ein Oracle-Benutzer würde feststellen, dass der datumsarithmetische Ausdruck 15. Oktober 1582 minus 4. Oktober 1582 einen Wert von 1 Tag ergibt (da der 5. bis 14. Oktober nicht existiert) und dass das Datum 29. Februar 1300 gültig ist (weil der Julianische Sprung gültig ist). Jahresregel gilt). Warum hat sich Oracle zusätzliche Mühe gegeben, 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 handelt es sich bei GregorianCalendar um einen Hybridkalender.)

Quelle 1 und 2

17
Somnath Muluk

Übrigens weiß Windows nicht mehr, wie UTC für bestimmte Daten in den Monaten März/April oder Oktober/November der vergangenen Jahre korrekt in US-Ortszeit umgerechnet 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 zu verarbeiten, bevor die US-Regierung die neuesten DST-Regeln erlassen hat. SQL Server lehnt es ab, Daten vor 1753 zu verarbeiten, da viele zusätzliche spezielle Logik erforderlich wäre, um sie korrekt zu behandeln, und sie nicht falsch behandeln möchte.

8
supercat