समय क्षेत्र असल में कैसे काम करते हैं

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

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

यह विचार आया कहाँ से

1880 के दशक से पहले हर क़स्बा अपना समय रखता था, स्थानीय दोपहर से मिलाकर — यानी उस क्षण से जब सूरज सिर के ऊपर के याम्योत्तर को पार करता है। ब्रिस्टल लंदन से दस मिनट पीछे था, और किसी को इससे फ़र्क़ नहीं पड़ता था, क्योंकि कोई चीज़ इतनी तेज़ नहीं चलती थी कि दस मिनट मायने रखते।

रेल ने यह बदल दिया। ऐसी समय-सारणी किस काम की जो कहे कि गाड़ी 10:15 पर छूटेगी, जब 10:15 का मतलब लाइन के दोनों सिरों पर अलग हो? 1840 के दशक तक ब्रिटिश रेल कंपनियों ने अपने पूरे तंत्र पर सीधे-सीधे लंदन का समय थोप दिया था। संयुक्त राज्य अमेरिका ने 1883 में यही किया, जब रेलवे ने अपने ही निर्णय से देश को चार क्षेत्रों में काट डाला। 1884 के अंतरराष्ट्रीय याम्योत्तर सम्मेलन ने ग्रीनविच को प्रधान याम्योत्तर बनाया और दुनिया को नापने के लिए एक साझा संदर्भ दिया।

इस इतिहास की असल बात यह है कि समय क्षेत्र तालमेल की समस्या सुलझाने के लिए गढ़े गए, और उन्हीं संस्थाओं ने गढ़े जिनके सामने वह समस्या थी। वे कभी इसका विवरण नहीं थे कि सूरज कहाँ है।

एक क्षेत्र में असल में होता क्या है

प्रामाणिक अभिलेख IANA समय क्षेत्र डेटाबेस है, जिसे tzdata या ओल्सन डेटाबेस भी कहते हैं। यह एक पाठ फ़ाइल है, साल में कई बार बदलती है, और आप जो भी ऑपरेटिंग सिस्टम, ब्राउज़र या प्रोग्रामिंग भाषा इस्तेमाल करते हैं, वह उसी का कोई संस्करण पढ़ रही है।

हर क्षेत्र के लिए वह दर्ज करती है:

• एक पहचानकर्ता, जैसे America/New_York या Asia/Kathmandu
• उस क्षेत्र के इतिहास के हर दौर में लागू रहा UTC से अंतर
• वह अंतर कब बदलता है, इसके नियम — अगर बदलता हो
• हर दौर के लिए एक संक्षेप, जहाँ मौजूद हो

पहचानकर्ता क्षेत्र/स्थान की रीति पर चलते हैं, और स्थान किसी देश की जगह एक प्रतिनिधि शहर होता है — क्योंकि देश बँटते हैं, जुड़ते हैं और अपनी सीमाओं से स्वतंत्र होकर नियम बदलते हैं। America/Argentina/Buenos_Aires इसलिए है क्योंकि अर्जेंटीना के प्रांत कभी आपस में अलग-अलग समय रखते थे।

ध्यान दीजिए कि क्षेत्र क्या नहीं है: वह कोई अंतर नहीं है। America/New_York “UTC-5” नहीं है। वह एक क्षेत्र है जिसका अंतर साल के एक हिस्से में UTC-5 और बाक़ी में UTC-4 रहता है, जो दूसरे विश्वयुद्ध के दौरान साल भर UTC-5 पर रहा, और जो 1966 से पहले अलग नियमों पर चलता था। “UTC-5” सहेजकर उसे न्यूयॉर्क कहना सॉफ़्टवेयर की सबसे आम समय क्षेत्र चूक है।

नियम बदलते हैं, और धीरे-धीरे नहीं

2016 में तुर्किये ने क़रीब तीन हफ़्ते की सूचना पर डेलाइट सेविंग छोड़ दी और स्थायी रूप से UTC+3 पर टिक गया। 2018 में उत्तर कोरिया ने दक्षिण के साथ फिर से मिलाने के लिए अपनी घड़ियाँ 30 मिनट खिसकाईं। 2022 में ईरान ने डेलाइट सेविंग ख़त्म की; उसी साल मेक्सिको ने देश के अधिकांश हिस्से से हटा दी। मिस्र ने 2014 में हटाकर 2023 में फिर से लागू कर दी।

