Je pense que la différence entre la date de SQL et celle de .NET les types de données proviennent du fait que le datetime de SQL Server type de données, ses valeurs minimale et maximale, et sa précision sont beaucoup plus anciennes 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 un aspect plus naturel valeur minimale, et 01/01/0001 semble un choix assez logique, et certainement d'un langage de programmation , plutôt que base de données perspective, cette valeur est plus naturelle.
Incidemment, avec SQL Server 2008, il existe un certain nombre de nouveaux types de données basés sur la date (Date, Time, DateTime2, DateTimeOffset) qui offrent en fait une plage et une précision accrues et correspondent étroitement au type de données DateTime dans .NET. Par exemple, le type de données DateTime2 a une plage de dates comprise entre 0001-01-01 et 9999-12-31.
Le type de données standard "datetime" de SQL Server a toujours eu une valeur minimale de 01/01/1753 (et en a toujours !). Je dois admettre que j'étais moi aussi curieux de connaître la signification de cette valeur, j'ai donc fait quelques recherches. Ce que j'ai trouvé était le suivant :
Au cours de la période entre 1 après JC et 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 diffèrent par une seule règle :la règle pour déterminer ce qu'est 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 divisibles 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 ordonné que les jours entre le 4 octobre 1582 et le 15 octobre 1582 soient ignorés, c'est-à-dire qu'il a dit que le lendemain du 4 octobre devrait être le 15 octobre. De nombreux pays cependant, le changement a été retardé. L'Angleterre et ses colonies ne sont pas passées du calcul julien au calcul grégorien avant 1752, donc pour elles, les dates sautées étaient entre le 4 septembre et le 14 septembre 1752. D'autres pays ont changé à d'autres moments, mais 1582 et 1752 sont les dates pertinentes pour le les SGBD dont nous parlons.
Ainsi, deux problèmes se posent avec l'arithmétique des dates lorsqu'on remonte plusieurs années en arrière. La première est la suivante :les années bissextiles avant le changement doivent-elles être calculées selon les règles juliennes ou grégoriennes ? Le deuxième problème est, quand et comment gérer les jours sautés ?
Voici comment les SGBD du Big Eight traitent ces questions :
Faire semblant qu'il n'y avait pas d'interrupteur. C'est ce que la norme SQL semble exiger, bien que le document standard ne soit pas clair :il dit simplement que les dates sont "contraintes par les règles naturelles pour les dates utilisant le calendrier grégorien" - quelles que soient les "règles naturelles". Il s'agit de l'option choisie par DB2. Quand on prétend que les règles d'un calendrier unique se sont toujours appliquées même à des moments où personne n'a entendu parler du calendrier, le terme technique est qu'un calendrier "proleptique" est en vigueur. Ainsi, par exemple, on pourrait dire que DB2 suit un calendrier grégorien proleptique.
Évitez complètement le problème. Microsoft et Sybase ont fixé leurs valeurs de date minimales au 1er janvier 1753, bien après l'heure à laquelle l'Amérique a changé de calendrier. C'est défendable, mais de temps en temps, des plaintes font surface selon lesquelles ces deux SGBD manquent d'une fonctionnalité utile que les autres SGBD ont et que la norme SQL exige.
Choisissez 1582. C'est ce qu'Oracle a fait. Un utilisateur d'Oracle trouverait que l'expression arithmétique de date du 15 octobre 1582 moins le 4 octobre 1582 donne une valeur de 1 jour (parce que le 5 au 14 octobre n'existe pas) et que la date du 29 février 1300 est valide (parce que le saut julien- la règle de l'année s'applique). Pourquoi Oracle s'est-il donné du mal alors que le standard SQL ne semble pas l'exiger ? La réponse est que les utilisateurs pourraient en avoir besoin. Les historiens et les astronomes utilisent ce système hybride au lieu d'un calendrier grégorien proleptique. (Il s'agit également de l'option par défaut choisie par Sun lors de l'implémentation de la classe GregorianCalendar pour Java. Malgré son nom, GregorianCalendar est un calendrier hybride.)
Cette citation ci-dessus est tirée du lien suivant :
Réglage des performances SQL :dates en SQL
