¿Cuál es la importancia de 1/1/1753 en SQL Server?

¿Por qué 1753? ¿Qué tienen contra 1752? Mi tatara-tatara-tatara-tatara-tatara-tatara-tatarabuelo se ofendería mucho.

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

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

Philip Stanhope, 4 ° conde de Chesterfield

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

Hubo algunos días faltantes en el calendario británico en 1752 cuando finalmente se hizo el ajuste del calendario juliano. El 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 se puede calcular las fechas? Por ejemplo, ¿cómo se puede calcular la cantidad de días entre el 12 de octubre de 1492 y el 4 de julio de 1776? ¿Incluyes esos días perdidos? Para evitar tener que resolver este problema, los desarrolladores originales de Sybase SQL Server decidieron no permitir las fechas anteriores a 1753. Puede almacenar fechas anteriores mediante el uso de campos de caracteres, pero no puede usar ninguna función de fecha y hora con las fechas anteriores que almacena en el carácter campos.

La elección de 1753 parece un tanto anglocéntrica, sin embargo, como muchos países católicos en Europa habían estado utilizando 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.

Tanto el datetime como el nuevo tipo de datos datetime2 mencionado en la respuesta de Joe no intentan dar cuenta de 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 tipo de datos datetime2 es que usa el calendario gregoriano proleptico proyectado hacia atrás mucho antes de que realmente se inventara, por lo que es de uso limitado al tratar con fechas históricas.

Esto contrasta con otras implementaciones de software, como la clase del calendario gregoriano de Java, que de manera predeterminada sigue al 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 anterior a esa fecha y el modelo gregoriano después de esa fecha. La persona que llama puede cambiar la fecha de setGregorianChange() llamando a setGregorianChange() .

Un artículo bastante entretenido discutiendo algunas más peculiaridades con la adopción del calendario se puede encontrar aquí .

Su gran tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-tatara-alto-alto-tatami-tatami-tatami-tatami-tatami-tatami-tatami-tatami

1752 fue el año en que Gran Bretaña pasó 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 una historia completa de cómo fue el problema de la fecha y cómo los grandes DBMS manejaron estos problemas.

Durante el período comprendido entre el año 1 dC y el día de 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é año bisiesto es. En el calendario juliano, todos los años divisibles por cuatro son bisiestos. En el calendario gregoriano, todos los años divisibles por cuatro son 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 los días comprendidos entre el 4 de octubre de 1582 y el 15 de octubre de 1582 se saltaran; es decir, que el día posterior al 4 de octubre sería el 15 de octubre. Muchos países retrasó el cambio, sin embargo. Inglaterra y sus colonias no cambiaron de juliano a gregoriano hasta 1752, así que para ellos, las fechas omitidas fueron entre el 4 de septiembre y el 14 de septiembre de 1752. Otros países cambiaron en otros momentos, pero 1582 y 1752 son las fechas relevantes para el SGBD que estamos discutiendo.

Por lo tanto, surgen dos problemas con la aritmética de fechas cuando uno se remonta a muchos años atrás. La primera es, ¿deberían saltar años antes de que el interruptor se calcule de acuerdo con las reglas julianas o gregorianas? El segundo problema es cuándo y cómo deben manejarse los días salteados.

Así es como los Big DBMS manejan estas preguntas:

  • Imagina que no hubo cambio. Esto es lo que el estándar SQL parece requerir, aunque el documento estándar no está claro: simplemente dice que las fechas están “limitadas por las reglas naturales para las fechas que usan el calendario gregoriano”, independientemente de cuáles sean las “reglas naturales”. Esta es la opción que eligió DB2. Cuando existe el pretexto de que las reglas de un solo calendario siempre se han aplicado incluso en momentos en que nadie oyó hablar del calendario, el término técnico es que un calendario “proléptico” está en vigor. 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 mínimos de fecha el 1 de enero de 1753, con seguridad más allá del tiempo en que Estados Unidos cambió los calendarios. Esto es defendible, pero de vez en cuando surgen quejas de que estos dos DBMS carecen de una funcionalidad útil que los otros DBMS tienen 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 del 15 de octubre de 1582 menos el 4 de octubre de 1582 arroja un valor de 1 día (porque el 5 al 14 de octubre no existe) y que la fecha 29 de febrero de 1300 es válida (porque el salto a Julian regla de año aplica). ¿Por qué Oracle tuvo más problemas cuando el SQL Standard no parece necesitarlo? La respuesta es que los usuarios pueden necesitarlo. Los historiadores y los astrónomos usan este sistema híbrido en lugar de un calendario gregoriano proléptico. (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

A propósito, Windows ya no sabe cómo convertir correctamente UTC a la hora local de los EE. UU. Para ciertas fechas en marzo / abril o octubre / noviembre de años pasados. Las marcas de tiempo basadas en UTC de esas fechas ahora son un poco absurdas. Sería muy repugnante para el sistema operativo simplemente negarse a manejar las marcas de tiempo antes del último conjunto de reglas del horario de verano del gobierno de Estados Unidos, por lo que simplemente maneja algunas de ellas mal. SQL Server se niega a procesar las fechas anteriores a 1753 porque se necesitaría mucha lógica especial adicional para manejarlas correctamente y no desea manejarlas incorrectamente.