ISO 8601, और तारीख़ को बिना दुविधा कैसे लिखें

03/04/2026 दुनिया के अधिकांश हिस्से में 3 अप्रैल है और संयुक्त राज्य अमेरिका में 4 मार्च। सिर्फ़ इस पंक्ति से यह जानने का कोई रास्ता नहीं कि क्या अभिप्रेत था, और दोनों पाठ पूरी तरह वाजिब हैं। हर साल यह दुविधा चूकी हुई समय-सीमाएँ, दोहरी बुकिंग और कम से कम एक यादगार सेवा-भंग पैदा करती है।

ISO 8601 वह अंतरराष्ट्रीय मानक है जो इसे मिटा देता है।

बुनियादी प्रारूप

2026-04-03T14:30:00Z

बाएँ से दाएँ पढ़िए, सबसे बड़ी इकाई से सबसे छोटी तक:

• 2026-04-03 — वर्ष, माह, दिन; हर एक शून्य से भरा हुआ, और हमेशा इसी क्रम में
• T — तारीख़ और समय के बीच का विभाजक, कठोर रूप में अनिवार्य
• 14:30:00 — 24 घंटे की घड़ी पर घंटे, मिनट, सेकंड
• Z — क्षेत्र का संकेतक। Z का मतलब ठीक UTC

बात क्रम की ही है। चूँकि घटक सबसे महत्वपूर्ण से कम महत्वपूर्ण की ओर चलते हैं, इसलिए ISO 8601 की पंक्ति सादे पाठ की तरह सही क्रम में लगती है। साधारण पंक्ति-तुलना में 2026-04-03, 2026-04-10 से पहले आता है — यह और कोई प्रचलित प्रारूप नहीं कर पाता। अकेला यही गुण इस मानक को सही ठहरा देता है।

क्षेत्र संकेतक

तीन रूप मान्य हैं, और उनके मतलब अलग हैं:

रूप	अर्थ
2026-04-03T14:30:00Z	14:30 UTC। निर्विवाद
2026-04-03T14:30:00+05:45	UTC से 5 घं 45 मि आगे वाले क्षेत्र में स्थानीय समय 14:30। निर्विवाद
2026-04-03T14:30:00	किसी अनिर्दिष्ट क्षेत्र में 14:30। यह टाइमस्टैम्प नहीं है

मुसीबत तीसरा रूप खड़ी करता है। वह एक स्थानीय तिथि-समय है — दीवार-घड़ी का पाठ, जिसे समय-रेखा पर रखने का कोई तरीक़ा नहीं। उसे किसी सिस्टम की सीमा के पार भेजकर यह उम्मीद करना कि दूसरी तरफ़ वही क्षेत्र मान लिया जाएगा जो आपने माना था — यह वह दोष है जो किसी दूसरे क्षेत्र में तैनाती का इंतज़ार कर रहा है।

यह भी ध्यान दीजिए कि अंतर क्या नहीं है: +05:45 आपको नेपाल का अंतर बताता है, यह नहीं कि टाइमस्टैम्प नेपाल का है। अंतर क्षेत्र नहीं होते — एक ही अंतर कई क्षेत्रों में साझा होता है, और किसी क्षेत्र का अंतर बदलता रहता है। अगर यह जानना ज़रूरी हो कि कहाँ, तो पहचानकर्ता साथ रखिए।

RFC 3339, वह प्रोफ़ाइल जो शायद आपको चाहिए

ISO 8601 बड़ा है। वह सप्ताह-तिथियाँ (2026-W14-5), क्रमिक तिथियाँ (2026-093), भिन्नात्मक इकाइयाँ और शताब्दी छोड़ने वाला छोटा रूप — सब की छूट देता है। इनमें से अधिकांश वह नहीं है जो आपको किसी इंटरफ़ेस में चाहिए।

RFC 3339 इंटरनेट प्रोटोकॉलों के लिए कसा हुआ प्रोफ़ाइल है। यह पूरी तारीख़ माँगता है, क्षेत्र संकेतक माँगता है, और विभाजक के रूप में T या एक जगह — दोनों की छूट देता है। जब कोई API के संदर्भ में “ISO प्रारूप” कहता है, तो लगभग हमेशा RFC 3339 ही अभिप्रेत होता है।

एक उपयोगी नियम: वह सब स्वीकारिए जो कोई अच्छा पार्सर पचा ले; निकालिए केवल कठोर RFC 3339, Z के साथ।

अवधियाँ और अंतराल

कम बरते जाते हैं, और जब सामने आएँ तो जान लेना अच्छा है।

अवधियाँ «period» के P से शुरू होती हैं, और T तारीख़ वाले हिस्सों को समय वाले हिस्सों से अलग करता है:

• P3Y6M4D — तीन वर्ष, छह माह, चार दिन
• PT1H30M — एक घंटा तीस मिनट
• P1DT12H — एक दिन बारह घंटे

T वैकल्पिक नहीं है: P1M एक माह है, PT1M एक मिनट। ISO 8601 की अवधियों वाली यही क्लासिक चूक है।

अंतराल दो बिंदुओं को तिरछी रेखा से जोड़ते हैं: 2026-04-03T14:00Z/2026-04-03T16:00Z, या एक बिंदु और एक अवधि: 2026-04-03T14:00Z/PT2H।

