सबसे पहले, कृपया यह पहचानें कि आधुनिक शब्दावली में आपको GMT के बजाय UTC कहना चाहिए। वे ज्यादातर समकक्ष हैं, सिवाय इसके कि यूटीसी अधिक सटीक रूप से परिभाषित है। यूनाइटेड किंगडम में समय क्षेत्र के उस हिस्से को संदर्भित करने के लिए GMT शब्द आरक्षित करें जो सर्दियों के महीनों के दौरान ऑफसेट UTC+0 के साथ प्रभावी होता है।
अब आपके प्रश्न पर। जरूरी नहीं कि UTC सभी दिनांक और समय मानों को संग्रहीत करने का सबसे अच्छा तरीका हो। यह अतीत . के लिए विशेष रूप से अच्छा काम करता है ईवेंट, या भविष्य के लिए पूर्ण ईवेंट, लेकिन यह भविष्य के लिए इतना बढ़िया काम नहीं करता स्थानीय घटनाएँ - विशेष रूप से भविष्य आवर्ती इवेंट.
मैंने इसके बारे में दूसरे जवाब पर लिखा था हाल ही में, और उन कुछ अपवाद मामलों में से एक है जहां स्थानीय समय यूटीसी की तुलना में अधिक मायने रखता है। मुख्य तर्क "अलार्म घड़ी की समस्या" है। यदि आप अपनी अलार्म घड़ी को UTC द्वारा सेट करते हैं, तो आप DST ट्रांज़िशन के दिन एक घंटे पहले या देर से जागेंगे। यही कारण है कि अधिकांश लोग अपनी अलार्म घड़ियों को स्थानीय समय के अनुसार सेट करते हैं।
बेशक, आप बस नहीं कर सकते यदि आप दुनिया भर के डेटा के साथ काम कर रहे हैं तो स्थानीय समय स्टोर करें। आपको कुछ अलग चीज़ें स्टोर करनी चाहिए:
- आवर्ती घटना का स्थानीय समय, जैसे "08:00"
- वह समय क्षेत्र जिसमें स्थानीय समय व्यक्त किया जाता है, जैसे "अमेरिका/न्यू_यॉर्क"
- पुनरावृत्ति पैटर्न, जो भी प्रारूप आपके आवेदन के लिए समझ में आता है, जैसे दैनिक, द्वि-साप्ताहिक, या महीने का तीसरा गुरुवार, आदि।
- अगला तत्काल UTC दिनांक और समय के बराबर, जितना आप इसे प्रोजेक्ट कर सकते हैं उतना अच्छा है।
- शायद, लेकिन हमेशा नहीं, भविष्य की घटना UTC दिनांक और समय की एक सूची, भविष्य में कुछ पूर्वनिर्धारित अवधि (शायद एक सप्ताह, शायद 6 महीने, शायद एक या दो वर्ष, आपकी आवश्यकताओं के आधार पर) का अनुमान लगाती है।
अंतिम दो के लिए, यह समझें कि किसी भी स्थानीय दिनांक/समय के समतुल्य UTC बदल सकता है यदि उस समय क्षेत्र के लिए जिम्मेदार सरकार कुछ भी बदलने का निर्णय लेती है। चूंकि हर साल कई समय क्षेत्र डेटाबेस अपडेट होते हैं, इसलिए आप की योजना बनाना चाहेंगे। अपडेट की घोषणाओं की सदस्यता लें और अपना टाइमज़ोन डेटाबेस अपडेट करें नियमित तौर पर। जब भी आप अपना टाइमज़ोन डेटा अपडेट करते हैं, तो आपको भविष्य के सभी इवेंट के यूटीसी समकक्ष समय की पुनर्गणना करनी होगी।
यदि आप एक से अधिक समय क्षेत्र में फैली घटनाओं की किसी भी प्रकार की सूची दिखाने की योजना बना रहे हैं तो यूटीसी समकक्ष होना महत्वपूर्ण है। वे मान हैं जिन्हें आप उस सूची को बनाने के लिए क्वेरी करेंगे।
विचार करने के लिए एक अन्य बिंदु यह है कि यदि कोई घटना स्थानीय समय के लिए निर्धारित की जाती है जो डीएसटी फॉल-बैक संक्रमण के दौरान होती है, तो आपको यह तय करना होगा कि घटना पहली बार (आमतौर पर), या दूसरी घटना (कभी-कभी) पर होती है। या दोनों (शायद ही कभी), और यह सुनिश्चित करने के लिए अपने आवेदन में एक तंत्र बनाएं कि घटना दो बार आग न लगे जब तक आप इसे नहीं चाहते।
यदि आप एक सरल उत्तर की तलाश में थे - क्षमा करें, लेकिन एक नहीं है। समय क्षेत्रों में भविष्य की घटनाओं को निर्धारित करना एक जटिल कार्य है।
वैकल्पिक दृष्टिकोण
मैंने कुछ लोगों से मुझे एक तकनीक दिखाने को कहा है जहां वे करते हैं शेड्यूलिंग के लिए UTC समय का उपयोग करते हैं, यानी वे स्थानीय समय में एक आरंभिक तिथि चुनते हैं, उसे संग्रहीत करने के लिए UTC में परिवर्तित करते हैं, और समय क्षेत्र आईडी भी संग्रहीत करते हैं। फिर रनटाइम पर, वे मूल यूटीसी समय को वापस स्थानीय समय में बदलने के लिए समय क्षेत्र लागू करते हैं, फिर उस स्थानीय समय का उपयोग अन्य पुनरावृत्तियों की गणना करने के लिए करते हैं, जैसे कि यह मूल रूप से ऊपर के रूप में संग्रहीत किया गया था।
जबकि यह तकनीक काम करेगी , कमियां हैं:
-
यदि कोई समय क्षेत्र अद्यतन है जो पहली आवृत्ति के चलने से पहले स्थानीय समय को बदलता है, तो यह पूरे शेड्यूल को बंद कर देगा। इसे "पहले" उदाहरण के लिए अतीत में एक समय चुनकर कम किया जा सकता है, जैसे कि दूसरा उदाहरण वास्तव में पहला है।
-
यदि समय वास्तव में एक "फ्लोटिंग टाइम" है जो उपयोगकर्ता के आसपास (जैसे सेल फोन पर अलार्म घड़ी में) का पालन करना चाहिए, तो आपको उस ज़ोन के लिए समय क्षेत्र की जानकारी संग्रहीत करनी होगी, जो मूल रूप से बनाई गई थी - भले ही अगर यह वह क्षेत्र नहीं है जिसमें आप भागना चाहते हैं।
-
यह बिना किसी लाभ के अतिरिक्त जटिलता जोड़ता है। मैं इस तकनीक को उन स्थितियों के लिए आरक्षित रखूंगा जहां आपके पास एक यूटीसी-केवल शेड्यूलर हो सकता है जिसे आप समय क्षेत्र समर्थन को वापस लेने का प्रयास कर रहे हैं।
