¿Cuál es el significado de 1/1/1753 en SQL Server?

¿Por qué 1753? ¿Qué tienen contra 1752? Mi tatara tatara tatara tatara tatarabuelo estaría muy ofendido.

La decisión de usar el 1 de enero de 1753 ( 1753-01-01) como el valor de fecha mínimo para una fecha y hora en SQL Server vuelve a sus orígenes Sybase .

Sin embargo, el significado de la fecha en sí puede atribuirse a este hombre.

Philip Stanhope, cuarto conde de Chesterfield. Quién dirigió la Ley de calendario (nuevo estilo) de 1750 a través del Parlamento británico. Esto legisló para la adopción del calendario gregoriano para Gran Bretaña y sus colonias.

Hubo algunos días faltantes _{(enlace de archivo de Internet)} en el calendario británico en 1752 cuando el ajuste finalmente se realizó desde el calendario juliano. 3 de septiembre de 1752 al 13 de septiembre de 1752 se perdieron.

Kalen Delaney explicó la elección de esta manera

Entonces, con 12 días perdidos, ¿cómo puedes calcular las fechas? Por ejemplo, ¿cómo puede calcular el número de días entre el 12 de octubre de 1492 y el 4 de julio de 1776? ¿Incluyen los que faltan 12 días? Para evitar tener que resolver este problema, los desarrolladores originales de Sybase SQL Server decidieron no permitir fechas anteriores a 1753. Puede almacenar fechas anteriores utilizando campos de caracteres, pero no puede usar ninguna función de fecha y hora con las fechas anteriores que almacena en caracteres. campos.

Sin embargo, la elección de 1753 parece algo anglocéntrica, ya que muchos países católicos en Europa habían estado usando el calendario durante 170 años antes de la implementación británica (originalmente retrasado debido a la oposición de la iglesia ). Por el contrario, muchos países no reformaron sus calendarios hasta mucho más tarde, 1918 en Rusia. De hecho, la Revolución de Octubre de 1917 comenzó el 7 de noviembre bajo el calendario gregoriano.

Ambos datetimey el nuevo datetime2tipo de datos mencionado en la respuesta de Joe no intentan explicar estas diferencias locales y simplemente usan el calendario gregoriano.

Entonces, con el mayor rango de datetime2

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

Devoluciones

Sep  8 1752 12:00AM

Un último punto con el datetime2tipo de datos es que utiliza el calendario gregoriano proleptico proyectado hacia atrás mucho antes de que realmente se inventara, por lo que tiene un uso limitado para tratar fechas históricas.

Esto contrasta con otras implementaciones de software, como la clase de calendario gregoriano de Java , que por defecto sigue el calendario juliano para las fechas hasta el 4 de octubre de 1582 y luego salta al 15 de octubre de 1582 en el nuevo calendario gregoriano. Maneja correctamente el modelo juliano del año bisiesto antes de esa fecha y el modelo gregoriano después de esa fecha. La persona que llama puede cambiar la fecha de transición llamando setGregorianChange().

Aquí puede encontrar un artículo bastante entretenido que discute algunas peculiaridades más con la adopción del calendario .

Su tatara tatara tatara tatara tatarabuelo debería actualizarse a SQL Server 2008 y usar el tipo de datos DateTime2 , que admite fechas en el rango: 0001-01-01 a 9999-12-31.

1752 fue el año en que Gran Bretaña cambió del calendario juliano al gregoriano. Creo que dos semanas en septiembre de 1752 nunca sucedieron como resultado, lo que tiene implicaciones para las fechas en esa área general.

Una explicación: http://uneasysilence.com/archive/2007/08/12008/ ( versión de Internet Archive )

Esta es toda la historia de cómo era el problema de la fecha y cómo Big DBMS manejó estos problemas.

Durante el período comprendido entre el año 1 DC y hoy, 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. Por lo tanto, los años 1700, 1800 y 1900 son años bisiestos en el calendario juliano pero no en el calendario gregoriano, mientras que los años 1600 y 2000 son años 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 después del 4 de octubre debería ser el 15 de octubre. Muchos países Sin embargo, retrasó el cambio. Inglaterra y sus colonias no cambiaron de Julian a Gregorian 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 transcurrir años antes de que el cambio se calcule de acuerdo con las reglas julianas o gregorianas? El segundo problema es, ¿cuándo y cómo se deben manejar los días omitidos?

Así es como los Grandes DBMS manejan estas preguntas:

• Finge que no hubo cambio. Esto es lo que parece requerir el Estándar SQL, aunque el documento estándar no está claro: solo dice que las fechas están "restringidas por las reglas naturales para las fechas que usan el calendario gregoriano", lo que sean las "reglas naturales". Esta es la opción que eligió DB2. Cuando se pretende que las reglas de un solo calendario se hayan aplicado siempre, incluso cuando nadie ha oído hablar del calendario, el término técnico es que está vigente un calendario "proleptico". Entonces, por ejemplo, podríamos decir que DB2 sigue un calendario gregoriano proleptico.
• Evita el problema por completo. Microsoft y Sybase establecieron sus valores mínimos de fecha al 1 de enero de 1753, más allá del tiempo 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 descubriría que la expresión aritmética de fecha 15 de octubre de 1582 menos el 4 de octubre de 1582 arroja un valor de 1 día (porque no existen del 5 al 14 de octubre) y que la fecha del 29 de febrero de 1300 es válida (porque el salto de Julian- 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 requerirlo. Los historiadores y astrónomos utilizan este sistema híbrido en lugar de un calendario gregoriano proleptico. (Esta es también la opción predeterminada que Sun eligió al implementar la clase GregorianCalendar para Java, a pesar del nombre, GregorianCalendar es un calendario híbrido).

Fuente 1 y 2

Por cierto, Windows ya no sabe cómo convertir correctamente la hora UTC a la hora local de EE. UU. Para ciertas fechas en marzo / abril u octubre / noviembre de años anteriores. Las marcas de tiempo basadas en UTC de esas fechas ahora son algo absurdas. Sería muy asqueroso que el sistema operativo simplemente se negara a manejar las marcas de tiempo antes del último conjunto de reglas de DST del gobierno de los EE. UU., Por lo que simplemente maneja algunas de ellas mal. SQL Server se niega a procesar fechas anteriores a 1753 porque se necesitaría mucha lógica extra especial para manejarlos correctamente y no quiere manejarlos incorrectamente.