विशिष्ट उदाहरण के लिए आपने अपने प्रश्न (वर्ष 1200) पर प्रयोग किया है, तकनीकी रूप से चीजें काम करेंगी।
सामान्य तौर पर, हालांकि, टाइमस्टैम्प इस उपयोग के लिए अनुपयुक्त हैं। सबसे पहले, सीमा सीमा मनमानी है:MySQL में यह 1 जनवरी, 1000 है। यदि आप 12-13 वीं शताब्दी के सामान के साथ काम कर रहे हैं, तो चीजें ठीक हो जाती हैं ... लेकिन अगर किसी पल में आपको कुछ पुराना (10वीं शताब्दी या उससे पहले) जोड़ने की आवश्यकता है, तिथि बुरी तरह टूट जाएगी, और समस्या को ठीक करने के लिए अपनी सभी ऐतिहासिक तिथियों को और अधिक पर्याप्त रूप से पुन:स्वरूपित करने की आवश्यकता होगी।
टाइमस्टैम्प को आम तौर पर दिए गए "टिक अंतराल" और "युग बिंदु" के साथ कच्चे पूर्णांक के रूप में दर्शाया जाता है, इसलिए संख्या वास्तव में युग के बाद से प्रतिनिधित्व तिथि (या नकारात्मक तिथियों के लिए विपरीत) के बाद से बीत चुके टिकों की संख्या है। इसका मतलब यह है कि, किसी भी निश्चित-पूर्णांक डेटा-प्रकार के साथ, प्रतिनिधित्व योग्य मानों का सेट सीमित है। अधिकांश टाइमस्टैम्प प्रारूप जिन्हें मैं सटीकता के पक्ष में बलिदान सीमा के बारे में जानता हूं, ज्यादातर इसलिए कि जिन अनुप्रयोगों को समय अंकगणित करने की आवश्यकता होती है, उन्हें अक्सर एक सभ्य परिशुद्धता के साथ ऐसा करने की आवश्यकता होती है; जबकि ऐतिहासिक तिथियों के साथ काम करने वाले अनुप्रयोगों को शायद ही कभी गंभीर अंकगणित करने की आवश्यकता होती है।
दूसरे शब्दों में, टाइमस्टैम्प सटीक . के लिए हैं तिथियों का प्रतिनिधित्व दूसरा (या सेकंड का अंश भी) सटीक ऐतिहासिक तारीखों के लिए कोई मतलब नहीं है:क्या आप मुझे बता सकते हैं, मिलीसेकंड तक, इंग्लैंड के राजा के रूप में 8 वें हेनरी को कब ताज पहनाया गया था?
MySQL के मामले में, प्रारूप को स्वाभाविक रूप से "4-अंकीय वर्ष" के रूप में परिभाषित किया गया है, इसलिए कोई भी संबंधित अनुकूलन इस धारणा पर भरोसा कर सकता है कि वर्ष में 4 अंक होंगे, या पूरे स्ट्रिंग में ठीक 10 वर्ण होंगे ("yyyy- एमएम-डीडी"), आदि। यह केवल भाग्य की बात है कि आपने अपने शीर्षक पर जिस तारीख का उल्लेख किया है, वह अभी भी फिट बैठता है, लेकिन उस पर भरोसा करना भी खतरनाक है:डीबी स्वयं क्या स्टोर कर सकता है, इसके अलावा, आपको इस बात से अवगत होना चाहिए कि आपका बाकी सर्वर स्टैक हेरफेर कर सकता है। उदाहरण के लिए, यदि आप अपने डेटाबेस के साथ बातचीत करने के लिए PHP का उपयोग कर रहे हैं, तो ऐतिहासिक तिथियों को संभालने का प्रयास किसी बिंदु या किसी अन्य पर क्रैश होने की संभावना है (32-बिट वातावरण पर, यूनिक्स-शैली टाइमस्टैम्प की सीमा 13 दिसंबर, 1 9 01 तक है। 19 जनवरी, 2038)।
संक्षेप में:MySQL किसी भी तारीख को 4-अंकीय वर्ष के साथ ठीक से संग्रहीत करेगा; लेकिन आम तौर पर ऐतिहासिक तिथियों के लिए टाइमस्टैम्प का उपयोग करने से समस्याओं और सिरदर्द को अधिक बार ट्रिगर करने की गारंटी होती है। मैं इस तरह के उपयोग के खिलाफ दृढ़ता से सलाह देता हूं।
आशा है कि यह मदद करता है।
संपादित करें/जोड़ें:
मुझे नहीं लगता कि इस तरह की तिथियों के लिए किसी भी डीबी के पास बहुत अधिक समर्थन है:इसका उपयोग करने वाले अनुप्रयोगों में अक्सर स्ट्रिंग-/टेक्स्ट- प्रतिनिधित्व के साथ पर्याप्त होता है। वास्तव में, वर्ष 1 और उसके बाद की तारीखों के लिए, एक पाठ्य प्रस्तुति से सही छँटाई/तुलना भी होगी (जब तक कि परिमाण के क्रम द्वारा दिनांक का प्रतिनिधित्व किया जाता है:y,m,d क्रम)। तुलना टूट जाएगी, हालांकि, यदि "नकारात्मक" तिथियां भी शामिल हैं (वे अभी भी किसी भी सकारात्मक तिथि से पहले की तुलना करेंगे, लेकिन दो नकारात्मक तिथियों की तुलना करने से उलटा परिणाम मिलेगा)।
यदि आपको केवल वर्ष 1 और बाद की तिथियों की आवश्यकता है, या यदि आपको छँटाई की आवश्यकता नहीं है, तो आप स्ट्रिंग्स का उपयोग करके अपने जीवन को बहुत आसान बना सकते हैं।
अन्यथा, किसी प्रकार की संख्या का उपयोग करना सबसे अच्छा तरीका है, और अपना खुद का "टिक अंतराल" और "युग बिंदु" परिभाषित करें। एक अच्छा अंतराल दिन हो सकता है (जब तक कि आपको वास्तव में और सटीकता की आवश्यकता न हो, लेकिन फिर भी आप पूर्णांकों के बजाय "वास्तविक" (फ़्लोटिंग-पॉइंट) संख्याओं पर भरोसा कर सकते हैं); और एक उचित युग 1 जनवरी हो सकता है। मुख्य समस्या इन मूल्यों को उनके पाठ प्रतिनिधित्व और इसके विपरीत में बदलना होगा। आपको निम्नलिखित विवरणों को ध्यान में रखना होगा:
- लीप वर्ष में एक अतिरिक्त दिन होता है।
- लीप वर्ष के लिए नियम 1582 तक "4 का कोई भी गुणज" था, जब यह जूलियन से ग्रेगोरियन कैलेंडर में बदल गया और "4 का गुणक बन गया, सिवाय उन लोगों को छोड़कर जो 100 के गुणक हैं जब तक कि वे 400 के गुणक भी न हों"।
- जूलियन कैलेंडर का अंतिम दिन 4 अक्टूबर, 1582 था। अगले दिन, ग्रेगोरियन कैलेंडर का पहला दिन, 15 अक्टूबर, 1582 था। नए कैलेंडर को सीज़न के साथ फिर से बनाने के लिए 10 दिन छोड़ दिए गए थे।
- जैसा कि टिप्पणियों में कहा गया है, ऊपर दिए गए दो नियम देश के अनुसार अलग-अलग हैं:पोप राज्यों और कुछ कैथोलिक देशों ने बताई गई तारीखों पर नया कैलेंडर अपनाया, लेकिन कई अन्य देशों ने ऐसा करने में अधिक समय लिया (अंतिम रूप से 1926 में तुर्की) . इसका मतलब यह है कि 1582 में पोप बैल और 1926 में अंतिम गोद लेने के बीच कोई भी तारीख भौगोलिक संदर्भ के बिना अस्पष्ट होगी, और प्रक्रिया के लिए और भी जटिल होगी।
- कोई "वर्ष 0" नहीं है:वर्ष 1 से पहले का वर्ष वर्ष -1 या वर्ष 1 ईसा पूर्व था।
इन सभी के लिए काफी विस्तृत पार्सर और फॉर्मेटर फ़ंक्शंस की आवश्यकता होती है, लेकिन कई केस-बाय-केस ब्रेकिंग से परे वास्तव में बहुत अधिक जटिलता नहीं होती है (यह कोड के लिए कठिन होगा, लेकिन काफी सीधा होगा)। अंतर्निहित प्रतिनिधित्व के रूप में संख्याओं का उपयोग मूल्यों की किसी भी जोड़ी के लिए सही सॉर्टिंग/तुलना सुनिश्चित करता है।
यह जानने के बाद, अब यह आपकी पसंद है कि आप वह तरीका अपनाएं जो आपकी आवश्यकताओं के अनुरूप बेहतर हो।
