Pourquoi 1753 ? Qu'ont-ils 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 la valeur minimale de la date pour une date dans le serveur SQL remonte à sa date d'origine. Origine de Sybase .
L'importance de la date elle-même peut cependant être attribuée à cet homme.
Philip Stanhope, 4ème comte de Chesterfield. Qui a dirigé le Loi de 1750 sur le calendrier (nouveau style) par le Parlement britannique. Cette loi prévoyait l'adoption du calendrier grégorien pour la Grande-Bretagne et ses colonies de l'époque.
Il y a eu quelques jours manquants (lien vers les archives internet) dans le calendrier britannique en 1752, lorsque l'ajustement du calendrier julien a finalement été effectué. Les dates du 3 septembre 1752 au 13 septembre 1752 ont été perdues.
Kalen Delaney a expliqué le choix de cette façon
Donc, avec 12 jours de 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 ? Est-ce que inclure les 12 jours manquants ? Pour éviter d'avoir à résoudre ce problème, les développeurs originaux de Sybase SQL Server ont décidé de ne pas autoriser les dates avant 1753. Vous pouvez stocker des dates antérieures en utilisant des champs de caractères, mais vous ne pouvez pas utiliser de fonctions de date avec les dates antérieures que vous stockez dans des champs de caractères.
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ée en raison de l'opposition par l'église ). À l'inverse, 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.
Les deux sites datetime et le nouveau datetime2 mentionné dans La réponse de Joe ne tentent 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)Renvoie à
Sep 8 1752 12:00AMUn dernier point avec le datetime2 est qu'il utilise la fonction calendrier grégorien proleptique Il est donc d'une utilité limitée pour traiter des dates historiques.
Cela contraste avec d'autres implémentations logicielles telles que le système Java Calendrier grégorien qui suit par défaut le calendrier julien pour les dates jusqu'au 4 octobre 1582 puis saute au 15 octobre 1582 dans le nouveau calendrier grégorien. Elle 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 divertissant sur les particularités de l'adoption du calendrier. peuvent être trouvés ici .
+1 pour un grand portrait de l'arrière arrière arrière arrière arrière arrière arrière grand-père non offensé. Egalement d'autres attributs brillants de cette réponse.
+1 pour une réponse qui soit à la fois technique et historique. Sur un forum fréquenté par de gros cerveaux gauches, c'est une lecture agréable. Et oui, je suis allé dans une université d'arts libéraux.
Concernant ce lien Imaginez quelqu'un né en Suède le 30 février 1712 - il n'aurait jamais vieilli ! :P De même, que diable ont fait la Lituanie et la Lettonie pendant tout ce temps ?
Votre arrière-arrière-arrière-arrière-arrière-arrière-arrière-grand-père devrait passer à SQL Server 2008 et utiliser l'outil de mise à jour de la base de données. DateTime2 qui prend en charge les dates de l'intervalle : 0001-01-01 à 9999-12-31.
@CRMay : Dites-lui que vous prévoyez de commencer à travailler sur la conformité à l'an 2000 le jeudi 5000-01-02 ; cela vous laisse un peu moins de 5 millénaires pour régler le problème.
Mm Je suppose que quelqu'un a manqué la réponse à la vraie question : pourquoi 1753 de toutes les années ?
Oui.... mais essayez de faire passer ce changement de type de données dans une entreprise qui a une base installée massive de bases de données SQL Server, et plus de lignes de défense contre le redoutable CHANGEMENT ennemi que les États-Unis n'en avaient contre les ICBM russes au plus fort de la guerre froide...
1752 est l'année où la Grande-Bretagne est passée du calendrier julien au calendrier grégorien. Je crois que les deux semaines de septembre 1752 n'ont jamais eu lieu, ce qui a des conséquences sur les dates dans ce domaine général.
Une explication : http://uneasysilence.com/archive/2007/08/12008/ ( Version Internet Archive )
Voici l'histoire complète du problème des dates et de la façon dont les grands SGBD ont traité ces problèmes.
Durant la période entre l'an 1 de notre ère 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 sur une seule règle : celle qui permet de déterminer ce qu'est une année bissextile. Dans le calendrier julien, toutes les années divisibles par quatre sont années bissextiles. Dans le calendrier grégorien, toutes les années divisibles par quatre sont bissextiles, à l'exception des années divisibles par 100 (mais non divisibles par 400). 400) ne sont pas bissextiles. Ainsi, les années 1700, 1800 et 1900 sont bissextiles dans le calendrier julien, mais pas dans le calendrier grégorien. 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 a introduit son calendrier en 1582, il a également ordonné que les jours compris entre le 4 octobre 1582 et le 15 octobre 1582, devait être sauté, c'est-à-dire que le jour après le 4 octobre devait être le 15 octobre. De nombreux pays ont cependant retardé le passage à l'an 2000. L'Angleterre et ses colonies ne sont passées du système julien au système grégorien qu'en 1752. qu'en 1752, donc pour eux, les dates sautées se situaient entre le 4 septembre et le 14 septembre 1752. D'autres pays ont changé à d'autres moments, mais mais 1582 et 1752 sont les dates pertinentes pour les SGBDs dont nous discutons.
Ainsi, deux problèmes se posent avec l'arithmétique des dates lorsque l'on remonte à de nombreux années en arrière. Le premier est de savoir si les années bissextiles avant le changement doivent être calculées selon les règles juliennes ou grégoriennes ? Le second problème est le suivant, quand et comment les jours sautés doivent-ils être traités ?
C'est ainsi que les grands SGBD traitent ces questions :
- Faites comme s'il n'y avait pas d'interrupteur. C'est ce que la norme SQL semble exiger, bien que le document de la norme ne soit pas clair : il dit simplement que les 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 que DB2 a choisie. Lorsqu'on prétend que les règles d'un seul calendrier ont toujours d'un calendrier s'appliquent depuis toujours, même à des époques où personne n'a entendu parler de ce le terme technique est qu'un calendrier "proleptique" est en vigueur. en vigueur. Ainsi, par exemple, nous pourrions dire que DB2 suit un calendrier proleptique calendrier grégorien.
- Évitez complètement le problème. Microsoft et Sybase fixent leurs valeurs minimales de date au 1er janvier 1753, soit bien au-delà du moment où le que l'Amérique a changé de calendrier. C'est défendable, mais de temps en mais de temps en temps, des plaintes apparaissent pour dénoncer le fait que ces deux SGBD n'ont pas de date de référence utile. fonctionnalité utile que les autres SGBD ont et que la norme SQL exige. exige.
- Pick 1582. C'est ce qu'a fait Oracle. Un utilisateur d'Oracle constaterait que l'expression arithmétique de la date 15 octobre 1582 moins 4 octobre 4 octobre 1582 donne une valeur de 1 jour (car les 5-14 octobre n'existent pas) et que que la date du 29 février 1300 est valide (car la règle de l'année bissextile julienne s'applique). s'applique). Pourquoi Oracle s'est-il donné tant de mal alors que le SQL ne semble pas l'exiger ? La réponse est que les utilisateurs pourraient l'exigent. Les historiens et les astronomes utilisent plutôt ce système hybride d'un calendrier grégorien proleptique. (C'est aussi l'option par défaut que Sun a choisie lors de l'implémentation de la classe GregorianCalendar pour Java. Java - malgré son nom, GregorianCalendar est un calendrier hybride).
Par ailleurs, Windows ne sait plus comment convertir correctement l'UTC en heure locale américaine pour certaines dates de mars/avril ou d'octobre/novembre des années passées. Les horodatages basés sur l'UTC à partir de ces dates n'ont plus aucun sens. Il serait très dégoûtant que le système d'exploitation refuse tout simplement de traiter les horodatages antérieurs aux dernières règles de l'heure d'été du gouvernement américain. Le serveur SQL refuse de traiter les dates antérieures à 1753 parce qu'une logique spéciale supplémentaire serait nécessaire pour les traiter correctement et qu'il ne veut pas les traiter incorrectement.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
