डेट डिफ़: दिन गिनना दिखने से ज़्यादा मुश्किल क्यों है

भारत में "05/03/2024" का मतलब है 5 मार्च — लेकिन अमेरिका में यही स्ट्रिंग 3 मई बन जाती है। यह एक फ़ॉर्मेट का फ़र्क़ ही लीप ईयर और टाइम ज़ोन से कहीं ज़्यादा असली दुनिया में तारीख़ों के हिसाब को ग़लत बनाता है, क्योंकि ग़लत पढ़ी गई तारीख़ भी बिल्कुल सही दिखती है।

DD/MM/YYYY बनाम MM/DD/YYYY

भारत में, ज़्यादातर यूरोप और दुनिया के बाक़ी हिस्सों की तरह, दिन पहले लिखा जाता है: 05/03/2024 यानी 5 मार्च। अमेरिका में महीना पहले आता है — वही स्ट्रिंग वहाँ 3 मई का मतलब रखती है। अगर किसी अमेरिकी API या स्प्रेडशीट से आई तारीख़ को भारतीय क्रम में पढ़ लिया जाए, तो दो तारीख़ों का फ़र्क़ हफ़्तों तक ग़लत निकल सकता है — बिना किसी एरर के।

वह फ़ॉर्मेट जिसमें कोई अस्पष्टता नहीं: ISO 8601

2024-03-05 (साल-महीना-दिन) जैसा लेखन दुनिया में कहीं भी एक जैसा पढ़ा जाता है, इसीलिए ज़्यादातर API, डेटाबेस और लॉग इसी क्रम का इस्तेमाल करते हैं। अगर सिस्टम के बीच तारीख़ भेजते वक़्त फ़ॉर्मेट चुनने की गुंजाइश हो, तो ISO 8601 यह पूरी उलझन हमेशा के लिए ख़त्म कर देता है।

टाइम ज़ोन और दिन की सीमाएँ

अगर तारीख़ों में सिर्फ़ दिन नहीं बल्कि समय भी शामिल है, तो टाइम ज़ोन का फ़र्क़ दिन की गिनती को एक इकाई से बदल सकता है: दिल्ली में रात 11:30 और उसी पल न्यूयॉर्क में दोपहर 1:00 बजे, गिनती किस टाइम ज़ोन में हो रही है इस पर निर्भर करते हुए अलग-अलग कैलेंडर दिनों में आ सकते हैं।

यह किस काम आता है

• किसी डेडलाइन तक या प्रोजेक्ट की शुरुआती तारीख़ से सटीक दिनों की गिनती करना।
• किराए, सब्सक्रिप्शन या वारंटी की अवधि अभी भी वैध है या नहीं, यह जांचना।
• ग़लत फ़ॉर्मेट में पढ़ी गई तारीख़ को रिपोर्ट ख़राब करने से पहले पकड़ना।

"महीनों का फ़र्क़" का कोई एक सही जवाब क्यों नहीं है

31 मार्च में से एक महीना घटाने पर नतीजा अस्पष्ट है — 31 फ़रवरी होती ही नहीं, इसलिए कुछ सिस्टम 28 फ़रवरी तक राउंड कर देते हैं तो कुछ बचे हुए दिन 3 मार्च में जोड़ देते हैं। दोनों तरीक़े तर्कसंगत हैं, पर अलग जवाब देते हैं — यह याद रखना तब काम आता है जब नतीजा किसी और टूल से मेल न खाए।