Quelle est la signification de 1/1/1753 dans SQL Server?
Pourquoi 1753? Qu'est-ce qu'ils ont contre 1752? Mon 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 une date/heure dans SQL Server revient à sa valeur Sybase origins .
La signification de la date elle-même peut cependant être attribuée à cet homme.
Philip Stanhope, 4ème comte de Chesterfield. Qui a dirigé le Calendar (New Style) Act 175 par le Parlement britannique. Cela a légiféré pour l'adoption du calendrier grégorien pour la Grande-Bretagne et ses colonies de l'époque.
Il y avait quelques jours manquants dans le calendrier britannique en 1752 lorsque l'ajustement fut finalement effectué à partir du calendrier julien. 3 septembre 1752 au 13 septembre 1752 ont été perdus.
Kalen Delaney expliqué le choix de cette façon
Alors, avec 12 jours perdus, comment pouvez-vous calculer les dates? Par exemple, comment pouvez-vous calculer le nombre de jours entre le 12 octobre 1492 et le 4 juillet 1776? Incluez-vous les 12 jours manquants? Pour éviter de devoir 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 à l'aide de champs de caractères, mais vous ne pouvez utiliser aucune fonction datetime avec les dates antérieures que vous stockez en caractères. des champs.
Le choix de 1753 semble toutefois quelque peu anglocentrique car de nombreux pays catholiques en Europe utilisait le calendrier depuis 170 ans avant la mise en œuvre britannique (initialement retardée en raison d’une opposition de la part de l’Église ) Inversement, de nombreux pays n’ont réformé leur calendrier que bien plus tard, en 1918, en Russie. En effet, la révolution d’octobre 1917 a débuté le 7 novembre sous le calendrier grégorien.
datetime et le nouveau type de données datetime2 mentionné dans réponse de Joe ne tentent pas de prendre en compte 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)
Résultats
Sep 8 1752 12:00AM
Un dernier point avec le type de données datetime2 est qu’il utilise le calendrier proleptique grégorien projeté en arrière bien avant qu’il ait été réellement inventé, son utilisation est donc limitée dans le traitement des dates historiques.
Cela contraste avec d'autres implémentations logicielles telles que la classe Java calendrier grégorien , qui suit par défaut le calendrier julien jusqu'au 4 octobre 1582, puis passe au 15 octobre 1582 dans la nouvelle version. Calendrier Grégorien. Il gère correctement le modèle julien d’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 amusant traitant de plus de particularités 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 des dates comprises entre 0001-01-01 et 9999-12-31.
L'année 1752 a été marquée par le passage de la Grande-Bretagne du calendrier julien au calendrier grégorien. Je pense que deux semaines en septembre 1752 ne se sont jamais produites, ce qui a des conséquences pour les dattes de cette région.
Une explication: http://uneasysilence.com/archive/2007/08/12008/ ( version d'archive Internet )
C’est toute l’histoire du problème de la date et de la façon dont Big DBMS a géré ces problèmes.
Entre le 1er siècle et aujourd'hui, le monde occidental a 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 compris 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 serait le 15 octobre. De nombreux pays changement retardé, cependant. L'Angleterre et ses colonies ne sont pas passées du julien au 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 Grégorien? Le deuxième problème est de savoir quand et comment les jours sautés doivent être gérés.
Voici comment le Big SGBD traite ces questions:
- Prétendre qu'il n'y avait pas de commutateur. C'est ce que la norme SQL semble exiger, bien que le document standard ne soit pas clair: il indique 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". 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 calendrier "proleptique" est en vigueur. Ainsi, par exemple, nous pourrions dire que DB2 suit un calendrier proleptique grégorien.
- Évitez le problème entièrement. Microsoft et Sybase définissent leurs valeurs de date minimales au 1er janvier 1753, une fois dépassé 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 du standard SQL.
- 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 au 14 octobre n'existe pas) et que la date du 29 février 1300 est valide (car le saut Julian). règle de l'année 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é son nom, GregorianCalendar est un calendrier hybride.)
Incidemment, Windows ne sait plus comment convertir correctement UTC en heure locale aux États-Unis à certaines dates en mars/avril ou en 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 désagréable pour le système d’exploitation de refuser tout simplement de gérer les horodatages avant la dernière série de règles DST du gouvernement américain, de sorte que certains d’entre eux sont mal gérés. SQL Server refuse de traiter les dates antérieures à 1753, car il faudrait beaucoup de logique spéciale pour les traiter correctement, et il ne souhaite pas les gérer incorrectement.