fecha sql-server tsql datetime localization internationalization

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



set min date sql server (5)

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

Esta es toda la historia de cómo era el problema de la fecha y cómo los grandes DBMS manejaban estos problemas.

Durante el período comprendido entre el 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é 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 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 entre el 4 de octubre de 1582 y el 15 de octubre de 1582 se omitieran, es decir, dijo que el día posterior al 4 de octubre debía ser el 15 de octubre. Muchos países Sin embargo, retrasado el cambio. Inglaterra y sus colonias no cambiaron de cuentas julianas a gregorianas hasta 1752, por lo que para ellos, las fechas omitidas fueron entre el 4 de septiembre y el 14 de septiembre de 1752. Otros países cambiaron en otras ocasiones, pero 1582 y 1752 son las fechas relevantes para la DBMSs que estamos discutiendo.

Así, dos problemas surgen con la aritmética de fecha cuando uno se remonta a muchos años. La primera es, ¿deberían saltarse años antes de que se calcule el cambio de acuerdo con las reglas de Julian o Gregorian? El segundo problema es, ¿cuándo y cómo deben manejarse los días omitidos?

Así es como los grandes DBMS manejan estas preguntas:

  • Finge que no había interruptor. Esto es lo que el estándar de SQL parece requerir, 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", cualquiera que sea "reglas naturales". Esta es la opción que DB2 eligió. Cuando hay una pretensión de que las reglas de un solo calendario siempre se han aplicado incluso en los momentos en que nadie ha oído 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 proleptico.
  • Evita el problema por completo. Microsoft y Sybase establecieron sus valores de fecha mínima el 1 de enero de 1753, después de la fecha en que América cambió los calendarios. 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.
  • Escoja 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 el 5 al 14 de octubre no existe) y que la fecha del 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 de SQL no parece requerirlo? 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 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

Incidentalmente, 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 anteriores. Las marcas de tiempo basadas en UTC de esas fechas ahora son un tanto absurdas. Sería muy difícil para el sistema operativo simplemente negarse a manejar cualquier marca de tiempo antes del último conjunto de reglas de horario de verano del gobierno de los EE. UU., Así que simplemente maneja algunas de ellas de forma incorrecta. 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 quiere manejarlas de forma incorrecta.

Su gran gran gran gran gran gran gran bisabuelo debe actualizar a SQL Server 2008 y usar el tipo de datos DateTime2 , que admite fechas en el rango: 0001-01-01 a 9999-12-31.

La decisión de usar el 1 de enero de 1753 ( 1753-01-01 ) como el valor de fecha mínima para una fecha y hora en SQL Server se remonta a sus orígenes de 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. Esta legislado para la adopción del calendario gregoriano para Gran Bretaña y sus colonias de entonces.

Faltaban algunos días en el calendario británico en 1752, cuando finalmente se hizo el ajuste del calendario juliano. 3 de septiembre de 1752 al 13 de septiembre de 1752 se perdieron.

Kalen Delaney explained la elección de esta manera.

Entonces, con 12 días perdidos, ¿cómo se pueden 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? ¿Incluyes esos 12 días perdidos? Para evitar tener que resolver este problema, los desarrolladores originales de Sybase SQL Server decidieron no permitir fechas antes de 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.

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

Tanto datetime como el nuevo tipo de datos datetime2 mencionados en la respuesta de Joe no intentan explicar estas diferencias locales y simplemente usan el calendario gregoriano.

Así que 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 utiliza el prolífico calendario gregoriano proyectado hacia atrás mucho antes de que se inventara, por lo que es de 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 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 posterior a esa fecha. El llamante puede cambiar la fecha de corte al llamar a setGregorianChange() .

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