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

Question

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

Answer 1

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 su Sybase origins.

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

Philip Stanhope, cuarto conde de Chesterfield. Quién dirigió el Calendar (New Style) Act 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 missing days en el calendario británico en 1752 cuando el ajuste finalmente se hizo desde el calendario juliano. El 3 de septiembre de 1752 al 13 de septiembre de 1752 se perdieron.

Kalen Delaney explained la elección de esta manera

Así, con 12 días de baja, ¿cómo se puede fechas de cómputo? Por ejemplo, ¿cómo puede calcular la cantidad de días entre 12 de octubre de 1492 y 4 de julio de 1776? ¿Incluye los que faltan 12 días? Para evitar tener que resolver este problema, los originales servidor desarrolladores de Sybase SQL decidió no permitir las fechas antes de 1753. Puede almacenar anteriores fechas mediante el uso de campos de caracteres, pero no se puede utilizar cualquiera de las funciones de fecha y hora con el fechas anteriores que almacena en campos de caracteres.

La elección de 1753 parece un tanto anglocéntrica sin embargo, como many catholic countries en Europa había estado utilizando el calendario de 170 años antes de la aplicación británica (originalmente retrasado debido a la oposición by the church). 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 datetime y el nuevo tipo de datos datetime2 mencionado en Joe's answer no intenten dar cuenta de estas diferencias locales y simplemente use el Calendario Gregoriano.

Así, con la mayor gama de datetime2

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

devoluciones

Sep 8 1752 12:00AM 

Un punto final con el tipo de datos datetime2 es que utiliza la proleptic Gregorian calendar proyectado hacia atrás para así antes de que fue inventado por lo es de uso limitado al tratar con fechas históricas.

Esto contrasta con otras implementaciones de software como la clase Java Gregorian Calendar que se predetermina a seguir el calendario juliano para las fechas hasta el 4 de octubre de 1582 y luego saltar 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 corte llamando al setGregorianChange().

Un artículo bastante entretenido discutiendo algunas más peculiaridades con la adopción del calendario can be found here.

Answer 2

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/ (Internet Archive version)

Answer 3

su gran gran gran gran gran gran gran abuelo debe actualizar a SQL Server 2008 y utilizar el tipo de datos DateTime2, que soporta fechas del rango: 0001-01-01 hasta 9999-12-31.

Answer 4

Dicho sea de paso, 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 los últimos años. 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 EE. UU., Por lo que simplemente maneja algunas de ellas incorrectas. 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.

Answer 5

Esta es toda la historia sobre cómo fue el problema de la fecha y cómo los grandes DBMS manejaron estos problemas.

Durante el periodo comprendido entre el 1 dC y hoy en día, el mundo occidental ha realmente 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 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 saltos años 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 Gregory XIII presenta su calendario en 1582, también dirigida que los días entre el 4 de octubre de, 1582, y 15 de octubre, 1582, se debe omitir, es decir, dijo que el día después del 4 de octubre de debe sea el 15 de octubre. Sin embargo, muchos países retrasaron el cambio. Inglaterra y sus colonias no pasaron de Julian a Gregorian hasta 1752, por lo que para ellos, las fechas omitidas fueron entre 4 de septiembre de y 14 de septiembre de 1752. Otros países cambiaron en otros momentos, pero 1582 y 1752 son los fechas relevantes para los DBMS que estamos hablando .

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

Esta es la forma en la Gran DBMS manejar estas preguntas:

• Haga de cuenta que no había interruptor. Esto es lo que requiere 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 ", independientemente de cuáles sean las "reglas naturales". Esta es la opción que DB2 eligió. Cuando existe el pretexto de que las reglas de un solo calendario siempre se han aplicado incluso cuando no se ha escuchado sobre el calendario , el término técnico es que un calendario "proléptico" está en forzado. Entonces, por ejemplo, podríamos decir que DB2 sigue un calendario gregoriano proléptico.
• Evite el problema por completo. Microsoft y Sybase establecen sus valores de fecha mínima al 1 de enero de 1753, con seguridad más allá del tiempo que América cambió los calendarios. Esto es defendible, pero de tiempo a 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 podría encontrar que la expresión aritmética de fecha 15 de octubre 1582 menos octubre 4 1582 produce un valor de 1 día (porque 5-14 de octubre no existe) y que la fecha 29 de febrero de 1300 es válida (porque el Se aplica la regla del año bisiesto juliano ). ¿Por qué Oracle tuvo más problemas cuando el estándar SQL no parece requerirlo? La respuesta es que los usuarios pueden requerirlo. Los historiadores y astrónomos usan este sistema híbrido en su lugar de un calendario gregoriano proléptico. (Esta es también la opción por defecto que Sun recogió la hora de implementar la clase GregorianCalendar para Java-a pesar del nombre, es un calendario GregorianCalendar híbrido.)

Fuente 1 y 2