Jag tror att skillnaden mellan SQL:s och .NET:s Datum datatyper härrör från det faktum att SQL Servers datetime datatypen, dess minimi- och maximivärden, och dess precision är mycket äldre än .NET:s DateTime-datatyp.
Med tillkomsten av .NET beslutade teamet att Datetime-datatypen skulle ha en mer naturlig minimumvärde, och 01/01/0001 verkar vara ett ganska logiskt val, och definitivt från ett programmeringsspråk , istället för databas perspektiv är detta värde mer naturligt.
För övrigt, med SQL Server 2008, finns det ett antal nya datumbaserade datatyper (Date, Time, DateTime2, DateTimeOffset) som faktiskt erbjuder ett ökat räckvidd och precision, och som är nära anslutna till DateTime-datatypen i .NET. Datatypen DateTime2 har till exempel ett datumintervall från 0001-01-01 till 9999-12-31.
Standarddatatypen "datetime" för SQL Server har alltid haft ett lägsta värde på 01/01/1753 (och har faktiskt fortfarande!). Jag måste erkänna att jag också var nyfiken på betydelsen av detta värde, så gjorde en del grävande. Det jag hittade var följande:
Under perioden mellan 1 e.Kr. och idag har västvärlden faktiskt använt två huvudkalendrar:Julius Caesars julianska kalender och påven Gregorius XIII:s gregorianska kalender. De två kalendrarna skiljer sig bara åt med avseende på en regel:regeln för att bestämma vad ett skottår är. I den julianska kalendern är alla år som är delbara med fyra skottår. I den gregorianska kalendern är alla år delbara med fyra skottår, förutom att år som är delbara med 100 (men inte delbara med 400) inte är skottår. Åren 1700, 1800 och 1900 är alltså skottår i den julianska kalendern men inte i den gregorianska kalendern, medan åren 1600 och 2000 är skottår i båda kalendrarna.
När påven Gregorius XIII introducerade sin kalender 1582 beordrade han också att dagarna mellan 4 oktober 1582 och 15 oktober 1582 skulle hoppas över – det vill säga han sa att dagen efter 4 oktober skulle vara 15 oktober. Många länder försenad omställning, dock. England och hennes kolonier bytte inte från julianskt till gregorianskt räkning förrän 1752, så för dem var de överhoppade datumen mellan 4 september och 14 september 1752. Andra länder bytte vid andra tidpunkter, men 1582 och 1752 är de relevanta datumen för DBMS som vi diskuterar.
Sålunda uppstår två problem med datumräkningen när man går tillbaka många år. Den första är, ska skottår innan bytet beräknas enligt de julianska eller gregorianska reglerna? Det andra problemet är när och hur ska de överhoppade dagarna hanteras?
Så här hanterar Big Eight DBMS dessa frågor:
Låtsas att det inte fanns någon switch. Detta är vad SQL-standarden verkar kräva, även om standarddokumentet är oklart:Det säger bara att datum är "begränsade av de naturliga reglerna för datum som använder den gregorianska kalendern" - vilka "naturliga regler" än är. Det här är alternativet som DB2 valde. När det finns en låtsas att en enda kalenders regler alltid har gällt även på tillfällen då ingen hört talas om kalendern, är den tekniska termen att en "proleptisk" kalender är i kraft. Så, till exempel, kan vi säga att DB2 följer en proleptisk gregoriansk kalender.
Undvik problemet helt och hållet. Microsoft och Sybase satte sina lägsta datumvärden till 1 januari 1753, säkert efter den tid då Amerika bytte kalendrar. Detta är försvarbart, men då och då dyker det upp klagomål om att dessa två DBMS saknar en användbar funktionalitet som de andra DBMS har och som SQL-standarden kräver.
Välj 1582. Detta är vad Oracle gjorde. En Oracle-användare skulle finna att det aritmetiska datumuttrycket 15 oktober 1582 minus 4 oktober 1582 ger ett värde på 1 dag (eftersom 5–14 oktober inte existerar) och att datumet 29 februari 1300 är giltigt (eftersom det julianska språnget- årsregeln gäller). Varför fick Oracle extra problem när SQL-standarden inte verkar kräva det? Svaret är att användare kan kräva det. Historiker och astronomer använder detta hybridsystem istället för en proleptisk gregoriansk kalender. (Detta är också standardalternativet som Sun valde när klassen GregorianCalendar implementerades för Java – trots namnet är GregorianCalendar en hybridkalender.)
Detta citat ovan är hämtat från följande länk:
SQL Performance Tuning:Datum i SQL