Ich frage mich, warum SqlDateTime.MinValue nicht mit DateTime.MinValue identisch ist.
Antworten:
Ich denke , der Unterschied zwischen SQL und .NET des Datums - Datentypen aus der Tatsache stammt , dass SQL Server Datetime - Datentyp, ist es Minimal- und Maximalwerte, und es ist Präzision sind viel älter als .NET des Datetime - Datentyp.
Mit dem Aufkommen von .NET entschied das Team, dass der Datetime-Datentyp einen natürlicheren Mindestwert haben sollte, und der 01/01/0001 scheint eine ziemlich logische Wahl zu sein, und dieser Wert ist sicherlich aus Programmiersprache und nicht aus Datenbanksicht natürlicher.
Übrigens gibt es in SQL Server 2008 eine Reihe neuer datumsbasierter Datentypen ( Datum , Uhrzeit , DateTime2 , DateTimeOffset ), die tatsächlich einen größeren Bereich und eine höhere Genauigkeit bieten und dem DateTime-Datentyp in .NET genau zugeordnet sind. Beispielsweise hat der Datentyp DateTime2 einen Datumsbereich von 0001-01-01 bis 9999-12-31.
Der Standarddatentyp "datetime" von SQL Server hatte immer einen Mindestwert von 01/01/1753 (und hat es tatsächlich immer noch!). Ich muss zugeben, auch ich war neugierig auf die Bedeutung dieses Wertes, ebenso wie das Graben. Was ich fand, war wie folgt:
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 Eight 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.)
Dieses obige Zitat stammt aus dem folgenden Link:
Da in SQL Server das Mindestdatum, das in einem Datum / Uhrzeit-Feld (1753/1/1) gespeichert werden kann, nicht dem MinValue des Datentyps DateTime .NET (0001/1/1) entspricht.
1753 war das Datum des ersten Anwenders des Gregorianischen Kalenders (England). Warum dies gegenüber dem 01.01.10001 gewählt wurde - es ist zweifellos ein Erbe aus der Zeit, als SQL Server in den 1990er Jahren Sybase war. Sie müssen die Entwurfsentscheidung frühzeitig getroffen haben und das Microsoft SQL-Team hat keinen Grund gesehen, sie zu ändern.
Seit der Explosion von .NET und der Integration in SQL Server gibt es jetzt das DateTime2- Objekt für die Kompatibilität. Wenn Sie ein NHibernate-Benutzer sind, können Sie diesen Typ in Ihren Typzuordnungen angeben, um DateTime.MinProbleme zu vermeiden
.NET-Daten berücksichtigen andere Kalender als den gregorianischen:
Der JulianCalendar enthält aktuelle Daten DateTime.MinValue
Zwei verschiedene Gruppen entschieden, was "Minimum" für sie in Bezug auf Datum / Uhrzeit bedeutet.
SQL verwendet eine andere interne Darstellung für DateTime.