क्या MySQL ऐतिहासिक तिथि का समर्थन करता है (जैसे 1200)?

Question

मुझे इसके बारे में कोई जानकारी नहीं दिखाई दे रही है। मुझे सबसे पुरानी तारीख कहां मिल सकती है MySQL समर्थन कर सकते हैं?

Answer 1

आपके प्रश्न (वर्ष 1200) पर उपयोग किए जाने वाले विशिष्ट उदाहरण के लिए तकनीकी रूप से काम करेंगे।

सामान्य रूप से, हालांकि, इस उपयोग के लिए टाइमस्टैम्प अव्यवस्थित हैं। सबसे पहले, सीमा सीमा मनमानी है: MySQL में यह 1 जनवरी, 1000 है। यदि आप 12-13 वीं शताब्दी के सामान के साथ काम कर रहे हैं, तो चीजें ठीक हो जाती हैं ... लेकिन अगर किसी पल में आपको कुछ पुराना (10 वीं शताब्दी या इससे पहले) जोड़ना होगा), तिथि बुरी तरह टूट जाएगी, और इस मुद्दे को ठीक करने के लिए आपकी सभी ऐतिहासिक तिथियों को फिर से स्वरूपित करने की आवश्यकता होगी और कुछ और पर्याप्त होगा।

टाइमस्टैम्प को आम तौर पर कच्चे पूर्णांक के रूप में दर्शाया जाता है, जिसमें "टिक अंतराल" और "युग बिंदु" होता है, इसलिए संख्या वास्तव में प्रतिनिधित्व की तारीख (या ऋणात्मक तिथियों के लिए उपाध्यक्ष) के बाद से निकलती हुई टिकों की संख्या है। इसका अर्थ यह है कि, किसी भी निश्चित-पूर्णांक डेटा प्रकार के साथ, प्रतिनिधित्व योग्य मानों का सेट सीमित है। बलिदान के बारे में मुझे पता है कि अधिकांश टाइमस्टैम्प प्रारूप परिशुद्धता के पक्ष में हैं, अधिकांशतः जिन अनुप्रयोगों को समय अंकगणित करने की आवश्यकता होती है उन्हें अक्सर एक सभ्य परिशुद्धता के साथ ऐसा करने की आवश्यकता होती है; जबकि ऐतिहासिक तिथियों के साथ काम करने की आवश्यकता वाले अनुप्रयोगों को गंभीर अंकगणित करने की बहुत कम आवश्यकता होती है।

दूसरे शब्दों में, टाइमस्टैम्प सटीक तिथियों का प्रतिनिधित्व करने के लिए हैं। द्वितीय (या दूसरे का अंश भी) सटीक ऐतिहासिक तिथियों के लिए कोई समझ नहीं आता है: क्या आप मुझे मिलीसेकंड तक बता सकते हैं, जब हेनरी इंग्लैंड के राजा के रूप में 8 वें स्थान पर थे?

MySQL के मामले में, प्रारूप को मूल रूप से "4-अंकों के वर्षों" के रूप में परिभाषित किया गया है, इसलिए कोई भी संबंधित अनुकूलन इस धारणा पर भरोसा कर सकता है कि वर्ष में 4 अंक होंगे, या पूरे स्ट्रिंग में बिल्कुल 10 वर्ण होंगे ("yyyy-mm-dd"), इत्यादि। यह सिर्फ किस्मत का विषय है कि आपके शीर्षक पर जिस तारीख का उल्लेख किया गया है वह अभी भी फिट बैठता है, लेकिन उस पर भरोसा करना अभी भी खतरनाक है: डीबी स्वयं जो स्टोर कर सकता है उसके अलावा, आपको होना चाहिए इसके बारे में पता है कि आपके बाकी सर्वर का ढेर क्या कर सकता है। उदाहरण के लिए, यदि आप अपने डेटाबेस से बातचीत करने के लिए PHP का उपयोग कर रहे हैं, तो ऐतिहासिक तिथियों को संभालने का प्रयास किसी बिंदु या किसी अन्य पर क्रैश होने की संभावना है (32-बिट वातावरण पर, यूनिक्स-शैली टाइमस्टैम्प की सीमा 13 दिसंबर, 1 9 01 के माध्यम से है 1 9 जनवरी, 2038)।

सारांश में: MySQL 4-अंकों के वर्ष के साथ किसी भी तारीख को ठीक से स्टोर करेगा; लेकिन सामान्य रूप से ऐतिहासिक तिथियों के लिए टाइमस्टैम्प का उपयोग करने से लगभग मुद्दों और सिरदर्द को अक्सर ट्रिगर करने की गारंटी दी जाती है। मैं इस तरह के उपयोग के खिलाफ दृढ़ता से सलाह देता हूं।

उम्मीद है कि इससे मदद मिलती है।

---

संपादित करें/इसके अलावा:

यह बहुत insteresting जवाब के लिए धन्यवाद।क्या मुझे ऐतिहासिक तारीख के लिए अपना स्वयं का अहंकार बनाना चाहिए या कोई अन्य डीबी चुनें लेकिन कौन सा? - उपयोगकर्ता 284523

मुझे नहीं लगता कि किसी भी डीबी के पास इस तरह की तिथियों के लिए बहुत अधिक समर्थन है: इसका उपयोग करने वाले अनुप्रयोगों में अक्सर स्ट्रिंग/टेक्स्ट-प्रस्तुति के साथ पर्याप्त होता है। असल में, वर्ष 1 और बाद की तारीखों के लिए, एक पाठपरक प्रतिनिधित्व सही सॉर्टिंग/तुलना भी उत्पन्न करेगा (जब तक तिथि परिमाण के क्रम में प्रतिनिधित्व की जाती है: y, m, d आदेश)। हालांकि, तुलना "तुलनात्मक" तिथियां भी शामिल होंगी (वे अभी भी किसी भी सकारात्मक से पहले की तुलना में तुलना करेंगे, लेकिन दो नकारात्मक तिथियों की तुलना में एक उलट परिणाम मिलेगा)।

यदि आपको केवल वर्ष 1 और बाद की तिथियों की आवश्यकता है, या यदि आपको सॉर्टिंग की आवश्यकता नहीं है, तो आप तारों का उपयोग करके अपना जीवन बहुत आसान बना सकते हैं।

अन्यथा, सबसे अच्छा तरीका किसी प्रकार की संख्या का उपयोग करना है, और अपने "टिक अंतराल" और "युग बिंदु" को परिभाषित करना है। एक अच्छा अंतराल दिन हो सकता है (जब तक आपको वास्तव में और अधिक सटीकता की आवश्यकता न हो, तब भी आप पूर्णांक के बजाय "वास्तविक" (फ़्लोटिंग-पॉइंट) संख्याओं पर भरोसा कर सकते हैं); और एक उचित युग 1 जनवरी, 1 हो सकता है। मुख्य समस्या इन मानों को उनके पाठ प्रतिनिधित्व, और उपाध्यक्ष को बदल देगी। आपको निम्नलिखित विवरणों को ध्यान में रखना होगा:

• लीप वर्षों में एक अतिरिक्त दिन होता है।
• लीप वर्षों के लिए नियम 1582 तक "4 में से कोई भी" था, जब यह जूलियन से ग्रेगोरियन कैलेंडर में बदल गया और "उन लोगों को छोड़कर 4 में से कई बन गया जो 100 के गुणक हैं, जब तक कि वे 400 के गुणक भी न हों।"
• जूलियन कैलेंडर का अंतिम दिन 4 अक्टूबर, 1582 था। अगले दिन ग्रेगोरियन कैलेंडर का पहला दिन 15 अक्टूबर, 1582 था। 10 दिनों को नए कैलेंडर मैच को मौसम के साथ फिर से बनाने के लिए छोड़ दिया गया।
• जैसा कि टिप्पणियों में बताया गया है, ऊपर दिए गए दो नियम देश के अनुसार अलग-अलग हैं: पापल राज्यों और कुछ कैथोलिक देशों ने निर्धारित तारीखों पर नया कैलेंडर अपनाया है, लेकिन कई अन्य देशों ने ऐसा करने में अधिक समय लगाया है (आखिरी बार 1 9 26 में टर्ले होने के कारण) । इसका मतलब है कि 1582 में पापल बैल के बीच की तारीख और 1 9 26 में अंतिम गोद लेने भौगोलिक संदर्भ के बिना संदिग्ध होगा, और प्रक्रिया के लिए और भी जटिल होगा।
• कोई "वर्ष 0" नहीं है: वर्ष 1 से पहले वर्ष 1 वर्ष या वर्ष 1 ईसा पूर्व था।

यह सब काफी विस्तृत पार्सर और formater कार्यों की आवश्यकता है, लेकिन बहुत से मामला-दर-मामला परे breakings वहाँ वास्तव में बहुत ज्यादा जटिलता नहीं है (यह कोड के लिए कठिन है, लेकिन काफी सीधी-सपाट हो जाएगा) । अंतर्निहित प्रतिनिधित्व के रूप में संख्याओं का उपयोग मूल्यों की किसी भी जोड़ी के लिए सही सॉर्टिंग/तुलना सुनिश्चित करता है।

यह जानना, अब यह आपकी पसंद है कि आपकी आवश्यकताओं को बेहतर तरीके से फिट करने के लिए यह आपकी पसंद है।

Answer 2

documentation से

:

DATE के

एक तारीख। समर्थित श्रेणी '1000-01-01' से '9999-12-31' है।

Answer 3

हां। MySQL dates वर्ष 1000 में शुरू होता है।

Answer 4

