समय सरल लगता है जब तक आप इसे सही ढंग से संभालने वाला सॉफ़्टवेयर लिखने की कोशिश नहीं करते। "दोपहर 3 बजे" के लिए निर्धारित कार्यक्रम टोक्यो, लंदन और न्यूयॉर्क में अलग-अलग अर्थ रखता है। डेलाइट सेविंग टाइम घड़ियों को आगे या पीछे करता है — लेकिन हर जगह नहीं, और एक ही तिथि पर नहीं। एक टाइमस्टैम्प जो आपके स्थानीय वातावरण में सही दिखता है, उत्पादन में टूट जाता है क्योंकि सर्वर अलग ज़ोन में है।
टाइम ज़ोन सॉफ़्टवेयर विकास में सबसे विश्वसनीय रूप से भ्रमित करने वाले विषयों में से एक हैं। यह लेख बताता है कि वे कैसे काम करते हैं, जटिलता कहाँ से आती है, और सबसे सामान्य गलतियों से कैसे बचें।
टाइम ज़ोन क्यों मौजूद हैं
पृथ्वी 24 घंटे में 360 डिग्री घूमती है, जिसका अर्थ है कि आपके देशांतर के आधार पर सूर्य अलग-अलग क्षणों में अपने उच्चतम बिंदु पर होता है। 19वीं सदी से पहले, हर शहर अपनी घड़ियों को स्थानीय सौर समय पर सेट करता था — दोपहर तब होती थी जब सूर्य ऊपर होता था। यह तब तक काम करता रहा जब तक रेलमार्गों ने दूर के शहरों को जोड़ा और ट्रेन शेड्यूल को एक एकल, सुसंगत घड़ी की ज़रूरत हुई।
1884 में, 25 राष्ट्रों के प्रतिनिधि वॉशिंगटन, D.C. में अंतर्राष्ट्रीय मेरिडियन सम्मेलन में मिले और दुनिया को 24 मानक टाइम ज़ोन में विभाजित करने पर सहमत हुए, प्रत्येक ग्रीनविच, इंग्लैंड से गुज़रने वाले प्रधान मध्याह्न रेखा (0 डिग्री देशांतर) से ऑफ़सेट।
व्यवहार में, टाइम ज़ोन सीमाएँ राजनीतिक सीमाओं का पालन करती हैं, साफ़-सुथरी देशांतर रेखाओं का नहीं। चीन पाँच भौगोलिक ज़ोन में फैला है लेकिन एक एकल आधिकारिक समय (UTC+8) का उपयोग करता है। भारत UTC+5:30 उपयोग करता है — आधे घंटे का ऑफ़सेट। नेपाल UTC+5:45 उपयोग करता है। टाइम ज़ोन का वास्तविक मानचित्र अव्यवस्थित है।
UTC बनाम GMT
GMT (ग्रीनविच मीन टाइम) ग्रीनविच के रॉयल ऑब्ज़र्वेटरी में औसत सौर समय है। यह एक सदी से अधिक समय तक दुनिया का समय संदर्भ था।
UTC (Coordinated Universal Time) ने 1972 में GMT को अंतर्राष्ट्रीय मानक के रूप में बदला। UTC खगोलीय अवलोकन के बजाय परमाणु घड़ियों पर आधारित है, जो इसे कहीं अधिक सटीक बनाता है। अधिकांश व्यावहारिक उद्देश्यों के लिए, UTC और GMT एक ही समय दिखाते हैं, लेकिन UTC सही तकनीकी संदर्भ है।
"UTC" क्यों, "CUT" नहीं? यह संक्षिप्त नाम अंग्रेज़ी "Coordinated Universal Time" (CUT) और फ़्रेंच "Temps Universel Coordonné" (TUC) के बीच एक समझौता है। किसी भी पक्ष को अपना पसंदीदा संक्षेप नहीं मिला, इसलिए UTC को भाषा-तटस्थ विकल्प के रूप में चुना गया।
डेलाइट सेविंग टाइम: संगठित अराजकता
लगभग 70 देश डेलाइट सेविंग टाइम (DST) का पालन करते हैं, वसंत में घड़ियों को एक घंटा आगे और शरद ऋतु में पीछे करते हैं। इसका उद्देश्य जागने के घंटों को दिन के उजाले के साथ संरेखित करना है। परिणाम अर्ध-वार्षिक बग का स्रोत है।
प्रमुख जटिलताएँ:
- सार्वभौमिक नहीं। अधिकांश अफ़्रीका, एशिया और दक्षिण अमेरिका DST का पालन नहीं करते। अमेरिका के भीतर, एरिज़ोना और हवाई इससे बाहर हैं।
- अलग-अलग तिथियाँ। EU मार्च और अक्टूबर के अंतिम रविवार को बदलता है। अमेरिका मार्च के दूसरे और नवंबर के पहले रविवार को। वे हर साल कई हफ़्तों तक असमन्वित रहते हैं।
- अस्पष्ट समय। जब घड़ियाँ पीछे होती हैं, 1:00 AM से 2:00 AM का घंटा दो बार होता है। उस दिन "1:30 AM" का टाइमस्टैम्प अस्पष्ट है।
- छोड़ा गया समय। जब घड़ियाँ आगे होती हैं, 2:00 AM से 3:00 AM का घंटा अस्तित्व में नहीं होता। उस दिन 2:30 AM पर निर्धारित मीटिंग कभी नहीं होती।
- राजनीतिक परिवर्तन। सरकारें कम नोटिस पर DST नियम बदल सकती हैं (और बदलती हैं)। रूस ने 2011 में स्थायी DST अपनाया, फिर 2014 में स्थायी मानक समय पर स्विच किया। मोरक्को ने DST नियम कई बार बदले हैं।
ISO 8601: सार्वभौमिक तिथि प्रारूप
अस्पष्टता से बचने के लिए, अंतर्राष्ट्रीय मानक ISO 8601 एक स्पष्ट तिथि और समय प्रारूप परिभाषित करता है:
2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00
Tतिथि को समय से अलग करता है।Zका अर्थ UTC है (सैन्य शब्दावली में "ज़ुलु" टाइम ज़ोन)।+02:00या-05:00UTC ऑफ़सेट है।
यह प्रारूप अस्पष्ट नहीं है, सादे टेक्स्ट के रूप में सॉर्ट करने योग्य है, और तिथि पार्सिंग लाइब्रेरी द्वारा सार्वभौमिक रूप से समझा जाता है। संदेह होने पर, ISO 8601 उपयोग करें।
Unix टाइमस्टैम्प
Unix टाइमस्टैम्प (जिसे एपॉक टाइम या POSIX टाइम भी कहते हैं) 1 जनवरी 1970, 00:00:00 UTC — जिसे Unix एपॉक कहा जाता है — से बीत चुके सेकंड की संख्या है।
| मानव-पठनीय | Unix टाइमस्टैम्प |
|---|---|
| 1970-01-01 00:00:00 UTC | 0 |
| 2000-01-01 00:00:00 UTC | 946684800 |
| 2026-03-29 12:00:00 UTC | 1774987200 |
Unix टाइमस्टैम्प का कोई टाइम ज़ोन नहीं होता — वे हमेशा UTC में होते हैं। यह उन्हें सॉफ़्टवेयर में समय संग्रहीत और तुलना करने के लिए आदर्श बनाता है। आप स्थानीय टाइम ज़ोन में रूपांतरण केवल प्रदर्शन परत पर करते हैं।
वर्ष 2038 की समस्या: जो सिस्टम Unix टाइमस्टैम्प को 32-बिट साइन्ड इंटीजर के रूप में संग्रहीत करते हैं, वे 19 जनवरी 2038 को 03:14:07 UTC पर ओवरफ़्लो होंगे। अधिकतम मान (2,147,483,647) एक ऋणात्मक संख्या में बदल जाता है, जिसे दिसंबर 1901 के रूप में व्याख्या किया जाता है। अधिकांश आधुनिक सिस्टम 64-बिट इंटीजर उपयोग करते हैं, जो अगले 292 अरब वर्षों तक ओवरफ़्लो नहीं होंगे।
IANA टाइम ज़ोन डेटाबेस
सॉफ़्टवेयर को केवल UTC ऑफ़सेट नहीं चाहिए — इसे प्रत्येक क्षेत्र के लिए पूरा इतिहास और भविष्य के नियम जानने की ज़रूरत है, जिसमें DST संक्रमण, राजनीतिक परिवर्तन और ऐतिहासिक विसंगतियाँ शामिल हैं। यह जानकारी IANA टाइम ज़ोन डेटाबेस (जिसे ओल्सन डेटाबेस या tzdata भी कहते हैं) में रहती है।
यह America/New_York, Europe/Paris, Asia/Tokyo जैसे पहचानकर्ताओं का उपयोग करता है। प्रत्येक प्रविष्टि उस स्थान के UTC ऑफ़सेट और DST नियमों का पूरा इतिहास एनकोड करती है।
इसीलिए आपको कभी भी टाइम ज़ोन को निश्चित ऑफ़सेट के रूप में संग्रहीत नहीं करना चाहिए जैसे "+02:00"। ऑफ़सेट आपको UTC से वर्तमान अंतर बताता है लेकिन DST नियमों के बारे में कुछ नहीं कहता। Europe/Paris सर्दियों में UTC+1 और गर्मियों में UTC+2 है। IANA पहचानकर्ता दोनों को कैप्चर करता है।
सॉफ़्टवेयर में सामान्य बग
- टाइम ज़ोन के बिना स्थानीय समय संग्रहीत करना।
2026-03-29 14:30:00जैसा मान बिना यह जाने अर्थहीन है कि यह किस टाइम ज़ोन को संदर्भित करता है। हमेशा UTC संग्रहीत करें या ऑफ़सेट शामिल करें। - मानना कि UTC ऑफ़सेट टाइम ज़ोन के बराबर है। मार्च में UTC+2 जुलाई में UTC+3 हो सकता है (यदि क्षेत्र DST का पालन करता है)। IANA पहचानकर्ता संग्रहीत करें, ऑफ़सेट नहीं।
- शेड्यूलिंग में DST संक्रमण को अनदेखा करना। 2:30 AM पर दैनिक कार्य साल में एक बार छूटेगा और एक बार दो बार चलेगा यदि आप DST नहीं संभाल रहे हैं।
- मानना कि दिन 24 घंटे के होते हैं। DST संक्रमण दिनों में, एक दिन 23 या 25 घंटे का होता है। 86,400 सेकंड जोड़कर "कल उसी समय" की गणना एक घंटे गलत होगी।
- JavaScript
Dateका सहजता से उपयोग करना।new Date("2026-03-29")कुछ इंजनों में UTC और अन्य में स्थानीय समय के रूप में पार्स होता है। हमेशा टाइम ज़ोन के बारे में स्पष्ट रहें।
डेवलपरों के लिए सर्वोत्तम प्रथाएँ
- UTC में समय संग्रहीत करें। उपयोगकर्ता के स्थानीय टाइम ज़ोन में रूपांतरण केवल प्रस्तुति परत पर करें।
- IANA टाइम ज़ोन पहचानकर्ता उपयोग करें (
America/New_York), निश्चित ऑफ़सेट नहीं (-05:00)। - सीरियलाइज़ेशन के लिए ISO 8601 उपयोग करें। यह अस्पष्ट नहीं है और सार्वभौमिक रूप से पार्स करने योग्य है।
- एक परिपक्व तिथि लाइब्रेरी उपयोग करें। JavaScript में,
Intl.DateTimeFormatयाdate-fns-tzजैसी लाइब्रेरी उपयोग करें। Python में,zoneinfo(3.9+) याpytzउपयोग करें। Java में,java.time.ZonedDateTimeउपयोग करें। tzdataअपडेट रखें। सरकारें DST नियम बदलती हैं। आपके ऑपरेटिंग सिस्टम और भाषा रनटाइम को वर्तमान टाइमज़ोन डेटा की आवश्यकता है।- कई टाइम ज़ोन में परीक्षण करें। यह न मानें कि आपका सर्वर और आपके उपयोगकर्ता एक ही ज़ोन साझा करते हैं।
आगे पढ़ें
समय भ्रामक रूप से जटिल है, लेकिन नियम अच्छी तरह प्रलेखित हैं और उपकरण परिपक्व हैं। कुंजी जटिलता का सम्मान करना है बजाय इसे दूर मान लेने के।
- Cron एक्सप्रेशन सरलीकृत — टाइम ज़ोन में कार्य शेड्यूलिंग
- हैश जनरेटर और Regex टेस्टर — ToolK पर और डेवलपर उपकरण
