समय फ़ॉर्मेट के बीच कैसे कनवर्ट करें

समय प्रारूप सिस्टम, API और देशों में भिन्न होते हैं। API प्रतिक्रियाओं में Unix टाइमस्टैम्प, डेटाबेस में ISO 8601, अमेरिका में 12-घंटे की घड़ियाँ, यूरोप में 24-घंटे की घड़ियाँ, उनके बीच रूपांतरण डेवलपर्स और अंतर्राष्ट्रीय डेटा के साथ काम करने वाले किसी भी व्यक्ति की निरंतर आवश्यकता है। प्रत्येक प्रारूप क्यों मौजूद है, कहाँ चमकता है, और कहाँ काटता है यह समझना रूपांतरण को सूक्ष्म बगों के आवर्ती स्रोत के बजाय एक त्वरित प्रतिवर्त बना देता है।

समय प्रारूपों का संक्षिप्त इतिहास

समय का मानकीकरण इंटरनेट से पुराना है। 1884 में अंतर्राष्ट्रीय मध्याह्न सम्मेलन ने ग्रीनविच मीन टाइम और प्रधान मध्याह्न रेखा स्थापित की, जिसने दुनिया को पहली बार एक सामान्य संदर्भ दिया। 24-घंटे की घड़ी इसी कारण से विमानन और सैन्य में फैल गई: यह AM/PM की उस अस्पष्टता को हटा देती है जो आधी रात की बुकिंग को दोपहर की उड़ान बना सकती है।

Unix समय 1971 में मूल Unix कर्नेल के साथ आया, 1 जनवरी 1970 UTC ("एपोक") से सेकंड गिनता है। यह विकल्प व्यावहारिक था: 32-बिट पूर्णांक दशकों को कवर कर सकता था, टाइमस्टैम्प छाँटना संख्याएँ छाँटना था, और अंतराल की गणना घटाव थी। ISO 8601 मानव-पठनीय पक्ष को मानकीकृत करने के लिए 1988 में आया: बिग-एंडियन क्रम में वर्ष-माह-दिन, दिनांक/समय विभाजक के रूप में T, और UTC के लिए Z। RFC 3339 (2002) ISO 8601 का इंटरनेट प्रोटोकॉल के लिए डिज़ाइन किया गया एक अधिक प्रतिबंधात्मक प्रोफ़ाइल है। RFC 2822 (2001) दिन के नाम और ऑफ़सेट के साथ ईमेल-शैली प्रारूप परिभाषित करता है। प्रत्येक प्रारूप एक वास्तविक समस्या हल करता है; कोई भी दूसरे को पूरी तरह से प्रतिस्थापित नहीं करता।

सामान्य समय प्रारूप

छह प्रारूप जंगल में आप जो कुछ भी मिलेंगे उसे लगभग पूरी तरह कवर करते हैं। पहला कॉलम वह नाम है जो आप दस्तावेज़ में देखेंगे; उदाहरण कॉलम दिखाता है कि 7 अप्रैल 2024 UTC के 14:30 कैसे दिखते हैं।

अधिकांश टीमें भंडारण के लिए Unix मिलीसेकंड और पारगमन के लिए ISO 8601 पर स्थिर हो जाती हैं, प्रदर्शन प्रारूप प्रति-लोकेल चुने जाते हैं। विकल्प स्थिरता से कम मायने रखता है: एक प्राथमिक प्रारूप चुनें, उसका दस्तावेजीकरण करें, और किनारों पर बदलें।

त्वरित रूपांतरण संदर्भ

12-घंटे से 24-घंटे

12-घंटे की घड़ी की दो विषमताएँ हैं: 12 AM मध्यरात्रि है (दिन की शुरुआत) और 12 PM दोपहर है। नीचे की तालिका उन मामलों को कवर करती है जो लोगों को उलझाते हैं।

टाइमस्टैम्प से तिथियाँ

एपोक कनवर्टर Unix टाइमस्टैम्प को तुरंत मानव-पठनीय तिथियों में अनुवादित करता है और वापस भी। कनवर्टर सेकंड (10 अंक) और मिलीसेकंड (13 अंक) दोनों प्रारूपों को स्वचालित रूप से पहचानता है, इसलिए आप किसी भी स्रोत से एक मान चिपका सकते हैं बिना इकाई की चिंता किए।

