Quelle est la signification de 1/1753 dans SQL Server?
pourquoi 1753? Qu'ont-ils contre 1752? Mon great great great great great great great grand-père serait très offensé.
5 réponses
la décision d'utiliser le 1er janvier 1753 ( 1753-01-01 ) comme date minimum pour un datetime dans SQL Server remonte à son Sybase origins .
la signification de la date elle-même peut être attribuée à cet homme.
Philip Stanhope, 4e comte de Chesterfield. Qui a piloté le calendrier (Nouveau Style) loi 1750 par le biais de la 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 a eu quelques jours manquants dans le calendrier britannique en 1752 lorsque l'ajustement a finalement été fait à partir du calendrier julien. Du 3 septembre 1752 au 13 septembre 1752 sont perdus.
Kalen Delaney expliqué le choix de cette façon
So, avec 12 jours perdus, comment pouvez-vous calculer les dates? Par exemple, comment peut vous calculez le nombre de jours entre Le 12 octobre 1492 et le 4 juillet 1776? Faire vous incluez les 12 jours manquants? De éviter d'avoir à résoudre ce problème, le serveur SQL Sybase original les développeurs ont décidé de ne pas autoriser les dates avant 1753. Vous pouvez stocker plus tôt date en utilisant des champs de caractères, mais vous ne pouvez utiliser aucune fonction datetime avec les dates que vous stockez dans les champs de caractère.
le choix de 1753 semble quelque peu anglocentrique cependant comme beaucoup de pays catholiques en Europe avait utilisé le calendrier depuis 170 ans avant la mise en œuvre britannique (à l'origine retardé en raison de l'opposition par l'Église ). En revanche, de nombreux pays n'ont pas réformé leurs calendriers jusqu'à beaucoup plus tard, 1918 en Russie. En effet, la Révolution d'octobre de 1917 a commencé le 7 novembre sous le calendrier grégorien.
les deux datetime et le nouveau datetime2 type de données mentionné dans Joe's answer ne tentent pas de tenir compte de ces différences locales et utilisent simplement le calendrier grégorien.
ainsi avec la plus grande gamme de datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)
retourne
Sep 8 1752 12:00AM
un dernier point avec le type de données datetime2 est qu'il utilise le Gregorian proleptique calendrier projeté à l'envers bien avant qu'il n'ait été inventé est donc d'une utilité limitée dans le traitement des dates historiques.
ceci contraste avec d'autres implémentations logicielles telles que la classe Java calendrier grégorien qui suit par défaut le calendrier julien pour les dates jusqu'au 4 octobre 1582 puis sautant au 15 octobre 1582 dans le nouveau calendrier grégorien. Il traite 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 limite peut être changée par l'appelant en appelant setGregorianChange() .
un article assez divertissant discutant quelques particularités plus avec l'adoption du calendrier peut être trouvé ici .
votre great great great great great great great grandfather devrait mettre à niveau vers SQL Server 2008 et utiliser le type de données DateTime2 , qui prend en charge les dates dans l'intervalle: 0001-01-01 à 9999-12-31.
1752 est l'Année du passage de la Grande-Bretagne du calendrier julien au calendrier grégorien. Je crois que deux semaines en septembre 1752 ne s'est jamais produit 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/ ( Internet Archive version )
C'est toute l'histoire Comment date problème était et comment grand DBMSs a géré ces problèmes.
au cours de la période entre 1 A. D. 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 rapport à une seule règle: la règle pour décider de ce que année bissextile. Dans le calendrier Julien, toutes les années divisibles par quatre saut an. Dans le calendrier Grégorien, toutes les années divisibles par quatre 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 bissextiles années du calendrier julien mais pas du 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 présenté son calendrier en 1582, il a également ordonné que les jours entre le 4 octobre 1582, et octobre 15, 1582, devrait être sauté-c'est-à-dire, il a dit que le lendemain du 4 octobre devrait soyez le 15 octobre. Cependant, de nombreux pays ont tardé à changer. Angleterre et ses colonies ne sont pas passées de Julian à grégorien jusqu'en 1752, donc pour eux, les dates manquées étaient entre le 4 septembre et le 14 septembre 1752. D'autres pays mis à d'autres moments, mais 1582 et 1752 sont les dates pertinentes pour le Sgbd que nous sommes discuter.
Ainsi, deux problèmes se posent avec date arithmétique quand on remonte beaucoup an. La première est, si les années bissextiles avant que le commutateur soit calculé selon les règles juliennes ou grégoriennes? Le deuxième problème est, quand et comment faut-il Gérer les journées manquées?
Voici comment le Grand DBMSs traitent ces questions:
- prétendre qu'il n'y avait pas d'interrupteur. C'est ce que le standard SQL semble le document standard n'est pas clair: il dit que les dates sont " limitées par les règles naturelles pour les dates Calendrier grégorien"selon les "lois naturelles". C'est l'option que DB2 a choisi. Quand il y a une prétention qu'un calendrier simple est les règles ont toujours été, même à des moments où personne n'a entendu parler de la calendrier, le terme technique est qu'un "proleptic" calendrier force. Ainsi, par exemple, nous pourrions dire que DB2 suit un proleptique Calendrier grégorien.
- Évitez le problème entièrement. Microsoft et Sybase fixez leurs dates minimales au 1er janvier 1753, en toute sécurité après le temps que l'Amérique commutation de calendriers. C'est défendable, mais de temps en les plaintes de temps surface que ces deux DBMSs manquent d'un utile fonctionnalité que les autres DBMSs ont et que la norme SQL nécessite.
- choisir 1582. C'est ce que l'Oracle n'. Un utilisateur D'Oracle trouver que l'expression date-arithmétique octobre 1582 moins octobre 4 1582 donne une valeur de 1 jour (parce que les 5-14 octobre n'existent pas) et que la date du 29 février 1300 est valide (parce que L'année Julian leap la règle s'applique). Pourquoi Oracle a-t-il fait des problèmes supplémentaires quand le SQL Standard ne semble pas l'exiger? La réponse est que les utilisateurs peuvent l'exigent. Les historiens et les astronomes utilisent plutôt ce système hybride d'un calendrier gregorien. (C'est aussi l'option par défaut que le soleil a choisi lors de la mise en œuvre de la classe GregorianCalendar pour Java-malgré le nom, GregorianCalendar est un calendrier hybride.)
incidemment, Windows ne sait plus comment convertir correctement UTC en heure locale américaine pour certaines dates en Mars/Avril ou en octobre/novembre des années passées. Les horodatages basés sur UTC à partir de ces dates sont maintenant quelque peu absurdes. Il serait très glauque pour L'OS de simplement refuser de traiter n'importe quel timestampers avant la dernière série de règles de DST du gouvernement des États-Unis, de sorte qu'il traite tout simplement certains d'entre eux faux. SQL Server refuse de traiter les dates avant 1753 parce que beaucoup de logique spéciale supplémentaire serait requis pour les gérer correctement et il ne veut pas gérer les mauvais.