इनमें से हर बदलाव एक tzdata रिलीज़ था, और हर एक ने उन सभी प्रणालियों को तोड़ा जिनमें अंतर की तालिका कोड में जड़ी थी। इसीलिए इस साइट के हर पन्ने के पीछे का इंजन अंतर यहाँ सहेजी किसी चीज़ से नहीं, बल्कि रनटाइम की tzdata प्रति से पढ़ता है। नया बिल्ड नए नियम उठा लेता है; कुछ भी संपादित करने की ज़रूरत नहीं पड़ती।

अंतर पूरे घंटों में क्यों नहीं होते

दुनिया की लगभग पाँचवीं आबादी ऐसे अंतर पर जीती है जो UTC से पूरे घंटों में नहीं है। भारत UTC+05:30 पर है, जो इतने चौड़े देश के लिए — जो दो क्षेत्रों का हक़दार था — एकल समझौते के रूप में चुना गया। नेपाल UTC+05:45 पर है, और वे पैंतालीस मिनट कुछ हद तक भारतीय समय से स्वतंत्रता जताने के लिए हैं। चैथम द्वीप UTC+12:45 पर हैं। न्यूफ़ाउंडलैंड UTC-03:30 पर।

जो सॉफ़्टवेयर मान लेता है कि अंतर पूरे घंटों में होते हैं, वह केवल गोल नहीं करता — वह करोड़ों लोगों के लिए 30 या 45 मिनट ग़लत जवाब देता है, और यही वह आकार की चूक है जो कॉल के दौरान पकड़ में आती है, उससे पहले नहीं।

साल के वे दो दिन जब स्थानीय समय कोई फलन नहीं होता

डेलाइट सेविंग साल में दो विच्छेद पैदा करती है, और यही वजह है कि “इस स्थानीय समय को बदलिए” दिखने से कहीं मुश्किल काम है।

घड़ी आगे करना एक घंटा मिटा देता है। न्यूयॉर्क में बदलाव के दिन 01:59:59 के तुरंत बाद 03:00:00 आ जाता है। स्थानीय समय 02:30 होता ही नहीं। कोई उसे लिख दे, तो लौटाने लायक़ कोई सही क्षण है ही नहीं — सिर्फ़ यह नीति है कि उसकी जगह क्या लौटाया जाए।

घड़ी पीछे करना एक घंटा दोहरा देता है। 01:30 दो बार आता है, एक बार डेलाइट समय में और एक घंटे बाद मानक समय में। अकेला स्थानीय समय सचमुच दो अर्थ रखता है; जानना पड़ेगा कि कौन-सा वाला अभिप्रेत था, और लगभग कोई इंटरफ़ेस यह पूछता नहीं।

इस साइट का हर औज़ार दोनों को स्पष्ट रूप से सुलझाता है और बताता है कि उसने क्या किया। चुपचाप एक चुन लेना ही वह तरीक़ा है जिससे कैलेंडर की कोई प्रविष्टि एक घंटा खिसक जाती है और कॉल तक किसी को पता नहीं चलता।

व्यवहार में इसका क्या मतलब है

इस कार्यविधि से तीन नियम निकलते हैं, और जो कुछ ग़लत होता है उसका अधिकांश वे ढक लेते हैं:

1. क्षण सहेजिए, स्थानीय समय नहीं। UTC टाइमस्टैम्प अस्पष्ट नहीं होता। स्थानीय समय का मतलब है टाइमस्टैम्प, साथ में क्षेत्र, और साथ में उन दो झंझट वाले दिनों की नीति।
2. क्षेत्र का पहचानकर्ता सहेजिए, अंतर नहीं। Europe/London नियम बदलने पर भी टिका रहता है; UTC+0 नहीं, और वह वैसे भी आधे साल ग़लत रहता है।
3. दिखाते समय बदलिए, रनटाइम की tzdata से। सहेजते समय नहीं, और अपनी बनाई किसी तालिका से तो कभी नहीं।

यह साइट अंतरों के साथ बार-बार “पिछले बिल्ड के अनुसार” क्यों लिखती है, और वर्तमान समय आपके ब्राउज़र में क्यों निकालती है — कारण यही है। ये नियम हमारे नहीं हैं कि हम इन्हें जमा दें।