SQL Server में 1/1/1753 का क्या महत्व है?
जवाबों:
1753-01-01SQL सर्वर में डेटाइम के लिए न्यूनतम दिनांक मान के रूप में 1 जनवरी 1753 ( ) का उपयोग करने का निर्णय अपने Sybase मूल में वापस जाता है ।
तारीख का महत्व हालांकि इस आदमी के लिए जिम्मेदार ठहराया जा सकता है।
फिलिप स्टेनहोप, चेस्टरफील्ड के 4 वें अर्ल। जिन्होंने ब्रिटिश संसद के माध्यम से कैलेंडर (नई शैली) अधिनियम 1750 को आगे बढ़ाया । इसने ब्रिटेन और उसके बाद के उपनिवेशों के लिए ग्रेगोरियन कैलेंडर को अपनाने के लिए कानून बनाया।
1752 में ब्रिटिश कैलेंडर में कुछ गायब दिन (इंटरनेट संग्रह लिंक) थे जब समायोजन अंततः जूलियन कैलेंडर से किया गया था। 3 सितंबर, 1752 से 13 सितंबर, 1752 तक खो गए थे।
कैलेन डेलाने ने इस तरह से पसंद को समझाया
तो, 12 दिनों के खो जाने के साथ, आप तिथियों की गणना कैसे कर सकते हैं? उदाहरण के लिए, आप 12 अक्टूबर, 1492 और 4 जुलाई, 1776 के बीच दिनों की संख्या की गणना कैसे कर सकते हैं? क्या आप 12 दिनों से लापता लोगों को शामिल करते हैं? इस समस्या को हल करने से बचने के लिए, मूल Sybase SQL सर्वर डेवलपर्स ने 1753 से पहले तारीखों की अनुमति नहीं देने का फैसला किया। आप चरित्र फ़ील्ड्स का उपयोग करके पहले की तारीखों को संग्रहीत कर सकते हैं, लेकिन आप पहले की तारीखों के साथ किसी भी डेटाइम फ़ंक्शन का उपयोग नहीं कर सकते हैं जिसे आप चरित्र में संग्रहीत करते हैं खेत।
1753 का चुनाव कुछ हद तक अस्पष्ट लगता है लेकिन यूरोप में कई कैथोलिक देश ब्रिटिश कार्यान्वयन से पहले 170 साल से कैलेंडर का उपयोग कर रहे थे (मूल रूप से चर्च द्वारा विरोध के कारण देरी हुई )। इसके विपरीत कई देशों ने अपने कैलेंडर में सुधार नहीं किया, 1918 तक रूस में। दरअसल 1917 की अक्टूबर क्रांति ग्रेगोरियन कैलेंडर के तहत 7 नवंबर को शुरू हुई थी।
जो के उत्तर में वर्णित दोनों datetimeनए datetime2डेटाटाइप इन स्थानीय अंतरों के लिए जिम्मेदार नहीं हैं और बस ग्रेगोरियन कैलेंडर का उपयोग करते हैं।
तो अधिक से अधिक रेंज के साथ datetime2
SELECT CONVERT(VARCHAR, DATEADD(DAY,-5,CAST('1752-09-13' AS DATETIME2)),100)रिटर्न
Sep 8 1752 12:00AMdatetime2डेटा प्रकार के साथ एक अंतिम बिंदु यह है कि इससे पहले कि यह वास्तव में आविष्कार किया गया था, ऐतिहासिक तारीखों से निपटने में सीमित उपयोग का है इससे पहले कि यह अच्छी तरह से पीछे की ओर proleptic ग्रेगोरियन कैलेंडर का उपयोग करता है।
यह अन्य सॉफ़्टवेयर कार्यान्वयन जैसे जावा ग्रेगोरियन कैलेंडर वर्ग के साथ विरोधाभास है जो 4 अक्टूबर, 1582 तक की तारीखों के लिए जूलियन कैलेंडर का पालन करने के लिए चूकता है और फिर नए ग्रेगोरियन कैलेंडर में 15 अक्टूबर, 1582 को कूदता है। यह उस तारीख से पहले लीप वर्ष के जूलियन मॉडल और उस तारीख के बाद ग्रेगोरियन मॉडल को सही ढंग से संभालता है। फोन करने वाले द्वारा कॉल करके डेटओवर तिथि को बदला जा सकता है setGregorianChange()।
कैलेंडर को अपनाने के साथ कुछ और ख़ासियतों पर चर्चा करने वाला एक काफी मनोरंजक लेख यहाँ पाया जा सकता है ।
आपके महान महान महान महान महान महान महान दादा को SQL Server 2008 में अपग्रेड करना चाहिए और DateTime2 डेटा प्रकार का उपयोग करना चाहिए , जो कि 9999-12-31 के माध्यम से रेंज में तारीखों का समर्थन करता है: 0001-01-01।
1752 जूलियन से ग्रेगोरियन कैलेंडर में स्विच करने वाला ब्रिटेन का वर्ष था। मेरा मानना है कि सितंबर 1752 में दो सप्ताह कभी नहीं हुए, जिसका उस सामान्य क्षेत्र में तारीखों के लिए निहितार्थ है।
एक स्पष्टीकरण: http://uneasysilence.com/archive/2007/08/12008/ ( इंटरनेट आर्काइव संस्करण )
यह पूरी कहानी है कि डेट प्रॉब्लम कैसे हुई और बिग डीबीएमएस ने इन समस्याओं को कैसे हैंडल किया।
1 ईस्वी और आज के बीच की अवधि के दौरान, पश्चिमी दुनिया ने वास्तव में दो मुख्य कैलेंडर का उपयोग किया है: जूलियस सीज़र के जूलियन कैलेंडर और पोप ग्रेगरी XIII के ग्रेगोरियन कैलेंडर। दो कैलेंडर केवल एक नियम के संबंध में भिन्न हैं: एक लीप वर्ष क्या है यह तय करने के लिए नियम। जूलियन कैलेंडर में, चार से विभाजित सभी वर्ष लीप वर्ष होते हैं। ग्रेगोरियन कैलेंडर में, चार साल से विभाजित सभी वर्ष लीप वर्ष होते हैं, सिवाय इसके कि वर्ष 100 से विभाज्य (लेकिन 400 से विभाज्य नहीं) छलांग वर्ष नहीं होते हैं। इस प्रकार, वर्ष 1700, 1800 और 1900 जूलियन कैलेंडर में लीप वर्ष हैं, लेकिन ग्रेगोरियन कैलेंडर में नहीं, जबकि 1600 और 2000 वर्ष दोनों कैलेंडर में लीप वर्ष हैं।
1582 में जब पोप ग्रेगरी XIII ने अपना कैलेंडर पेश किया, तो उन्होंने यह भी निर्देश दिया कि 4 अक्टूबर, 1582 और 15 अक्टूबर, 1582 के बीच के दिनों को छोड़ दिया जाए - यानी, उन्होंने कहा कि 4 अक्टूबर के बाद का दिन 15 अक्टूबर होना चाहिए। कई देश हालांकि बदलने में देरी हुई। इंग्लैंड और उसके उपनिवेशों ने जूलियन से ग्रेगोरियन के लिए 1752 तक गणना नहीं की, इसलिए उनके लिए छोड़ दी गई तारीखें 4 सितंबर से 14 सितंबर, 1752 के बीच थीं। अन्य देशों ने अन्य समय पर स्विच किया, लेकिन 1582 और 1752 के लिए प्रासंगिक तारीखें हैं DBMS जो हम चर्चा कर रहे हैं।
इस प्रकार, दो समस्याएं अंकगणित के साथ उत्पन्न होती हैं जब कोई कई वर्षों से वापस जाता है। पहला है, जूलियन या ग्रेगोरियन नियमों के अनुसार स्विच की गणना से पहले छलांग लगानी चाहिए? दूसरी समस्या यह है कि स्किप किए गए दिनों को कब और कैसे संभाला जाना चाहिए?
यह है कि बिग DBMS इन सवालों को कैसे हल करते हैं:
- कोई स्विच नहीं था। यह वही है जो SQL मानक की आवश्यकता प्रतीत होती है, हालांकि मानक दस्तावेज़ अस्पष्ट है: यह सिर्फ कहता है कि दिनांक "ग्रेगोरियन कैलेंडर का उपयोग करने वाली तिथियों के लिए प्राकृतिक नियमों द्वारा विवश हैं" -जो भी "प्राकृतिक नियम" हैं। यह वह विकल्प है जिसे DB2 ने चुना। जब यह ढोंग होता है कि किसी एक कैलेंडर के नियमों ने हमेशा उस समय पर भी लागू किया है जब किसी ने कैलेंडर के बारे में नहीं सुना है, तो तकनीकी शब्द यह है कि "प्रोलेप्टिक" कैलेंडर लागू है। इसलिए, उदाहरण के लिए, हम कह सकते हैं कि डीबी 2 एक प्रोलैप्टिक ग्रेगोरियन कैलेंडर का अनुसरण करता है।
- समस्या से पूरी तरह बचें। Microsoft और Sybase ने अपने न्यूनतम दिनांक मानों को 1 जनवरी 1753 को निर्धारित किया, जिस समय अमेरिका ने कैलेंडरों को स्विच किया। यह बचाव योग्य है, लेकिन समय-समय पर शिकायत की सतह है कि इन दो DBMS में एक उपयोगी कार्यक्षमता की कमी है जो अन्य DBMS के पास है और SQL मानक की आवश्यकता है।
- 1582 उठाओ। यही ओरेकल ने किया। ओरेकल यूजर को पता चलेगा कि दिनांक-अंकगणितीय अभिव्यक्ति 15 अक्टूबर 1582 माइनस 4 अक्टूबर 1582 1 दिन का मान देती है (क्योंकि अक्टूबर 5-14 तक मौजूद नहीं है) और यह कि तारीख 29 फरवरी 1300 वैध है (क्योंकि जूलियन लीप वर्ष नियम लागू होता है)। जब SQL मानक को इसकी आवश्यकता नहीं लगती, तो Oracle अतिरिक्त परेशानी में क्यों गया? इसका उत्तर यह है कि उपयोगकर्ताओं को इसकी आवश्यकता हो सकती है। इतिहासकार और खगोलविद एक प्रलेप्टिक ग्रेगोरियन कैलेंडर के बजाय इस संकर प्रणाली का उपयोग करते हैं। (यह भी डिफ़ॉल्ट विकल्प है जिसे जावा के लिए ग्रेगोरियन कैलेन्डर वर्ग को लागू करते समय सूर्य ने उठाया था - नाम के बावजूद, ग्रेगोरियन कैलेन्डर एक संकर कैलेंडर है।)
संयोग से, विंडोज अब नहीं जानता कि पिछले वर्षों के मार्च / अप्रैल या अक्टूबर / नवंबर में कुछ तिथियों के लिए यूटीसी को अमेरिकी स्थानीय समय में सही ढंग से कैसे बदलना है। उन तारीखों से यूटीसी-आधारित टाइमस्टैम्प अब कुछ हद तक निरर्थक हैं। ओएस के लिए यह बहुत ही icky होगा कि अमेरिकी सरकार के डीएसटी नियमों के नवीनतम सेट से पहले किसी भी टाइमस्टैम्प को संभालने से मना कर दिया जाए, इसलिए यह केवल उनमें से कुछ को गलत तरीके से संभालता है। SQL सर्वर 1753 से पहले की तारीखों को संसाधित करने से इंकार कर देता है क्योंकि बहुत सारे अतिरिक्त विशेष तर्क उन्हें सही ढंग से संभालने के लिए आवश्यक होंगे और यह उन्हें गलत तरीके से संभालना नहीं चाहता है।