स्थानीय समय के हिसाब से भविष्य के कार्यों की उचित समय-सारणी, खाते के समय क्षेत्र और दिन के समय की बचत को ध्यान में रखते हुए, एक बहुत ही जटिल विषय है। मैं स्टैक ओवरफ़्लो पर एक प्रोग्रामिंग के नजरिए से पहले इसके बारे में लिखा है यहाँ और यहाँ ।
मैं गैर-प्रोग्रामिंग दृष्टिकोण से संक्षेप में बताऊंगा:
स्थानीय समयानुसार अपने पुनरावृत्ति पैटर्न को परिभाषित करें - UTC नहीं । उदाहरण के लिए, यदि आप प्रतिदिन सुबह 8:00 बजे उठने के लिए एक दैनिक अलार्म घड़ी सेट करते हैं, तो आप दिन के समय की बचत के बाद एक घंटे पहले या एक घंटे देर से उठना नहीं चाहते हैं। यदि मैं यूएस पैसिफिक टाइम ज़ोन में हूं, तो मैं 4:00 PM UTC के लिए शेड्यूल नहीं कर सकता, क्योंकि संक्रमण के बाद उसी स्थानीय समय 8:00 बजे को रखने के लिए इसे 3:00 PM UTC पर स्विच करना होगा।
उस समय क्षेत्र को परिभाषित करें जो "स्थानीय" समय दर्शाता है। यह मत समझो कि सर्वर का स्थानीय समय क्षेत्र एक ही समय क्षेत्र है जो अंतिम उपयोगकर्ता के लिए मायने रखता है।
प्रत्येक घटना के लिए एक UTC दिनांक और समय के स्थानीय समय को प्रोजेक्ट करें जो आप चाहते हैं कि ईवेंट आग लग जाए।
आप लगभग हमेशा अगली तत्काल घटना के लिए ऐसा करेंगे, जैसे कि आप यूटीसी घड़ी का उपयोग चलाने के लिए वास्तविक तत्काल समय निर्धारित करने के लिए कर सकते हैं।
में कुछ मामलों में, आप भी इस तरह के अगले 5 घटनाओं, या अगले साल के लिए सभी घटनाओं के रूप में अगले कई (या कई) उदाहरणों, परियोजना के लिए कर सकते हैं। (यह हिस्सा आवेदन की आवश्यकताओं के लिए अत्यधिक विशिष्ट है।)
दिन के उजाले की बचत के संक्रमण के समय घटित होने वाली घटनाओं के लिए क्या करना है (या तो निश्चित या विन्यास योग्य) में एक रणनीति रखें :
"स्प्रिंग फ़ॉरवर्ड" संक्रमण के लिए, स्थानीय समय के लापता होने का अंतराल होता है जब घटना मौजूद नहीं हो सकती है। उदाहरण के लिए, यूएस पैसिफ़िक समय में, एक दैनिक कार्य जो स्थानीय समयानुसार 2:00 बजे चलने वाला है, 9 मार्च, 2014 को मौजूद नहीं होगा। ज्यादातर मामलों में, आप उस समय को बचत राशि (आमतौर पर 1 घंटे) से आगे बढ़ाना चाहेंगे। ), इसलिए उस दिन यह अपराह्न 3:00 बजे चलेगा, लेकिन अगले समय 2:00 पूर्वाह्न पर वापस चलेगा। (हालांकि, यह पूरी तरह से संभव है कि आप इसके लिए एक अलग रणनीति चाहते हैं।)
"फ़ॉल बैक" संक्रमण के लिए, दोहराए गए स्थानीय समय का ओवरलैप होता है जब घटना दो बार मौजूद हो सकती है । उदाहरण के लिए, यूएस पैसिफिक टाइम में, 1:00 बजे चलने वाले एक दैनिक कार्य में दो संभावित समय होंगे जो 2 नवंबर 2014 को चल सकते हैं। ज्यादातर मामलों में, आप 1 की पहली घटना पर चलना चाहेंगे। : 00 AM पीडीटी और उसी तिथि के 1:00 पूर्वाह्न पीएसटी की अगली घटना को छोड़ दें। (लेकिन फिर से, आप कर सकते हैं एक अलग रणनीति इस तरह के दूसरे घटना पर चल रहा है, या दोनों में चल रहे के रूप में चाहते हैं। YMMV)
यदि आपको कभी भी अपना समय क्षेत्र डेटा अपडेट करने की आवश्यकता हो, तो अपने सभी होने वाले UTC समयों को पुनर्गणना करने के लिए तैयार रहें । IANA / ओल्सन TZDB हर साल कई अद्यतन डालता है क्योंकि उनके समय क्षेत्र ऑफसेट और डेलाइट बचत समय नियमों के बारे में दुनिया को बदलते हुए उनके दिमाग में हर समय की सरकारों। आप भविष्य में किसी भी विशिष्ट अवधि के लिए मान नहीं सकते हैं कि नियम नहीं बदलेंगे ।
समय क्षेत्र डेटा रिलीज़ की घोषणाओं के लिए सदस्यता सुनिश्चित करें , और उन्हें आपके सिस्टम और / या अनुप्रयोगों पर लागू करने के लिए एक प्रक्रिया हो।
एक पारंपरिक कॉर्पोरेट सेटिंग में, यह आईटी ऑपरेशंस स्टाफ की जिम्मेदारी होनी चाहिए।
आपके वातावरण के आधार पर, आपको यह डेटा tzdataलिनक्स पैकेज अपडेट, जावा JRE या tzupdater , या किसी अन्य चैनल के माध्यम से मिल सकता है । कभी-कभी यह पर्यावरण विशिष्ट होता है, और कभी-कभी यह प्रोग्रामिंग प्लेटफ़ॉर्म विशिष्ट होता है, जैसे कि PHP के लिए टाइमज़ोनबेड PECL पैकेज और कई अन्य।
Microsoft का अपना समय क्षेत्र डेटा है। Windows पर, यदि आप TimeZoneInfo.NET (उदाहरण के लिए) का उपयोग कर रहे हैं, तो आप इस डेटा का उपयोग कर रहे हैं। अपडेट यहां से आते हैं , और स्वचालित रूप से विंडोज अपडेट के माध्यम से भी बाहर धकेल दिए जाते हैं, इसलिए आपको उन लोगों पर नजर रखनी चाहिए, ताकि आपको पता चल जाए कि आपको कब / क्या पुनर्गणना करने की आवश्यकता है।
कि समझ में आ के सभी के साथ, वहाँ है अभी भी एक परिदृश्य में जहाँ आप यूटीसी द्वारा बस अनुसूची होता है, और उस के लिए है ABSOLUTE भविष्य की घटनाओं। उदाहरण:
एक ऐसा काम जो हर X घंटे या हर X मिनट चलता है।
सूर्योदय के समय और अन्य खगोलीय घटनाएँ शुरू होती हैं।
एक समय के प्रति संवेदनशील सुरक्षा खिड़की, जैसे कि किसी पूर्वाभासित समय में संवेदनशील जानकारी को किसी अन्य पार्टी में स्थानांतरित करना।
विंडोज टास्क शेड्यूलर
विंडोज जरूरी नहीं कि सही काम हो। ध्यान दें कि आप ट्रिगर को कैसे परिभाषित करते हैं:
जब आप "समय क्षेत्रों में सिंक्रनाइज़ करें" लेबल वाले बॉक्स की जांच करते हैं, तो कार्य केवल यूटीसी द्वारा निर्धारित किया जाता है। (सभी समय को अभी भी स्थानीय समय के रूप में दिखाया जाता है, लेकिन इसे यूटीसी के रूप में संग्रहीत किया जाता है।) तो यह उस चीज के लिए है जिसे मैंने पहले "पूर्ण" घटना कहा था।
जब आप उस बॉक्स को अनियंत्रित छोड़ देते हैं, तो यह उस कंप्यूटर के स्थानीय समय क्षेत्र का उपयोग करने वाला है जिस पर कोड चल रहा है। यह आपको समय क्षेत्र निर्दिष्ट करने का कोई विकल्प नहीं देता है, इसलिए यह बहुत अच्छा कार्यान्वयन IMHO नहीं है।
मुझे यकीन नहीं है कि यह डीएसटी व्यवहार है, लेकिन मैं प्रयोग करूंगा और आपको उस पर वापस लाऊंगा। यह शायद वही है जो मैंने ऊपर वर्णित किया है, लेकिन जरूरी नहीं।
एसक्यूएल एजेंट
SQL एजेंट शेड्यूलर और भी बदतर है, इसमें आप केवल स्थानीय सर्वर समय का उपयोग कर सकते हैं। फिर से, कोई समय क्षेत्र निर्दिष्ट नहीं किया जा सकता है, और आप यूटीसी को भी निर्दिष्ट नहीं कर सकते हैं।
इसका अनुरोध किया गया है , लेकिन स्वीकार नहीं किया गया।