Quelle est la signification du 1/1/1753 dans SQL Server?

Pourquoi 1753? Qu'ont-ils contre 1752? Mon arrière arrière arrière arrière arrière arrière arrière grand-père serait très offensé.

La décision d'utiliser le 1er janvier 1753 ( 1753-01-01) comme valeur de date minimale pour un datetime dans SQL Server remonte à ses origines Sybase .

L'importance de la date elle-même peut être attribuée à cet homme.

Philip Stanhope, 4e comte de Chesterfield. Qui a dirigé le Calendar (New Style) Act 1750 par le Parlement britannique. Cela a légiféré pour l'adoption du calendrier grégorien pour la Grande-Bretagne et ses colonies d'alors.

Il y avait quelques jours manquants _{(lien vers les archives Internet)} dans le calendrier britannique en 1752 lorsque l'ajustement a finalement été effectué à partir du calendrier julien. Du 3 septembre 1752 au 13 septembre 1752 ont été perdus.

Kalen Delaney a expliqué le choix de cette façon

Alors, avec 12 jours perdus, comment calculer les dates? Par exemple, comment calculer le nombre de jours entre le 12 octobre 1492 et le 4 juillet 1776? Incluez-vous ces 12 jours manquants? Pour éviter d'avoir à résoudre ce problème, les développeurs Sybase SQL Server d'origine ont décidé de ne pas autoriser les dates antérieures à 1753. Vous pouvez stocker des dates antérieures en utilisant des champs de caractères, mais vous ne pouvez pas utiliser de fonctions datetime avec les dates antérieures que vous stockez en caractère des champs.

Le choix de 1753 semble cependant quelque peu anglocentrique car de nombreux pays catholiques en Europe utilisaient le calendrier depuis 170 ans avant la mise en œuvre britannique (initialement retardé en raison de l'opposition de l'église ). À l'inverse, de nombreux pays n'ont réformé leur calendrier que bien plus tard, en Russie en 1918. En effet, la révolution d'octobre 1917 a commencé le 7 novembre sous le calendrier grégorien.

Les deux datetimeet le nouveau datetime2type de données mentionné dans la réponse de Joe n'essaient pas de tenir compte de ces différences locales et utilisent simplement le calendrier grégorien.

Donc, avec la plus grande gamme de datetime2

SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)

Retour

Sep  8 1752 12:00AM

Un dernier point avec le datetime2type de données est qu'il utilise le calendrier grégorien proleptique projeté en arrière bien avant qu'il ne soit réellement inventé et est donc d'une utilité limitée pour traiter les dates historiques.

Cela contraste avec d'autres implémentations logicielles telles que la classe Java Gregorian Calendar , qui suit par défaut le calendrier julien pour les dates jusqu'au 4 octobre 1582, puis passe au 15 octobre 1582 dans le nouveau calendrier grégorien. Il gère correctement le modèle julien de l'année bissextile avant cette date et le modèle grégorien après cette date. La date de basculement peut être modifiée par l'appelant en appelant setGregorianChange().

Un article assez divertissant discutant de quelques particularités supplémentaires avec l'adoption du calendrier peut être trouvé ici .

Votre arrière arrière arrière arrière arrière arrière arrière grand-père doit effectuer une mise à niveau vers SQL Server 2008 et utiliser le type de données DateTime2 , qui prend en charge les dates comprises entre 0001-01-01 et 9999-12-31.

1752 fut l'année de la Grande-Bretagne passant du calendrier julien au calendrier grégorien. Je crois que deux semaines en septembre 1752 ne se sont jamais produites en conséquence, ce qui a des implications pour les dates dans ce domaine général.

Une explication: http://uneasysilence.com/archive/2007/08/12008/ ( version Internet Archive )

C'est toute l'histoire du problème de date et de la façon dont les grands SGBD ont géré ces problèmes.

Au cours de la période comprise entre le 1 er 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 en ce qui concerne une seule règle: la règle pour décider 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é de sauter les jours entre le 4 octobre 1582 et le 15 octobre 1582, c'est-à-dire qu'il a déclaré que le lendemain du 4 octobre devrait être le 15 octobre. De nombreux pays retardé de changer, cependant. L'Angleterre et ses colonies ne sont passées de Julian à Grégorien qu'en 1752, donc pour elles, les dates ignorées se situaient 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 la SGBD dont nous discutons.

Ainsi, deux problèmes surviennent avec l'arithmétique des dates lorsque l'on remonte à plusieurs années. La première est la suivante: les années bissextiles doivent-elles être calculées selon les règles juliennes ou grégoriennes? Le deuxième problème est de savoir quand et comment gérer les jours ignorés.

Voici comment les Big DBMS traitent ces questions:

• Imaginez 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 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 calendrier "proleptique" est en vigueur. Ainsi, par exemple, nous pourrions 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, après l'heure à laquelle les calendriers américains ont changé de calendrier. C'est défendable, mais de temps en temps, des plaintes émergent que ces deux SGBD manquent d'une fonctionnalité utile que les autres SGBD ont et que la norme SQL requiert.
• Choisissez 1582. C'est ce qu'a fait Oracle. Un utilisateur Oracle constaterait que l'expression date-arithmétique 15 octobre 1582 moins 4 octobre 1582 donne une valeur de 1 jour (car les 5 et 14 octobre n'existent pas) et que la date du 29 février 1300 est valide (car le saut julien- la règle de l'année s'applique). Pourquoi Oracle s'est-il donné des ennuis supplémentaires 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.)

Source 1 et 2

Par ailleurs, Windows ne sait plus comment convertir correctement UTC en heure locale américaine pour certaines dates en mars / avril ou octobre / novembre des années précédentes. Les horodatages basés sur UTC à partir de ces dates sont maintenant quelque peu absurdes. Il serait très compliqué pour le système d'exploitation de simplement refuser de gérer les horodatages avant le dernier ensemble de règles DST du gouvernement américain, il en gère donc simplement certains de manière incorrecte. SQL Server refuse de traiter les dates antérieures à 1753 car il faudrait beaucoup de logique spéciale supplémentaire pour les gérer correctement et il ne veut pas les mal gérer.