SqlDateTime.MinValue != DateTime.MinValue, pourquoi?

Je pense que la différence entre SQL et .NET Date types de données provient du fait que SQL Server est datetime type de données, c'est les valeurs minimale et maximale, et c'est la précision sont beaucoup plus âgés que les .NET type de données DateTime.

Avec l'avènement de la .NET, l'équipe a décidé que le type de données Datetime devrait avoir un plus naturel valeur minimale, et 01/01/0001 semble assez logique, et certainement à partir d'un langage de programmation, plutôt que de base de données point de vue, cette valeur est plus naturel.

D'ailleurs, avec SQL Server 2008, il y a un certain nombre de nouvelle Date basée sur les types de données (Date, Le temps, DateTime2, DateTimeOffset) qui offre une augmentation de la portée et de précision, et étroitement carte pour le type de données DateTime dans .NET. Par exemple, le DateTime2 type de données a une plage de dates à partir de 0001-01-01 par 9999-12-31.

La norme "datetime" type de données de SQL Server a toujours eu une valeur minimale de 01/01/1753 (et toujours!). Je dois avouer, que j'étais trop curieux de savoir la signification de cette valeur, donc fait quelques recherches.. Ce que j'ai trouvé comme suit:

Au cours de la période comprise entre le 1er A. D. et aujourd'hui, le monde Occidental a effectivement utilisé principalement deux calendriers: le calendrier Julien de Jules César et le calendrier Grégorien du Pape Grégoire XIII. Les deux calendriers diffèrent par rapport à une seule règle: la règle pour décider de ce que l'année bissextile est. Dans le calendrier Julien, toutes les années divisibles par quatre sont des années bissextiles. Dans le calendrier Grégorien, toutes les années divisibles par quatre sont des années bissextiles, sauf que les années divisibles par 100 (mais pas divisible par 400) ne sont pas des années bissextiles. Ainsi, les années 1700, 1800 et 1900 sont des années bissextiles dans le calendrier Julien, mais pas dans le calendrier Grégorien, tandis que les années 1600 et 2000 sont des années bissextiles dans les deux calendriers.

Lorsque le Pape Grégoire XIII a présenté son calendrier en 1582, il a également dirigé le nombre de jours entre le 4 octobre 1582, et le 15 octobre 1582, doivent être ignorés—qui est, il a dit que le jour après le 4 octobre devrait être le 15 octobre. De nombreux pays en retard de changer, cependant. L'angleterre et ses colonies n'ai pas passer de Julien au Grégorien reckoning jusqu'en 1752, donc pour eux, le sauté de dates entre le 4 septembre et le 14 septembre 1752. D'autres pays mis à d'autres moments, mais 1582 et 1752 sont les dates pertinentes pour le Sgbd que nous sommes en train de discuter.

Ainsi, deux problèmes se posent avec la date de l'arithmétique lorsque l'on remonte à de nombreuses années. La première est de savoir si les années bissextiles avant que le commutateur être calculée selon le calendrier Julien ou Grégorien règles? Le deuxième problème est, quand et comment le sauté jours seront-ils traités?

C'est comment le Grand Huit Sgbd répondre à ces questions:

• Faire semblant il n'y a pas d'interrupteur. C'est ce que la Norme SQL semble que, bien que la norme document n'est pas clair: Il dit seulement que les dates sont "contraints par les règles naturelles pour les dates à l'aide du calendrier Grégorien"selon les "lois naturelles" sont. C'est l'option que DB2 choisi. Quand il y a un prétexte qu'un seul calendrier de règles ont toujours appliqué, même à des moments où personne n'a entendu parler du calendrier, le terme technique est qu'un "proleptic" calendrier est en vigueur. Ainsi, par exemple, on pourrait dire que DB2 suit un calendrier gregorien.

• Éviter tout problème. Microsoft et Sybase ensemble minimal de valeurs de date au 1er janvier 1753, en toute sécurité passé, le temps que l'Amérique commutation de calendriers. C'est défendable, mais de temps à autre des plaintes de la surface que ces deux Sgbd manque une fonctionnalité utile que les autres Sgbd et que la Norme SQL requiert.

• Choisir 1582. C'est ce que l'Oracle n'. Un utilisateur Oracle trouverait que la date-expression arithmétique 15 octobre 1582 moins 4 octobre 1582 donne une valeur de 1 jour (en raison d'octobre 5-14 n'existent pas) et que la date du 29 février 1300 est valide (parce que le Julien de l'année bissextile règle s'applique). Pourquoi Oracle aller à des problème lors de la Norme SQL ne semble pas à l'exiger? La réponse est que les utilisateurs pourraient avoir besoin d'elle. Les historiens et les astronomes utilisent ce système hybride à la place d'un calendrier gregorien. (C'est aussi l'option par défaut que le Soleil a choisi lors de l'implémentation de la classe GregorianCalendar pour Java—malgré le nom, GregorianCalendar est un hybride de calendrier.)

Cette citation ci-dessus, à partir de prises à partir du lien suivant:

SQL optimisation des Performances: les Dates en SQL

1753, était la date de la première à adopter le calendrier Grégorien (Angleterre). Pourquoi ce qui a été choisi 01/01/0001 - c'est sans doute l'héritage de lorsque SQL Server Sybase dans les années 1990. Ils ont pris la décision de conception dès le début, et Microsoft SQL équipe n'ai pas vu de raison de le modifier.

Depuis l'explosion de .NET et de l'intégration de Sql Server, il est maintenant le DateTime2 objet pour assurer la compatibilité. Si vous êtes un NHibernate utilisateur, vous pouvez fournir ce type dans votre type de mappages pour éviter DateTime.Min problèmes

.NET Dates de répondre pour les autres calendriers en plus de celui Grégorien:

• Calendrier
  • ChineseLunisolarCalendar
  • EastAsianLunisolarCalendar
  • GregorianCalendar
  • HebrewCalendar
  • HijriCalendar
  • JapaneseCalendar
  • JapaneseLunisolarCalendar
  • JulianCalendar
  • KoreanCalendar
  • KoreanLunisolarCalendar
  • PersianCalendar
  • TaiwanCalendar
  • TaiwanLunisolarCalendar
  • ThaiBuddhistCalendar
  • UmAlQuraCalendar

La JulianCalendar enfait pré-dates DateTime.MinValue

SQL utilise une autre représentation interne pour le type DateTime.