Architecture Decision Recordटाइमस्टैम्प प्रारूप
विषय-सूची:
सारांश
मुद्दा
हम टाइमस्टैम्प का उपयोग करके, और एक संगत टाइमस्टैम्प प्रारूप का उपयोग करके, जो हमारी सभी प्रणालियों और तृतीय-पक्ष प्रणालियों में अच्छी तरह काम करे, यह ट्रैक करने में सक्षम होना चाहते हैं कि चीज़ें कब घटित होती हैं।
हम ऐसी प्रणालियों के साथ संवाद करते हैं जिनके टाइमस्टैम्प प्रारूप अलग-अलग हैं:
JSON संदेशों में कोई मूल टाइमस्टैम्प प्रारूप नहीं होता, इसलिए हमें चुनना होगा कि टाइमस्टैम्प को स्ट्रिंग में कैसे बदलें और स्ट्रिंग को टाइमस्टैम्प में कैसे बदलें, यानी सीरियलाइज़/डीसीरियलाइज़ कैसे करें।
कुछ एप्लिकेशन UTC समय के बजाय स्थानीय समय का उपयोग करने के लिए सेट होते हैं। यह उन परियोजनाओं के लिए सुविधाजनक हो सकता है जिन्हें स्थानीय समय के अनुसार ढलना होता है, जैसे वे परियोजनाएँ जो स्थानीय समय पर आधारित घटनाएँ ट्रिगर करती हैं।
कुछ प्रणालियों की समय सटीकता की आवश्यकताएँ और क्षमताएँ अलग होती हैं, जैसे सेकंड बनाम मिलीसेकंड बनाम नैनोसेकंड का समय रिज़ॉल्यूशन। उदाहरण के लिए, Linux ऑपरेटिंग सिस्टम का
dateकमांड डिफ़ॉल्ट रूप से सेकंड की समय सटीकता का उपयोग करता है, जबकि Nasdaq स्टॉक एक्सचेंज डिफ़ॉल्ट रूप से नैनोसेकंड की सटीकता चाहता है।
निर्णय
हम नैनोसेकंड सटीकता वाले टाइमस्टैम्प मानक प्रारूप ISO 8601 को चुनते हैं, विशेष रूप से "YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ"।
यह प्रारूप वर्ष, माह, दिन, घंटा, मिनट, सेकंड, नैनोसेकंड और Zulu समय क्षेत्र, यानी UTC, GMT दिखाता है।
अवस्था
तय।
विवरण
मान्यताएँ
हमें इन टाइमस्टैम्प टेक्स्ट स्ट्रिंग को संभालना होगा, यानी टाइमस्टैम्प को स्ट्रिंग में बदलना (सीरियलाइज़ करना) और स्ट्रिंग को टाइमस्टैम्प में बदलना (डीसीरियलाइज़ करना)।
हम ऐसा प्रारूप चाहते हैं जिसका उपयोग सामान्यतः आसान हो, जिसे बदलना आसान हो, और जिसे व्यक्ति के लिए पढ़ना आसान हो।
हम बड़ी संख्या में उन बाहरी प्रणालियों के साथ अनुकूलता चाहते हैं जिन्हें हम नियंत्रित नहीं कर सकते, जैसे एनालिटिक्स प्रणालियाँ, डेटाबेस प्रणालियाँ, वित्तीय प्रणालियाँ।
बाधाएँ
कुछ प्रणालियों में समय सटीकता की सीमाएँ होती हैं। उदाहरण के लिए, macOS ऑपरेटिंग सिस्टम का date कमांड समय सटीकता सेकंड में प्रिंट कर सकता है, लेकिन नैनोसेकंड में नहीं।
रुख
हमने कई विकल्पों पर विचार किया:
Unix epoch यानी एक बढ़ती संख्या।
संक्षिप्त टेक्स्ट प्रारूप "YYYYMMDDTHHMMSSNNNNNNNNN"।
स्थानीय समय क्षेत्र बनाम UTC समय क्षेत्र का उपयोग।
तर्क
सामान्य उपयोग के लिए, हम कच्ची गति/आकार की तुलना में मनुष्यों द्वारा पढ़ने/लिखने में आसानी को अधिक महत्व देते हैं।
सामान्य उपयोग के लिए, हम ऐसा प्रारूप चाहते हैं जो मशीनी प्रणालियों में ठीक से काम करे, और मैन्युअल रूप से भी अच्छी तरह काम करे, जैसे नमूना डेटा लिखना, JSON आउटपुट पढ़ना, लॉग फ़ाइल को grep करना आदि।
असामान्य उपयोग, जैसे उच्च-प्रदर्शन कंप्यूटिंग, के लिए हम अपेक्षा करते हैं कि हम जो भी टेक्स्ट प्रारूप चुनेंगे उसे टेक्स्ट को तेज़ प्रारूप में बदलकर अनुकूलित करना चाहेंगे, जैसे प्रोग्रामिंग भाषा का अंतर्निहित दिनांक ऑब्जेक्ट प्रकार। इसलिए HPC के लिए टेक्स्ट प्रारूप ज़्यादा मायने नहीं रखता।
निहितार्थ
हमारी विभिन्न टेक्स्ट प्रणालियाँ और समय प्रणालियाँ इस प्रारूप पर अभिसरित होंगी।
संबंधित
संबंधित निर्णय
हम समय के अंतर यानी अवधि को ट्रैक करने का तेज़/आसान तरीका भी चाह सकते हैं। Unix epoch टाइमस्टैम्प के साथ यह आसान है।
संबंधित आवश्यकताएँ
यदि हमारे पास किसी विशिष्ट प्रकार के लॉगिंग संदेश स्टैम्प की संबंधित आवश्यकता हो, जैसे Splunk, Sumo, ELK आदि के लिए, तो हम अपना निर्णय समायोजित करना चाह सकते हैं।
संबंधित कलाकृतियाँ
भाषा फ़ॉर्मैटर और पार्सर:
Rosetta Code के उदाहरण:
SixArm के उदाहरण:
संबंधित सिद्धांत
आसानी से पलटा जा सकने वाला। हम आसानी से किसी अन्य प्रारूप में बदल सकते हैं, जैसे Unix epoch।
समय से पहले अनुकूलन टालें। सामान्य उपयोग के लिए हमें कुछ अतिरिक्त अक्षरों, जैसे डैश और कोलन वाले प्रारूप, की ज़्यादा चिंता नहीं है।
टिप्पणियाँ
यहाँ टिप्पणियाँ जोड़ें।