SqlDateTime.MinValue! = DateTime.MinValue, pourquoi?

Question

Je me demande pourquoi SqlDateTime.MinValue n'est pas identique à DateTime.MinValue?

Answer 1

Je pense que la différence entre les types de données Date de SQL et .NET provient du fait que le type de données datetime de SQL Server, ses valeurs minimale et maximale et sa précision beaucoup plus ancien que le type de données DateTime de .NET.

Avec l'avènement de .NET, l'équipe a décidé que le type de données Datetime devrait avoir une valeur minimale plus naturelle , et que 01/01/0001 semble un choix assez logique, et certainement à partir de < em> langage de programmation , plutôt que perspective , cette valeur est plus naturelle.

Incidemment, avec SQL Server 2008, il existe plusieurs nouveaux types de données basés sur la date ( Date , heure , DateTime2 , DateTimeOffset ) qui offre réellement une portée et une précision accrues et une correspondance étroite avec le type de données DateTime dans .NET. Par exemple, le type de données DateTime2 a une plage de dates allant du 0001-01-01 à 9999-12-31.

Le standard "datetime". Le type de données de SQL Server a toujours eu une valeur minimale de 01/01/1753 (et a toujours!). Je dois avouer que j’étais moi aussi curieux de l’importance de cette valeur, de même que quelques fouilles. Ce que j’ai trouvé est le suivant:

  

Au cours de la période allant de l'an 1 à aujourd'hui, le monde occidental a en fait utilisé deux calendriers principaux: le calendrier julien de Jules César et le calendrier grégorien du pape Grégoire XIII. Les deux calendriers ne diffèrent que par une seule règle: la règle permettant de déterminer en quoi consiste une année bissextile. 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 non 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, alors que les années 1600 et 2000 sont des années bissextiles dans les deux calendriers.

     Lorsque le pape Grégoire XIII introduisit son calendrier en 1582, il ordonna également que les jours entre le 4 octobre 1582 et le 15 octobre 1582 fussent omis, c'est-à-dire qu'il déclara que le lendemain du 4 octobre 15 octobre. Cependant, de nombreux pays ont tardé à basculer. L'Angleterre et ses colonies ne sont pas passées du julien au calcul grégorien avant 1752; elles ont donc été ignorées entre le 4 et le 14 septembre 1752. D'autres pays ont changé à un autre moment, mais 1582 et 1752 sont les dates pertinentes pour la SGBD dont nous discutons.

     

Ainsi, l’arithmétique des dates pose deux problèmes lorsque l’on remonte à plusieurs années. La première est celle-ci: les années bissextiles avant le basculement devraient-elles être calculées selon les règles de Julien ou de Grégorien? Le deuxième problème est de savoir quand et comment les jours ignorés doivent être gérés?

     

Voici comment le Big Eight DBMS gère ces questions:

     

  

• Imaginez qu'il n'y ait pas de commutateur. C’est ce que la norme SQL semble exiger, même si le document standard n’est pas clair: il indique simplement que les dates sont "contraintes par les règles naturelles des dates utilisant le calendrier grégorien", quelles que soient les "règles naturelles". sont. C'est l'option choisie par DB2. Lorsqu'il est prétendu que les règles d'un seul calendrier ont toujours été appliquées, même à des moments où personne n'a entendu parler du calendrier, le terme technique est qu'un "proleptique" le calendrier est en vigueur. Ainsi, par exemple, nous pourrions dire que DB2 suit un calendrier proleptique grégorien.

  

• Évitez complètement le problème. Microsoft et Sybase ont défini leurs valeurs de date minimales au 1er janvier 1753, en toute sécurité après le moment où l'Amérique a changé de calendrier. Ceci est défendable, mais de temps en temps, des plaintes font valoir que ces deux SGBD ne disposent pas des fonctionnalités utiles des autres SGBD et que le standard SQL l'exige.

  

• Choisissez 1582. Voici ce que Oracle a fait. Un utilisateur Oracle constaterait que l'expression date-arithmétique du 15 octobre 1582 moins le 4 octobre 1582 donne une valeur de 1 jour (car le 5 octobre # 8211; 14 n'existe pas) et que la date du 29 février 1300 est valide (car le règle de l'année bissextile s'applique). Pourquoi Oracle a-t-il eu des problèmes supplémentaires alors que SQL Standard ne semble pas en avoir besoin? La réponse est que les utilisateurs peuvent en avoir besoin. Les historiens et les astronomes utilisent ce système hybride au lieu d'un calendrier proleptique grégorien. (C’est également l’option par défaut choisie par Sun lors de l’implémentation de la classe GregorianCalendar pour Java, malgré le nom, mais GregorianCalendar est un calendrier hybride.)

  

Cette citation ci-dessus provient du lien suivant:

Optimisation des performances SQL: Dates dans SQL

Answer 2

Depuis, dans SQL Server, la date minimale pouvant être stockée dans un champ datetime (1753/1/1) n’est pas égale à la MinValue du type de données DateTime .NET (0001/1/1).

Answer 3

1753 est la date du premier adoptant du calendrier grégorien (Angleterre). Pourquoi cette option a-t-elle été choisie par rapport au 01/01/0001? C’est sans aucun doute un héritage de l'époque où SQL Server était Sybase dans les années 1990. Ils ont dû prendre la décision de conception très tôt et l'équipe de Microsoft SQL n'a pas vu de raison de la changer.

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

Les dates .NET répondent à d'autres calendriers que le calendrier grégorien:

• Calendrier
  • ChineseLunisolarCalendar
  • EastAsianLunisolarCalendar
  • calendrier grégorien
  • HebrewCalendar
  • HijriCalendar
  • Calendrier japonais
  • JapaneseLunisolarCalendar
  • JulianCalendar
  • KoreanCalendar
  • KoreanLunisolarCalendar
  • Calendrier persan
  • TaiwanCalendar
  • Calendrier TaiwanLunisolar
  • Calendrier bouddhiste thaïlandais
  • UmAlQuraCalendar

L'information JulianCalendar est antérieure aux dates DateTime.MinValue

Answer 4

Deux groupes différents ont décidé du "minimum". signifie pour eux en ce qui concerne la date / heure.

Answer 5

SQL utilise une représentation interne différente pour DateTime.