जो भी इसके लायक है, मैंने पाया कि MySQL DATE फ़ील्ड अभ्यास में < 1000 का समर्थन करता है, हालांकि दस्तावेज़ अन्यथा कहता है। उदा।, मैं 325 दर्ज करने में सक्षम था और यह 0325-00-00 के रूप में स्टोर करता है। एक खोज WHERE table.date < 1000 ने भी सही परिणाम दिए।

लेकिन मुझे < 1000 तिथियों पर भरोसा करने में संकोच नहीं है जब उन्हें आधिकारिक रूप से समर्थित नहीं किया जाता है, साथ ही मुझे कभी-कभी 4 से अधिक अंकों के साथ बीसीई वर्ष की आवश्यकता होती है (उदाहरण के लिए 10000 ईसा पूर्व)। साल, महीने और दिन (जैसा कि ऊपर सुझाया गया है) के लिए अलग आईएनटी फ़ील्ड एकमात्र विकल्प लगता है।

मैं चाहता हूं कि DATE की तारीख (या शायद एक नया हिस्टाडेट प्रकार) ऐतिहासिक तिथियों की पूरी श्रृंखला का समर्थन करे - तीन क्षेत्रों को एक साथ जोड़ना और year, month, day द्वारा क्रमबद्ध करने के बजाय बस तिथि से सॉर्ट करना अच्छा होगा।

Answer 5

उपयोग SMALLINT वर्ष के लिए है, इसलिए साल, 32768 (एडी) महीनों और दिनों के लिए के रूप में करने के लिए -32,768 (BC) से स्वीकार करेंगे का उपयोग TINYINT UNSIGNED

अधिकांश ऐतिहासिक घटनाओं न महीनों और दिनों की है, तो आप कर सकते थे इस तरह क्वेरी:

SELECT events FROM history WHERE year='-4990' 

परिणाम: 'नूह आर्क'

या: SELECT events FROM history WHERE year='570' AND month='4' AND day='20' वापसी: "मुहम्मद pbuh पैदा हुआ था"

आवश्यकताओं के आधार पर, आप भी DATETIME स्तंभ जोड़ सकते हैं और (इस प्रकार कुछ बाइट्स बचत)

Answer 6

यह एक महत्वपूर्ण और दिलचस्प समस्या एक और समाधान है जो है 1000 और ठीक इसके विपरीत पहले यह तारीख के लिए NULL बना सकता है।

मिलीसेकंड परिशुद्धता के साथ संभावित असीमित संख्याओं की संख्या का समर्थन करने के लिए डेटाबेस प्लेटफ़ॉर्म पर भरोसा करने के बजाय, ऑब्जेक्ट उन्मुख प्रोग्रामिंग भाषा कंपाइलर और रनटाइम पर सही ढंग से तारीख और समय अंकगणित करने के लिए भरोसा करें।

जावा वर्चुअल मशीन (जेवीएम) का उपयोग करके ऐसा करना संभव है, जहां मध्यरात्रि के संबंध में मिलीसेकंड में 1 जनवरी, 1 9 70 यूटीसी (एपोक) का समय डेटाबेस में लंबे समय तक आवश्यक मूल्य को जारी रखकर (नकारात्मक मूल्यों सहित), और पुनर्प्राप्ति के बाद घटक परत में आवश्यक रूपांतरण/गणना निष्पादित करना।

उदाहरण के लिए:

Date d = new Date(Long.MIN_VALUE); 
DateFormat df = new SimpleDateFormat("EEE, d MMM yyyy G HH:mm:ss Z"); 
System.out.println(df.format(d)); 

दिखाने चाहिए: सूर्य, 2 दिसंबर 292,269,055 ई.पू. 16:47:04 +0000

यह भी सक्षम बनाता है डेटाबेस संस्करणों और प्लेटफार्मों की स्वतंत्रता के रूप में यह सब तिथि सार और जेवीएम रनटाइम के लिए अंकगणित समय, यानी डेटाबेस संस्करणों और प्लेटफार्मों में परिवर्तनों को फिर से कार्यान्वयन की आवश्यकता होने की संभावना कम होगी।

Answer 7

मुझे एक ही समस्या थी और मैं डीबी में डेट फ़ील्ड पर रिले जारी रखना चाहता था ताकि मुझे ऐतिहासिक मूल्यों के लिए एक दिन तक की सटीकता के साथ तिथि सीमा खोज का उपयोग करने की अनुमति मिल सके। (मेरे डीबी जन्म और रोमन सम्राटों की तारीखों की तारीख भी शामिल है ...)

समाधान एक निरंतर साल (उदाहरण: 3000) जोड़ने के लिए था उन्हें डीबी को जोड़ने और एक ही घटाकर से पहले सभी तिथियों के लिए उपयोगकर्ताओं को क्वेरी परिणाम प्रदर्शित करने से पहले संख्या।

यदि आपके पास डीबी पहले से ही कुछ तिथियों का मूल्य है, तो नए कॉन्स नंबर के साथ बाहर निकलने वाले मूल्य को अपडेट करना याद रखें।