एक उपयोगी समझदारी जाँच: 86400 (एक दिन में सेकंड) से भाग दें फिर 1970 दिन जोड़ें ताकि किसी भी टाइमस्टैम्प को मानसिक रूप से ढूँढ सकें। 1712502600 / 86400 ~ 19820 दिन, जो 1970 के लगभग 54 साल बाद है, इसे 2024 में रखता है। सटीक नहीं पर एक नज़र में 1000-गुना त्रुटियाँ पकड़ने के लिए पर्याप्त।

कोड में रूपांतरण उदाहरण

अधिकांश डेवलपर्स को अंततः कोड में टाइमस्टैम्प परिवर्तित करने की आवश्यकता होती है। मुख्य API छोटे हैं:

• JavaScript, new Date(1712502600 * 1000).toISOString() 2024-04-07T14:30:00.000Z लौटाता है। 1000 से गुणा करना न भूलें क्योंकि JavaScript का Date मिलीसेकंड की अपेक्षा करता है। दूसरी दिशा में: Math.floor(Date.now() / 1000) सेकंड टाइमस्टैम्प देता है।
• Python, datetime.fromtimestamp(1712502600, tz=timezone.utc).isoformat() 2024-04-07T14:30:00+00:00 लौटाता है। utcfromtimestamp() से बचें; यह एक नैव datetime लौटाता है जिसे आपका बाकी कोड गलती से स्थानीय समय मान लेगा।
• Go, time.Unix(1712502600, 0).UTC().Format(time.RFC3339) 2024-04-07T14:30:00Z लौटाता है। Go का time पैकेज असामान्य है पर एक बार संदर्भ लेआउट Mon Jan 2 15:04:05 MST 2006 को आत्मसात कर लें तो सुसंगत है।
• Shell, GNU/Linux पर date -u -d @1712502600 +"%Y-%m-%dT%H:%M:%SZ", या BSD/macOS पर date -u -r 1712502600 +"%Y-%m-%dT%H:%M:%SZ"। फ़्लैग अंतर सबसे अधिक गूगल किए गए क्रॉस-प्लेटफ़ॉर्म जालों में से एक है।
• Rust, chrono::DateTime::<chrono::Utc>::from_timestamp(1712502600, 0).unwrap().to_rfc3339() वही ISO स्ट्रिंग लौटाता है। मानक पुस्तकालय में अब SystemTime है पर chrono अभी भी फ़ॉर्मेटिंग के लिए व्यावहारिक विकल्प है।
• SQL (Postgres), SELECT to_timestamp(1712502600) AT TIME ZONE 'UTC'; एक timestamptz लौटाता है। MySQL FROM_UNIXTIME() का उपयोग करता है; SQLite datetime(1712502600, 'unixepoch') का उपयोग करता है।

जब आपको केवल एक मान का अनुवाद करना हो (डीबगिंग के दौरान ज्यादातर समय यही होता है) तो एक कनवर्टर टूल इन वन-लाइनरों में से किसी से भी तेज़ है।

भंडारण के लिए ISO 8601 क्यों जीतता है

ISO 8601 (और इसका RFC 3339 प्रोफ़ाइल) सादे स्ट्रिंग के रूप में सही ढंग से छँटता है। 2024-04-07T14:30:00Z वर्णक्रम में 2024-04-07T15:00:00Z से पहले आता है, जो 2024-04-08T00:00:00Z से पहले आता है। यह संपत्ति आपको टाइमस्टैम्प को बिना पार्स किए छाँटने, sort | uniq -c के साथ लॉग लाइनें समूहित करने, और साधारण स्ट्रिंग तुलनाओं के साथ रेंज पर तर्क करने देती है।

यह उस तरह से भी असंदिग्ध है जैसा क्षेत्रीय प्रारूप नहीं हैं। 04/07/2024 7 अप्रैल (अमेरिका) या 4 जुलाई (यूरोप का अधिकांश) हो सकता है; 2024-04-07 हर लोकेल में समान है। मशीन-से-मशीन एक्सचेंज के लिए, वह अस्पष्टता का अभाव किसी भी अन्य फ़ॉर्मेटिंग विचार से अधिक मूल्यवान है।

बचने के लिए सामान्य नुकसान

