Eu acho que a diferença entre a Data do SQL e do .NET tipos de dados decorre do fato de que o datetime do SQL Server tipo de dados, seus valores mínimo e máximo e sua precisão são muito mais antigos que o tipo de dados DateTime do .NET.
Com o advento do .NET, a equipe decidiu que o tipo de dados Datetime deveria ter um formato mais natural valor mínimo, e 01/01/0001 parece uma escolha bastante lógica, e certamente de uma linguagem de programação , em vez de banco de dados perspectiva, esse valor é mais natural.
A propósito, com o SQL Server 2008, há vários novos tipos de dados baseados em data (Date, Time, DateTime2, DateTimeOffset) que realmente oferecem um intervalo e uma precisão maiores e mapeiam de perto para o tipo de dados DateTime no .NET. Por exemplo, o tipo de dados DateTime2 tem um intervalo de datas de 0001-01-01 a 9999-12-31.
O tipo de dados padrão "datetime" do SQL Server sempre teve um valor mínimo de 01/01/1753 (e, de fato, ainda tem!). Devo admitir, eu também estava curioso quanto ao significado desse valor, então fiz algumas pesquisas.. O que encontrei foi o seguinte:
Durante o período entre 1 d.C. e hoje, o mundo ocidental 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 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 em ambos os 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 deveriam ser omitidos - isto é, ele disse que o dia seguinte a 4 de outubro deveria ser 15 de outubro. mas atrasou a mudança. A Inglaterra e suas colônias não mudaram do cálculo juliano para o gregoriano até 1752, então, para eles, as datas omitidas 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 de datas quando se retrocede muitos anos. A primeira é, os anos bissextos antes da mudança devem ser calculados de acordo com as regras julianas ou gregorianas? O segundo problema é:quando e como os dias omitidos devem ser tratados?
É assim que os Oito Grandes SGBDs lidam com essas questões:
Finja que não havia interruptor. Isso é o que o padrão SQL parece exigir, embora o documento padrão não seja claro:ele apenas diz que as datas são "restringidas pelas regras naturais para datas usando o calendário gregoriano" - quaisquer que sejam as "regras naturais". Esta é a opção que o DB2 escolheu. Quando há 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 "proléptico" está em vigor. Assim, por exemplo, poderíamos dizer que o DB2 segue um calendário gregoriano proléptico.
Evite totalmente o problema. Microsoft e Sybase definiram seus valores mínimos de data em 1º de janeiro de 1753, com segurança após a época em que os Estados Unidos trocaram de calendário. Isso é defensável, mas de tempos em tempos surgem reclamações de que esses dois SGBDs não possuem uma funcionalidade útil que os outros SGBDs possuem e que o padrão SQL exige.
Escolha 1582. Foi isso que a Oracle fez. Um usuário Oracle descobriria que a expressão aritmética de data 15 de outubro de 1582 menos 4 de outubro de 1582 produz um valor de 1 dia (porque 5 a 14 de outubro não existem) e que a data de 29 de fevereiro de 1300 é válida (porque o salto Juliano regra do ano se aplica). 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 proléptico. (Esta também é a opção padrão que a Sun escolheu ao implementar a classe GregorianCalendar para Java – apesar do nome, GregorianCalendar é um calendário híbrido.)
Esta citação acima foi retirada do seguinte link:
Ajuste de desempenho do SQL:datas no SQL
