SqlDateTime.MinValue! = DateTime.MinValue, por quê?

Question

Eu me pergunto, por que SqlDateTime.MinValue não é o mesmo que DateTime.MinValue?

Answer 1

Eu acho que a diferença entre o SQL de e .NET da Data tipos de dados decorre do fato de que do SQL Server datetime tipo de dados, é os valores mínimos e máximos, e de precisão são muito mais velho que tipo de dados DateTime do .NET.

Com o advento da NET, a equipe decidiu que o tipo de dados de data e hora deve ter um valor mínimo mais natural, e 01-01-0001 parece uma escolha bastante lógico, e, certamente, a partir de um < em> linguagem de programação , em vez de banco de dados perspectiva, este valor é mais natural.

A propósito, com o SQL Server 2008, há uma série de novos tipos de dados baseado na data ( Data , Tempo , DateTime2 , DateTimeOffset ) que realmente oferecem um maior alcance e precisão, e estreitamente mapear para o tipo de dados DateTime em .NET. Por exemplo, o tipo de dados DateTime2 tem um intervalo de datas a partir de 0001-01-01 a 9999-12-31.

O "data e hora" tipo de SQL Server de dados padrão sempre teve um valor mínimo de 1753/01/01 (e de fato ainda tem!). Eu devo admitir, eu também estava curioso para saber o significado desse valor, por isso fiz alguma escavação .. O que eu encontrei foi a seguinte:

Durante o período compreendido entre 1 dC e hoje, o mundo ocidental tem realmente utilizados 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 diferentes 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 anos 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ível por 400) não são anos bissextos. Assim, nos 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 apresenta o seu calendário em 1582, ele também dirigiu que os dias entre 04 de outubro de 1582, e 15 de Outubro, 1582, deve ser ignorada, isto é, ele disse que o dia depois de 04 de outubro deve ser 15 de outubro . Muitos países adiada mudando ao longo, no entanto. Inglaterra e suas colônias não mudar de Julian para acerto de contas gregoriano até 1752, então para eles, o ignorada datas foram entre 4 de Setembro e 14 de setembro de 1752. Outros países comutada em outras vezes, mas 1582 e 1752 são as relevantes para o SGBDs que estamos discutindo.

Assim, surgem dois problemas com a data aritmética quando se remonta há muitos anos. O primeiro é, deve saltar anos antes de o interruptor ser calculado de acordo com a Julian ou as regras gregorianos? O segundo problema é que, quando e como deve o Saltado dias ser tratado?

Esta é a forma como os Big Oito SGBDs lidar com essas questões:

• Fingir não havia interruptor. Isto é o que o padrão SQL parece exigir, embora o documento padrão é claro: Ele apenas diz que as datas são "limitados pelas regras naturais para datas usando o calendário gregoriano" -Tanto faz "regras naturais" são. Esta é a opção que o DB2 escolheu. Quando há uma pretensão de que as regras de um único calendário sempre aplicada mesmo aos tempos em que ninguém ouviu falar do calendário, o termo técnico é que um calendário "proleptic" está em vigor. Assim, por exemplo, poderíamos dizer que o DB2 segue um calendário gregoriano proleptic.

• Evite o problema por completo. Microsoft e Sybase definir seus valores mínimos data em 01 de janeiro de 1753, com segurança passado o tempo em que a América comutada calendários. Esta é defensável, mas de vez em quando queixas superfície que these dois SGBDs carecem de uma funcionalidade útil que os outros SGBDs têm e que o padrão SQL requer.

• Escolha de 1582. Este é o que a Oracle fez. user um Oracle teria que encontrar a expressão data-aritmética 15 de outubro de 1582 menos 04 de outubro de 1582 produz um valor de 1 dia (porque 05-14 outubro não existem) e que a data de 29 de fevereiro de 1300 é válido (porque o leap- Julian regra ano aplicável). Por que a Oracle ir ao problema extra quando o padrão SQL não parece exigir isso? A resposta é que os usuários podem exigir. Historiadores e astrônomos usam este sistema híbrido em vez de um calendário gregoriano proleptic. (Esta é também a opção padrão que a Sun pegou ao implementar a classe GregorianCalendar para Java-apesar do nome, GregorianCalendar é um calendário híbrido.)

Esta citação acima tomadas a partir do seguinte link:

SQL Performance Tuning: Datas em SQL

Answer 2

Uma vez que, no SQL Server a data mínima que pode ser armazenado em um campo de data e hora (1753/01/01), não é igual ao MinValue do tipo de dados DateTime .NET (0001/1/1).

Answer 3

1753 foi a data do primeiro adoptante do calendário gregoriano (Inglaterra). Quanto ao porquê isso foi escolhido em detrimento 01-01-0001 - não é legado dúvida de quando SQL Server foi Sybase na década de 1990. Eles devem ter feito a decisão de design no início e a equipe Microsoft SQL não vi uma razão para alterá-lo.

Desde a explosão da NET ea integração do que em SQL Server, existe agora a DateTime2 objeto para compatibilidade. Se você é um usuário do NHibernate, você pode fornecer este tipo em seus mapeamentos de tipo de problemas evitar DateTime.Min

.NET Datas atender a outros calendários, além de o gregoriano:

• Calendário
  • ChineseLunisolarCalendar
  • EastAsianLunisolarCalendar
  • GregorianCalendar
  • calendário judaico
  • HijriCalendar
  • JapaneseCalendar
  • JapaneseLunisolarCalendar
  • JulianCalendar
  • KoreanCalendar
  • KoreanLunisolarCalendar
  • PersianCalendar
  • TaiwanCalendar
  • TaiwanLunisolarCalendar
  • ThaiBuddhistCalendar
  • UmAlQuraCalendar

O JulianCalendar InFact datas pré-DateTime.MinValue

Answer 4

Dois grupos diferentes decidiu o que significa "mínimos" para eles em relação a data / hora.

Answer 5

SQL usa uma representação interna diferente para DateTime.