समय क्षेत्र कैलकुलेटर

गंतव्य का समय = स्रोत का समय − स्रोत का UTC ऑफ़सेट + गंतव्य का UTC ऑफ़सेट; स्रोत से फ़र्क़ = गंतव्य का ऑफ़सेट − स्रोत का ऑफ़सेट; दिन का बदलाव = गंतव्य की तारीख़ − स्रोत की तारीख़

तारीख़

स्रोत वाले क्षेत्र की कैलेंडर तारीख़, YYYY-MM-DD के रूप में। यह वहाँ की तारीख़ है, वह नहीं जहाँ आप इसे पढ़ रहे हैं

समय

स्रोत वाले क्षेत्र की घड़ी का समय, 24 घंटे के रूप में HH:MM या HH:MM:SS। सेकंड छोड़े जा सकते हैं, पर नतीजे में वे हमेशा दिखाए जाते हैं

किस समय क्षेत्र से

वह क्षेत्र जिसका यह समय है। 22 क्षेत्रों में से एक, और हर एक के साथ उसका ऑफ़सेट नहीं बल्कि शहर का नाम लिखा है, क्योंकि ऑफ़सेट उस पल का गुण है, जगह का नहीं — वही शहर जनवरी और जुलाई में अलग-अलग ऑफ़सेट पर हो सकता है

किस समय क्षेत्र में

जिस क्षेत्र में बदलना है। वही 22 क्षेत्र जो स्रोत की सूची में हैं, इसलिए दोनों तरफ़ का कोई भी जोड़ा बनाया जा सकता है

गंतव्य का समय

गंतव्य क्षेत्र की घड़ी का समय, हमेशा सेकंड के साथ। यही इस पेज का मुख्य नतीजा है

गंतव्य की तारीख़

गंतव्य क्षेत्र की कैलेंडर तारीख़, जो हमेशा वही नहीं होती जो आपने डाली — दिन के बदलाव का पूरा सवाल यही है

गंतव्य का दिन

गंतव्य की तारीख़ पर पड़ने वाला दिन, और पैनल इसे नाम से छापता है — रविवार, सोमवार, मंगलवार, बुधवार, गुरुवार, शुक्रवार या शनिवार

स्रोत का UTC ऑफ़सेट

जिस क्षण पर समय टिका, उस पर स्रोत क्षेत्र UTC से कितना दूर है, UTC±HH:MM के रूप में। यह इस क्षेत्र का स्थायी ऑफ़सेट नहीं, उस पल का ऑफ़सेट है

गंतव्य का UTC ऑफ़सेट

उसी क्षण पर गंतव्य क्षेत्र UTC से कितना दूर है। दोनों ऑफ़सेट बदले गए पल पर पढ़े जाते हैं, इसलिए दोनों में डेलाइट समय जुड़ा हुआ आता है अगर वहाँ लागू हो

स्रोत से फ़र्क़

गंतव्य का ऑफ़सेट घटा स्रोत का ऑफ़सेट, घंटों में — यानी दो जगहों के बीच का समय अंतर। ऋणात्मक का मतलब है कि गंतव्य स्रोत से पीछे है

दिन का बदलाव

-1, 0 या +1: क्या गंतव्य की तारीख़ आपकी डाली तारीख़ से एक दिन पहले है, वही दिन है, या एक दिन बाद

इसका इस्तेमाल तब कीजिए जब दो जगहें शामिल हों और किसी घड़ी पर भरोसा करना हो: समुद्र पार कोई कॉल तय करते वक़्त, यह देखते वक़्त कि उड़ान उसी दिन उतरेगी जिस दिन उड़ी थी, UTC में लिखा कोई सर्वर लॉग पढ़ते वक़्त, या यह समझते वक़्त कि किसी मित्र की «रविवार की सुबह» आपकी रविवार की शाम क्यों बन जाती है। दिन का बदलाव वह हिस्सा है जिसमें हाथ से हिसाब लगाने पर ग़लती घुसती है, क्योंकि यह दो शहरों का स्थायी गुण नहीं है — वही दो क्षेत्र जनवरी में 12 घंटे के फ़र्क़ पर होते हैं और जुलाई में 11 के। ध्यान रहे कि यह पेज उस पल को बदलता है जो आपके पास पहले से है; यह नहीं बताता कि कोई जगह किस क्षेत्र में पड़ती है (सूचियाँ 22 क्षेत्रों पर तय हैं), और यात्रा के समय, उड़ान की अवधि या अपॉइंटमेंट की याददिहानी से इसका कोई वास्ता नहीं।

1. शंघाई की दोपहर से न्यूयॉर्क — पिछला दिन

   1. जनवरी में शंघाई UTC+08:00 पर चलता है, इसलिए वहाँ की दोपहर 12:00 बजे 15 जनवरी को 04:00 UTC होती है
   2. न्यूयॉर्क EST पर है, यानी UTC-05:00, इसलिए 04:00 UTC वहाँ की घड़ी पर 23:00 पढ़ता है
   3. 23:00 आधी रात से पहले पड़ता है, जिससे तारीख़ 14 जनवरी बनती है — डाली गई तारीख़ से एक दिन पहले, और दिन का बदलाव यही -1 बताता है
   4. 14 जनवरी 2026 बुधवार है, इसलिए गंतव्य का दिन बुधवार छपता है
   5. दोनों ऑफ़सेट में फ़र्क़ -13.00 घंटे है: 08:00 से (-05:00) घटाने पर 13 घंटे बनते हैं, और इन दोनों में ज़्यादा पश्चिम गंतव्य है

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

