Creo que la diferencia entre Date de SQL y .NET tipos de datos proviene del hecho de que datetime de SQL Server El tipo de datos, sus valores mínimo y máximo y su precisión son mucho más antiguos que el tipo de datos DateTime de .NET.
Con la llegada de .NET, el equipo decidió que el tipo de datos Datetime debería tener un aspecto más natural. valor mínimo, y 01/01/0001 parece una opción bastante lógica, y ciertamente de un lenguaje de programación , en lugar de base de datos perspectiva, este valor es más natural.
Por cierto, con SQL Server 2008, hay una serie de nuevos tipos de datos basados en fechas (Date, Time, DateTime2, DateTimeOffset) que en realidad ofrecen un mayor rango y precisión, y se corresponden estrechamente con el tipo de datos DateTime en .NET. Por ejemplo, el tipo de datos DateTime2 tiene un rango de fechas desde 0001-01-01 hasta 9999-12-31.
El tipo de datos estándar de "fecha y hora" de SQL Server siempre ha tenido un valor mínimo de 01/01/1753 (¡y de hecho todavía lo tiene!). Debo admitir que yo también tenía curiosidad sobre el significado de este valor, así que investigué un poco. Lo que encontré fue lo siguiente:
Durante el período comprendido entre el 1 d.C. y la actualidad, el mundo occidental ha utilizado dos calendarios principales:el calendario juliano de Julio César y el calendario gregoriano del Papa Gregorio XIII. Los dos calendarios difieren con respecto a una sola regla:la regla para decidir qué es un año bisiesto. En el calendario juliano, todos los años divisibles por cuatro son años bisiestos. En el calendario gregoriano, todos los años divisibles por cuatro son años bisiestos, excepto que los años divisibles por 100 (pero no divisibles por 400) no son años bisiestos. Así, los años 1700, 1800 y 1900 son bisiestos en el calendario juliano pero no en el calendario gregoriano, mientras que los años 1600 y 2000 son bisiestos en ambos calendarios.
Cuando el Papa Gregorio XIII presentó su calendario en 1582, también ordenó que se omitieran los días entre el 4 de octubre de 1582 y el 15 de octubre de 1582, es decir, dijo que el día posterior al 4 de octubre debería ser el 15 de octubre. Muchos países Sin embargo, retrasó el cambio. Inglaterra y sus colonias no cambiaron del cómputo juliano al gregoriano hasta 1752, por lo que para ellos, las fechas omitidas fueron entre el 4 y el 14 de septiembre de 1752. Otros países cambiaron en otros momentos, pero 1582 y 1752 son las fechas relevantes para el DBMS que estamos discutiendo.
Por lo tanto, surgen dos problemas con la aritmética de fechas cuando uno retrocede muchos años. La primera es, ¿deberían calcularse los años bisiestos antes del cambio de acuerdo con las reglas julianas o gregorianas? El segundo problema es, ¿cuándo y cómo deben manejarse los días omitidos?
Así es como los Big Eight DBMS manejan estas preguntas:
-
Finge que no hubo interruptor. Esto es lo que parece requerir el estándar SQL, aunque el documento estándar no está claro:simplemente dice que las fechas están "restringidas por las reglas naturales para las fechas que usan el calendario gregoriano", sean cuales sean las "reglas naturales". Esta es la opción que eligió DB2. Cuando existe la pretensión de que las reglas de un calendario único siempre se han aplicado incluso en momentos en que nadie había oído hablar del calendario, el término técnico es que está en vigor un calendario "proléptico". Entonces, por ejemplo, podríamos decir que DB2 sigue un calendario gregoriano proléptico.
-
Evita el problema por completo. Microsoft y Sybase establecieron sus valores de fecha mínimos en el 1 de enero de 1753, con seguridad más allá del momento en que Estados Unidos cambió de calendario. Esto es defendible, pero de vez en cuando surgen quejas de que estos dos DBMS carecen de una funcionalidad útil que tienen los otros DBMS y que requiere el estándar SQL.
-
Elija 1582. Esto es lo que hizo Oracle. Un usuario de Oracle encontraría que la expresión aritmética de fecha 15 de octubre de 1582 menos 4 de octubre de 1582 arroja un valor de 1 día (porque del 5 al 14 de octubre no existen) y que la fecha 29 de febrero de 1300 es válida (porque el salto juliano se aplica la regla del año). ¿Por qué Oracle tuvo problemas adicionales cuando el estándar SQL no parece requerirlo? La respuesta es que los usuarios pueden necesitarlo. Los historiadores y astrónomos utilizan este sistema híbrido en lugar de un calendario gregoriano proléptico. (Esta es también la opción predeterminada que eligió Sun al implementar la clase GregorianCalendar para Java; a pesar del nombre, GregorianCalendar es un calendario híbrido).
Esta cita anterior está tomada del siguiente enlace:
Ajuste del rendimiento de SQL:fechas en SQL
