Qual é o significado de 1/1/1753 no SQL Server?

Por que 1753? O que eles têm contra 1752? Meu tataravô tataravô ficaria muito ofendido.

A decisão de usar 1º de janeiro de 1753 ( 1753-01-01) como o valor mínimo de data para um datetime no SQL Server volta às origens do Sybase .

O significado da data em si pode ser atribuído a esse homem.

Philip Stanhope, 4º Conde de Chesterfield. Quem dirigiu a Lei do Calendário (Novo Estilo) 1750 através do Parlamento Britânico. Isso legislou para a adoção do calendário gregoriano para a Grã-Bretanha e suas então colônias.

Havia alguns dias faltando _{(link do arquivo da Internet)} no calendário britânico em 1752, quando o ajuste foi finalmente feito a partir do calendário juliano. 3 de setembro de 1752 a 13 de setembro de 1752 foram perdidos.

Kalen Delaney explicou a escolha desta maneira

Então, com 12 dias perdidos, como você pode calcular datas? Por exemplo, como você pode calcular o número de dias entre 12 de outubro de 1492 e 4 de julho de 1776? Você inclui os que faltam 12 dias? Para evitar a solução desse problema, os desenvolvedores originais do Sybase SQL Server decidiram não permitir datas anteriores a 1753. Você pode armazenar datas anteriores usando campos de caracteres, mas não pode usar nenhuma função de data e hora com as datas anteriores armazenadas em caracteres Campos.

A escolha de 1753 parece um tanto anglocêntrica, no entanto, como muitos países católicos na Europa usavam o calendário há 170 anos antes da implementação britânica (originalmente adiada devido à oposição da igreja ). Por outro lado, muitos países não reformaram seus calendários até muito mais tarde, em 1918, na Rússia. De fato, a Revolução de Outubro de 1917 começou em 7 de novembro sob o calendário gregoriano.

Tanto datetimeo novo datetime2tipo de dados mencionado na resposta de Joe não tentam explicar essas diferenças locais, mas simplesmente usam o calendário gregoriano.

Assim, com a maior variedade de datetime2

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

Devoluções

Sep  8 1752 12:00AM

Um ponto final com o datetime2tipo de dados é que ele usa o calendário gregoriano pró-séptico projetado para trás muito antes de realmente ser inventado, portanto é de uso limitado para lidar com datas históricas.

Isso contrasta com outras implementações de software, como a classe Java Gregorian Calendar, cujo padrão é seguir o calendário juliano para datas até 4 de outubro de 1582 e depois saltar para 15 de outubro de 1582 no novo calendário gregoriano. Ele lida corretamente com o modelo juliano do ano bissexto antes dessa data e o modelo gregoriano após essa data. A data de transição pode ser alterada pelo chamador ligando setGregorianChange().

Um artigo bastante divertido discutindo algumas peculiaridades com a adoção do calendário pode ser encontrado aqui .

O tataravô deve atualizar para o SQL Server 2008 e usar o tipo de dados DateTime2 , que suporta datas no intervalo: 0001-01-01 a 9999-12-31.

1752 foi o ano da Grã-Bretanha mudando do calendário juliano para o gregoriano. Acredito que duas semanas em setembro de 1752 nunca aconteceram como resultado, o que tem implicações para datas nessa área geral.

Uma explicação: http://uneasysilence.com/archive/2007/08/12008/ ( versão do Internet Archive )

Esta é a história completa de como foi o problema da data e como os Big DBMSs lidaram com esses problemas.

Durante o período entre 1 dC e hoje, o mundo ocidental realmente usou dois calendários principais: o calendário juliano de Júlio César e o calendário gregoriano do papa Gregório XIII. Os dois calendários diferem em relação a apenas uma regra: a regra para decidir o que é um ano bissexto. No calendário juliano, todos os anos divisíveis por quatro são bissextos. No calendário gregoriano, todos os anos divisíveis por quatro são anos bissextos, exceto que os anos divisíveis por 100 (mas não divisíveis por 400) não são anos bissextos. Assim, os anos 1700, 1800 e 1900 são anos bissextos no calendário juliano, mas não no calendário gregoriano, enquanto os anos 1600 e 2000 são anos bissextos nos dois calendários.

Quando o papa Gregório XIII introduziu seu calendário em 1582, ele também ordenou que os dias entre 4 de outubro de 1582 e 15 de outubro de 1582 fossem ignorados - ou seja, ele disse que o dia seguinte a 4 de outubro deveria ser 15 de outubro. Muitos países atrasou a mudança, no entanto. A Inglaterra e suas colônias não mudaram do acerto de contas juliano para gregoriano até 1752, portanto, para eles, as datas ignoradas foram entre 4 e 14 de setembro de 1752. Outros países mudaram em outros momentos, mas 1582 e 1752 são as datas relevantes para o DBMSs que estamos discutindo.

Assim, surgem dois problemas com a aritmética da data, quando se volta há muitos anos. A primeira é: os anos bissextos antes de a troca ser calculada de acordo com as regras julianas ou gregorianas? O segundo problema é quando e como devem ser tratados os dias ignorados?

É assim que os Big DBMSs lidam com estas perguntas:

• Finja que não houve troca. É isso que o SQL Standard parece exigir, embora o documento padrão não seja claro: apenas diz que as datas são "restringidas pelas regras naturais para datas usando o calendário gregoriano" - sejam quais forem as "regras naturais". Esta é a opção que o DB2 escolheu. Quando existe a pretensão de que as regras de um único calendário sempre se aplicaram mesmo a momentos em que ninguém ouviu falar do calendário, o termo técnico é que um calendário "pré-séptico" está em vigor. Assim, por exemplo, poderíamos dizer que o DB2 segue um calendário gregoriano pró-séptico.
• Evite o problema completamente. A Microsoft e a Sybase definiram seus valores mínimos de data em 1º de janeiro de 1753, após o horário em que os Estados Unidos trocaram de calendário. Isso é defensável, mas de tempos em tempos surgem reclamações de que esses dois DBMSs não possuem uma funcionalidade útil que os outros DBMSs possuem e que o SQL Standard exige.
• Escolha 1582. Foi isso que a Oracle fez. Um usuário do Oracle descobriria que a expressão data-aritmética de 15 de outubro de 1582 menos 4 de outubro de 1582 produz um valor de 1 dia (porque não existe de 5 a 14 de outubro) e que a data de 29 de fevereiro de 1300 é válida (porque o salto juliano) aplica-se a regra do ano). Por que a Oracle teve problemas extras quando o SQL Standard parece não exigir isso? A resposta é que os usuários podem exigir isso. Historiadores e astrônomos usam esse sistema híbrido em vez de um calendário gregoriano pró-séptico. (Essa também é a opção padrão escolhida pela Sun ao implementar a classe GregorianCalendar para Java - apesar do nome, GregorianCalendar é um calendário híbrido.)

Fonte 1 e 2

Aliás, o Windows não sabe mais como converter corretamente o horário local do UTC para o EUA em determinadas datas em março / abril ou outubro / novembro dos anos anteriores. Os carimbos de data e hora baseados em UTC dessas datas agora são um tanto absurdos. Seria muito nojento para o sistema operacional simplesmente se recusar a lidar com qualquer registro de data e hora antes do último conjunto de regras de horário de verão do governo dos EUA, para que ele simplesmente lide com alguns deles erradamente. O SQL Server se recusa a processar datas anteriores a 1753, porque seria necessária muita lógica extra especial para manipulá-las corretamente e não deseja manipulá-las incorretamente.