• समय क्षेत्र भूलना, 2026-04-07 14:30 क्षेत्र के बिना अस्पष्ट है। ISO स्ट्रिंग संग्रहीत करते समय हमेशा Z या +00:00 ऑफ़सेट शामिल करें, और कभी भी पाठक के डिफ़ॉल्ट क्षेत्र पर भरोसा न करें।
• सेकंड और मिलीसेकंड मिलाना, 10-अंकीय Unix टाइमस्टैम्प सेकंड में है, 13-अंकीय मिलीसेकंड में। उन्हें मिलाने से 1970 में या दूर भविष्य में तारीखें बनती हैं। माइक्रोसेकंड (16 अंक) और नैनोसेकंड (19 अंक) भी आते जा रहे हैं, इसलिए उनका भी अनुमान लगाएं।
• सर्वर में स्थानीय समय पर निर्भर रहना, यदि आपका सर्वर UTC में है और आपका उपयोगकर्ता टोक्यो में, तो UTC संग्रहीत करें और प्रदर्शन पर परिवर्तित करें। सर्वर को लोकेल का अनुमान लगाने देना लगभग हमेशा बग की ओर ले जाता है जब उपयोगकर्ता यात्रा करते हैं या DST बदलता है।
• स्ट्रिंग गणित से पार्स करना, तिथि स्ट्रिंग को न काटें न जोड़ें। Date.parse(), dateutil.parser, chrono, या अपनी भाषा की मानक पुस्तकालय का उपयोग करें। मैन्युअल पार्सिंग चरम तिथियों, लीप वर्षों और समय क्षेत्र ऑफ़सेट पर टूट जाती है।
• new Date("2024-04-07") पर भरोसा करना, JavaScript केवल-दिनांक स्ट्रिंग्स को UTC मध्यरात्रि के रूप में पार्स करता है, पर बिना क्षेत्र वाले तिथि-समय स्ट्रिंग्स को स्थानीय मध्यरात्रि के रूप में। व्यवहार ब्राउज़र और Node संस्करणों में भिन्न होता है। हमेशा एक स्पष्ट Z या ऑफ़सेट शामिल करें।
• दो अंकीय वर्ष, 04/07/24 कार्यान्वयन के आधार पर 1924, 2024, या 2124 हो सकता है। हर जगह चार अंकीय वर्षों का उपयोग करें।
• डेलाइट सेविंग संक्रमण, स्थानीय घड़ी वसंत में एक घंटा छोड़ती है और शरद में एक दोहराती है। एक नैव शेड्यूलर उन दिनों एक जॉब दो बार चला सकता है या बिल्कुल नहीं। शेड्यूलिंग तर्क के लिए UTC का उपयोग करें और केवल प्रदर्शन के लिए परिवर्तित करें।
• लीप सेकंड, Unix समय प्रभावित सेकंड को स्मियर या दोहराकर इसका नाटक करता है कि वे मौजूद नहीं हैं। "बीते सेकंड" की तुलना करने वाला कोड लीप सेकंड का सम्मान करने वाली दीवार घड़ी से थोड़ी देर के लिए असहमत हो सकता है।
• वर्ष 2038 समस्या, 32-बिट साइन्ड time_t 19 जनवरी 2038 को अतिप्रवाह करता है। अधिकांश आधुनिक सिस्टम 64-बिट समय का उपयोग करते हैं, पर विरासत एम्बेडेड डिवाइस और पुराने डेटाबेस कॉलम अभी भी इससे टकरा सकते हैं। जहाँ भी आप टाइमस्टैम्प संग्रहीत करने के लिए INT4 या int32 देखें, ऑडिट करें।
• लोकेल-निर्भर फ़ॉर्मेटिंग, JavaScript में toLocaleString() और अन्य भाषाओं में समकक्ष फ़ंक्शन अलग-अलग मशीनों पर अलग-अलग आउटपुट देते हैं। मशीन-पठनीय टाइमस्टैम्प के लिए toISOString() या समकक्ष का उपयोग करें; प्रदर्शन के लिए स्पष्ट रूप से प्रारूपित करें।

वैकल्पिक उपकरण और पुस्तकालय

एक कनवर्टर एक बार के मामले को संभालता है; प्रोडक्शन कोड के लिए आप एक पुस्तकालय की ओर जाएंगे।

सही पुस्तकालय आपके स्टैक पर निर्भर करता है; सही अनुशासन हर जगह एक जैसा है: UTC संग्रहीत करें, ISO 8601 प्रसारित करें, केवल प्रदर्शन के लिए प्रारूपित करें, और स्पष्ट क्षेत्र के बिना टाइमस्टैम्प पर कभी भरोसा न करें।

गोपनीयता और कनवर्टर

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