इस साइट का HowTo संरचित डेटा अवधि-वाक्यरचना बरतता है — दो मिनट के काम के लिए PT2M — क्योंकि schema.org ISO 8601 की अवधियाँ निर्दिष्ट करता है।

सप्ताह-तिथियाँ, और उनमें छिपा जाल

2026-W14-5 यानी 2026 के चौदहवें ISO सप्ताह का शुक्रवार। ISO सप्ताह सोमवार से शुरू होते हैं, और सप्ताह 1 वह है जिसमें जनवरी का पहला गुरुवार पड़ता है।

जिस नतीजे पर लोग ठोकर खाते हैं: ISO सप्ताह-वर्ष हमेशा कैलेंडर वर्ष नहीं होता। 1 जनवरी 2027 ISO के हिसाब से 2026 के 53वें सप्ताह में पड़ता है। जो फ़ॉर्मैटिंग कोड ISO सप्ताह-संख्या को कैलेंडर वर्ष से जोड़ता है, वह हर साल कुछ दिनों के लिए ग़लत तारीख़ बनाता है — और अधिकांश भाषाओं में फ़ॉर्मैट-चिह्न लगभग एक जैसे दिखते हैं (YYYY बनाम GGGG, या %Y बनाम %G)।

व्यावहारिक नियम

1. UTC में सहेजिए, Z के साथ निकालिए। 2026-04-03T14:30:00Z का हर जगह ठीक एक ही मतलब है।
2. किसी सीमा के पार कभी नंगी स्थानीय तिथि-समय मत भेजिए। अगर क्षेत्र जोड़ नहीं सकते, तो आपके पास टाइमस्टैम्प है ही नहीं।
3. सब कुछ शून्य से भरिए। 2026-4-3 मान्य ISO 8601 नहीं है, भले ही अधिकांश पार्सर इसे स्वीकार लें।
4. - और : विभाजक बरतिए। सघन रूप (20260403T143000Z) क़ानूनी तो है पर रूखा है, और कुछ पार्सर उसे ठुकरा देते हैं।
5. क्षेत्र पहचानकर्ता अलग रखिए जब यह जानना हो कि कहाँ, केवल कौन-सा अंतर नहीं। Europe/London नियम बदलने पर भी टिकता है; +01:00 नहीं।

पार्सिंग के जाल

मानक होते हुए भी, गड़बड़ी पार्सिंग में ही होती है।

जावास्क्रिप्ट का Date कंस्ट्रक्टर ग़ैर-ISO इनपुट पर असंगत है। new Date('2026-04-03') UTC की आधी रात मानी जाती है। new Date('2026-04-03T00:00:00') — बिना क्षेत्र संकेतक — स्थानीय आधी रात मानी जाती है। दोनों में आपके अपने अंतर जितना फ़र्क़ है, यानी वही कोड इस पर निर्भर करके अलग-अलग दिन देता है कि वह कहाँ चल रहा है। हमेशा क्षेत्र संकेतक लगाइए।

दो अंकों वाले वर्ष दुविधाजनक हैं और ठुकराए जाने चाहिए। ISO 8601 छोटा रूप मानता है; लगभग किसी को उसे स्वीकारना नहीं चाहिए। 26-04-03 1926 भी हो सकता है और 2026 भी, और जो सरकती खिड़की इसका फ़ैसला करती है वह पार्सर के भीतर छिपा एक नीतिगत निर्णय है।

सेकंड के अंश अलग-अलग परिशुद्धता के होते हैं। 14:30:00.5, 14:30:00.500 और 14:30:00.500000 — तीनों मान्य हैं और तीनों एक ही क्षण। जो पार्सर क्षणों के बजाय पंक्तियाँ तुलता है, वह असहमत होगा।

अल्पविराम क़ानूनी है। ISO 8601 14:30:00,5 की छूट देता है — दशमलव अल्पविराम — और उसे तरजीह भी देता है। अधिकांश पार्सर उसे ठुकरा देते हैं। अगर आप किसी यूरोपीय प्रणाली से डेटा ले रहे हैं, तो तैयार रहिए।

आधी रात की दो वर्तनियाँ हैं। एक दिन का 24:00:00 वही क्षण है जो अगले दिन का 00:00:00, और दोनों मान्य ISO 8601 हैं। दूसरा रूप निकालिए; दोनों स्वीकारिए।

क्रम के बारे में एक बात

ISO 8601 का क्रम में लगना केवल उन पंक्तियों के लिए टिकता है जिनका क्षेत्र-निरूपण एक जैसा हो। 2026-04-03T14:00:00Z और 2026-04-03T10:00:00-05:00 एक ही क्षण हैं, पर पंक्तियों के रूप में दूसरा पहले लगेगा।

अगर आप टाइमस्टैम्प को पाठ की तरह क्रम में लगा रहे हैं — किसी लॉग फ़ाइल में, किसी फ़ाइल के नाम में, पाठ के रूप में परिभाषित किसी डेटाबेस स्तंभ में — तो पहले सबको Z के साथ UTC में सामान्यीकृत कीजिए। वरना क्रम समय का नहीं, फ़ॉर्मैटिंग का गुण बन जाता है।