2. ऐसा समय जो मौजूद ही नहीं: न्यूयॉर्क, 8 मार्च 2026, 02:30

   1. इस तारीख़ को न्यूयॉर्क में घड़ियाँ स्थानीय समय 02:00 पर आगे बढ़ा दी जाती हैं, यानी 02:00 सीधे 03:00 बन जाता है और 02:00 से 03:00 तक का आधा घंटा कभी आता ही नहीं
   2. इसलिए डाला गया 02:30 मौजूद नहीं है। पेज इसे उसी तरह पढ़ता है जैसा खाली जगह के लिए नियम कहते हैं: आगे सरका दिया जाता है, जिससे 03:30 EDT बनता है
   3. 8 मार्च 2026 को 03:30 रविवार है, इसलिए गंतव्य का दिन रविवार छपता है
   4. चूँकि जो क्षण निकला वह पहले से EDT में है, स्रोत का जो ऑफ़सेट छपता है वह UTC-04:00 है — वह UTC-05:00 नहीं जो 02:30 के साथ एक दिन पहले चलता था
   5. शंघाई UTC+08:00 पर है, यानी EDT से बारह घंटे आगे, इसलिए 03:30 उसी दिन 15:30 बन जाता है

   डाले गए समय के बग़ल छपा ऑफ़सेट तब तक ग़लत लगता है जब तक उसकी वजह सामने न आए: न्यूयॉर्क में 02:30 सर्दियों में UTC-05:00 की घड़ी का समय होता है, पर यह ख़ास 02:30 बदलाव के बाद वाली खाली जगह में पड़ता है, इसलिए जिस क्षण पर यह टिकता है वह EDT का है और UTC-04:00 बताता है। पेज खाली जगहों और दोहराए गए समयों को उसी तरह पढ़ता है जैसा समय क्षेत्र डेटाबेस तय करता है, और इनपुट कभी ठुकराता नहीं — यानी नतीजा हमेशा बनता है, और यह वह मामला है जिसे दो बार पढ़ना बनता है।

3. दोनों सिरे डेलाइट समय पर: 4 जुलाई को लंदन से लॉस एंजिलिस

   1. जुलाई में लंदन BST पर चलता है, UTC+01:00, इसलिए वहाँ के 09:30 यानी 08:30 UTC
   2. लॉस एंजिलिस PDT पर है, UTC-07:00, इसलिए 08:30 UTC वहाँ की घड़ी पर 01:30 है
   3. ऑफ़सेट में फ़र्क़ 8 घंटे है — वे 8 घंटे नहीं जिनकी लोग सर्दियों में उम्मीद करते हैं, बल्कि दो अलग आठ: जनवरी में लंदन UTC+00:00 पर होता है और लॉस एंजिलिस UTC-08:00 पर
   4. दोनों छपे ऑफ़सेट में उनका डेलाइट समय जुड़ा हुआ है, इसीलिए स्रोत UTC+00:00 की जगह UTC+01:00 पढ़ता है
   5. तारीख़ नहीं बदली, इसलिए दिन का बदलाव 0 है — और 4 जुलाई 2026 शनिवार है

   मानक ऑफ़सेट (0 और -08:00) से हिसाब लगाने पर भी वही 8 घंटे का फ़र्क़ और वही घड़ी का समय आता है, और ठीक इसीलिए यहाँ ग़लती पकड़ में नहीं आती — वह बदलाव के आसपास की तारीख़ों पर दिखती है। मार्च के एक ही हफ़्ते में दोनों क्षेत्र उलटी दिशाओं में बदलते हैं, और तभी तय ऑफ़सेट वाला नियम पूरे एक घंटे की ग़लती करता है।

4. ऑकलैंड में नया साल, UTC में अब भी पिछला साल

   1. जनवरी में ऑकलैंड NZDT पर है, UTC+13:00, इसलिए वहाँ की आधी रात 31 दिसंबर 2025 को 11:00 UTC होती है
   2. इसलिए UTC में बदलने पर एक साथ दिन की सीमा और साल की सीमा, दोनों पार होती हैं
   3. गंतव्य की तारीख़ 31 दिसंबर 2025 है, और दिन का बदलाव -1 तारीख़ के अक्षर मिलाकर नहीं बल्कि दिन के अंक घटाकर निकाला जाता है
   4. 31 दिसंबर 2025 बुधवार है, इसलिए गंतव्य का दिन बुधवार छपता है
   5. ऑफ़सेट में फ़र्क़ -13.00 घंटे है: गंतव्य यानी UTC, इन दोनों में ज़्यादा पश्चिम वाला है

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

कैलकुलेटर 1970 से 2100 तक और 22 समय क्षेत्रों को कवर करता है, हर उस क्षेत्र को नहीं जिसे IANA डेटाबेस जानता हो। यह सीमा जानबूझकर है: 1970 से पहले वह डेटाबेस दर्ज करता है कि किसी जगह का असल स्थानीय माध्य समय क्या था — शंघाई UTC+08:06 पर था, मोनरोविया ऐसा ऑफ़सेट इस्तेमाल करता था जिसमें सेकंड भी जुड़े थे — और ऐसे जवाब सही होते हुए भी ग़लती जैसे पढ़ते हैं। जो समय दो बार आता है या आता ही नहीं, उसे ठुकराने की जगह उन्हीं नियमों से सुलझाया जाता है (आगे बढ़ने वाली खाली जगह में समय आगे सरका दिया जाता है, पीछे हटने वाले दोहरे समय में दोनों में से पहला लिया जाता है); पेज आपको यह बताता नहीं कि ऐसा हुआ, इसलिए बदलाव के आसपास की तारीख़ें छपे ऑफ़सेट से मिलाकर देख लेना ठीक है। किसी जगह के नाम से कोई क्षेत्र नहीं पहचाना जाता, क्योंकि लिखने की जगह ही नहीं है: दोनों सूचियाँ तय हैं। पेज यह भी नहीं जानता कि आपका अपना फ़ोन या कंप्यूटर किस क्षेत्र में है, यह अवधि या उड़ान के समय का हिसाब नहीं करता, और लीप सेकंड को गिनता नहीं।

दो शहरों के बीच समय अंतर कितना होता है?

दो शहरों का समय अंतर कोई तय संख्या नहीं है, और इस पेज पर जो फ़र्क़ छपता है वह उसी तारीख़ का होता है जो आपने डाली है। दो क्षेत्र जनवरी में 13 घंटे के फ़र्क़ पर हो सकते हैं और जुलाई में 12 के, क्योंकि उनमें से एक डेलाइट सेविंग मानता है और दूसरा नहीं। इसलिए «कोलकाता और लंदन में कितना फ़र्क़ है» का जवाब तारीख़ के साथ ही पूछा जा सकता है, और इसीलिए इस पेज में तारीख़ का बॉक्स सवाल का हिस्सा है, कोई ऐच्छिक जोड़ नहीं।

समय क्षेत्रों के बीच बैठक का समय कैसे निकालें?

बैठक को उसी क्षेत्र में रखिए जिसमें वह सुझाई गई थी, फिर उसे एक-एक करके बाक़ी क्षेत्रों में बदलिए। बैठक का समय तय करते वक़्त आम तौर पर घंटे से ज़्यादा काम का आँकड़ा दिन का बदलाव होता है: लंदन में 09:00 की कॉल टोक्यो में उसी दिन 18:00 है, पर न्यूयॉर्क में 04:00, और यही 04:00 तय करता है कि न्योता ठीक है या नहीं। चूँकि पेज तारीख़ और दिन दोनों बताता है, आप यह भी देख लेते हैं कि कोई सुझाव दूसरी तरफ़ के वीकेंड पर न गिर जाए।

क्या यह डेलाइट सेविंग अपने आप लागू करता है?

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

UTC ऑफ़सेट कभी-कभी वह क्यों नहीं होता जिसकी मुझे उम्मीद थी?

क्योंकि दिखाया गया ऑफ़सेट उस क्षण का है जिस पर इनपुट टिका, उस घड़ी के समय का नहीं जो आपने लिखा। जिस दिन घड़ियाँ आगे बढ़ती हैं, वह छूटा हुआ घंटा मौजूद ही नहीं होता, और उस घंटे में लिखा गया समय उसके ठीक बाद वाले क्षण के रूप में पढ़ा जाता है — इसलिए मार्च के बदलाव वाले दिन न्यूयॉर्क के लिए डाला गया 02:30 UTC-04:00 (EDT) बताता है, वह UTC-05:00 नहीं जो 02:30 के साथ एक दिन पहले चलता था। दोनों पाठ एक ही क्षण के हैं; उनमें से सिर्फ़ एक उस वक़्त लागू ऑफ़सेट है।

यहाँ बुधवार है तो वहाँ कौन-सा दिन होगा?

यह घंटे पर भी निर्भर करता है, सिर्फ़ क्षेत्रों पर नहीं, और इसीलिए यह पेज दोनों माँगता है। तारीख़ रेखा को पूरब की तरफ़ पार करने पर एक दिन मिल जाता है; पश्चिम की तरफ़ काफ़ी घंटे बदलने पर एक दिन खो जाता है। दिन का बदलाव वाला बॉक्स यह सीधे -1, 0 या +1 में बता देता है, और गंतव्य का दिन बताता है कि दूसरी तरफ़ आपके पूछे हुए दिन तक पहुँच चुके हैं या नहीं।

• IANA Time Zone Database — Internet Assigned Numbers Authority
• Theory and pragmatics of the tz code and data — IANA — the source for the 1970-01-01 accuracy window this page states
• Temporal documentation — Time zone handling — TC39 — describes the 'compatible' disambiguation rule this page follows