ध्यान में रखते हुए दोहराने वाली तिथियों को कैसे स्टोर करें डेलाइट सेविंग्स टाइम

Question

मैं अपने डेटाबेस में ईवेंट संग्रहीत कर रहा हूं। मेरे पास 'स्टार्ट' और 'एंड' डेट टाइम्स, 'टिकट_स्टार्ट' और 'टिकट_एंड' (जब टिकट बिक्री वास्तव में शुरू/अंत होती है - वास्तविक घटना के प्रारंभ/अंत के विपरीत)।

अब तक, मैंने उन तरीकों का निर्माण किया है जो सभी मजेदार सामानों को सहेजने से पहले दिनांक/समय को जीएमटी में परिवर्तित करने जैसे प्रदर्शन के लिए अपने संबंधित टाइमज़ोन पर वापस आते हैं।

मैं "अमेरिका/न्यू_यॉर्क" जैसे मूल्यों के साथ एक वर्चर फ़ील्ड में टाइमज़ोन संग्रहीत कर रहा हूं।

लेकिन - अगर उपयोगकर्ता दोहराने की घटनाओं को अनुमति देना चाहता है तो अब मुझे इससे निपटना शुरू करना होगा। मैंने इसे पहले किया है, और यह इतना बड़ा सौदा नहीं है, लेकिन कई टाइमज़ोन में कभी नहीं।

पहले, मैंने सोचा कि यह कोई बड़ा सौदा नहीं होगा, लेकिन फिर एहसास हुआ कि - यदि प्रारंभिक प्रारंभ तिथि जुलाई (उदाहरण के रूप में) में थी, और यह हर महीने एक महीने के लिए दोहराती है, किसी बिंदु पर, डेलाइट सेविंग्स समय यह होगा कि जीएमटी से रूपांतरण अलग-अलग समय बदल जाएगा। एक महीने, जब 12:00 को परिवर्तित किया जाता है, तो यह इसे -5 में बदल देगा, और अगला, यह डीएसटी की वजह से -4 में बदल जाएगा।

मेरा वर्तमान विचार यह है कि मैं डीएसटी के दौरान प्रारंभ/समाप्ति तिथियां दर्ज की गई थी या नहीं, और फिर आवश्यक होने पर एक घंटे तक समय बदलने के लिए एक विधि बना सकता हूं।

लेकिन - मुझे लगा कि मैं उम्मीदों में यहां पूछूंगा कि शायद इसके लिए "सामान्य" या एक आसान चीज़ है जिसे मैं नहीं सोच रहा हूं।

(CakePHP 2.4.x)

Answer 1

पहले, पहचान दें कि आधुनिक शब्दावली में आप यूटीसी के बजाय जीएमटी कहना चाहिए। वे अधिकतर समकक्ष हैं, सिवाय इसके कि यूटीसी अधिक सटीक रूप से परिभाषित है। यूनाइटेड किंगडम में समय क्षेत्र के हिस्से को संदर्भित करने के लिए जीएमटी शब्द को आरक्षित करें जो कि यूएफसी + 0 ऑफसेट होने वाले सर्दियों के महीनों के दौरान प्रभावी है।

अब आपके प्रश्न पर। यूटीसी सभी तारीख और समय मूल्यों को स्टोर करने का सबसे अच्छा तरीका नहीं है। यह विशेष रूप से अच्छी तरह से पिछले घटनाओं के लिए, या भविष्य पूर्ण घटनाओं के लिए काम करता है, लेकिन यह भविष्य स्थानीय घटनाओं के लिए इतना बड़ा काम नहीं करता है - विशेष रूप से भविष्य आवर्ती घटनाओं।

मैंने हाल ही में इस on another answer के बारे में लिखा है, और कुछ अपवाद मामलों में से एक है जहां स्थानीय समय यूटीसी की तुलना में अधिक समझ में आता है। मुख्य तर्क "अलार्म घड़ी की समस्या" है। यदि आप यूटीसी द्वारा अपनी अलार्म घड़ी सेट करते हैं, तो आप डीएसटी संक्रमण के दिन जल्दी या देर से जाग रहे होंगे। यही कारण है कि ज्यादातर लोगों ने स्थानीय समय से अपने अलार्म घड़ियों को सेट किया।

बेशक, आप स्थानीय समय स्टोर नहीं कर सकते हैं यदि आप दुनिया भर से डेटा के साथ काम कर रहे हैं। आप कुछ अलग बातें संग्रहीत करना चाहिए:

• पुनरावर्ती ईवेंट की स्थानीय समय, इस तरह के "08:00"
• समय क्षेत्र, इस तरह के "America/New_York 'के रूप में है कि स्थानीय समय में व्यक्त किया है के रूप में
• पुनरावृत्ति पैटर्न, जो भी प्रारूप आपके आवेदन के लिए समझ में आता है, जैसे दैनिक, द्वि साप्ताहिक, या महीने के तीसरे गुरुवार इत्यादि।
• अगले तत्काल यूटीसी दिनांक और समय बराबर है, सबसे अच्छा है कि आप इसे पेश कर सकती हैं करने के लिए।
• शायद, लेकिन हमेशा नहीं, भविष्य घटना यूटीसी तारीख और समय की एक सूची, बाहर भविष्य में कुछ पूर्वनिर्धारित अवधि (शायद एक सप्ताह, शायद 6 महीने, शायद या दो, अपनी आवश्यकताओं के आधार पर एक वर्ष) का अनुमान।

पिछले दो के लिए, समझते हैं कि किसी भी स्थानीय दिनांक/समय की यूटीसी बराबर है, तो सरकार उस समय क्षेत्र के लिए जिम्मेदार कुछ भी बदलने का फैसला करता है बदल सकते हैं। चूंकि हर साल कई समय क्षेत्र डेटाबेस अपडेट होते हैं, इसलिए आप subscribe to announcements of updates और update your timezone database नियमित रूप से योजना बनाना चाहते हैं। जब भी आप अपना टाइमज़ोन डेटा अपडेट करते हैं, तो आपको भविष्य की घटनाओं के यूटीसी समकक्ष समय को फिर से समझना होगा।

यूटीसी समकक्ष होने महत्वपूर्ण यदि आप एक से अधिक समय क्षेत्र में फैले घटनाओं की सूची के किसी भी प्रकार दिखाने की योजना है। वे वे मान हैं जिन्हें आप उस सूची को बनाने के लिए क्वेरी करेंगे।

विचार करने का एक और मुद्दा यह है कि यदि किसी ईवेंट को स्थानीय समय के लिए निर्धारित किया जाता है जो डीएसटी फॉल-बैक संक्रमण के दौरान होता है, तो आपको यह तय करना होगा कि घटना पहले उदाहरण (आमतौर पर), या दूसरी घटना पर होती है या नहीं (कभी-कभी), या दोनों (शायद ही कभी), और आपके आवेदन में एक तंत्र को सुनिश्चित करने के लिए एक तंत्र को आग लगाना सुनिश्चित नहीं करता है जब तक कि आप इसे नहीं चाहते हैं।

यदि आप एक साधारण उत्तर की तलाश में थे - क्षमा करें, लेकिन कोई नहीं है। समय क्षेत्रों में भविष्य की घटनाओं का निर्धारण करना एक जटिल कार्य है।

वैकल्पिक दृष्टिकोण

मैं कुछ लोगों को मिला है मुझे एक तकनीक है, जहां वे निर्धारण, जो यह है कि वे स्थानीय समय में एक प्रारंभिक तिथि चुन लिए उपयोग UTC समय कर दिखाने के लिए, यूटीसी है कि परिवर्तित होने के लिए संग्रहीत, और समय क्षेत्र आईडी भी स्टोर करें। फिर रनटाइम पर, वे मूल यूटीसी समय को स्थानीय समय में बदलने के लिए समय क्षेत्र लागू करते हैं, फिर उस स्थानीय समय का उपयोग अन्य पुनरावर्तनों की गणना करने के लिए करते हैं, जैसे कि यह मूल रूप से ऊपर के रूप में संग्रहीत किया गया था।

जबकि इस तकनीक जाएगा काम, कमियां हैं:

• अगर वहाँ एक समय क्षेत्र अद्यतन कि स्थानीय समय में परिवर्तन करने से पहले पहले उदाहरण चलाया जाता है है, यह पूरे अनुसूची फेंक होगा। इसे "पहले" उदाहरण के लिए अतीत में एक समय चुनकर कम किया जा सकता है, जैसे कि दूसरा उदाहरण वास्तव में पहला है।

• यदि समय वास्तव में एक "फ़्लोटिंग टाइम" है जो उपयोगकर्ता के आसपास (जैसे सेल फ़ोन पर अलार्म घड़ी में) का पालन करना चाहिए, तो आपको उस क्षेत्र के लिए समय क्षेत्र जानकारी संग्रहीत करनी होगी जो मूल रूप से थी में बनाया -। भले ही उस क्षेत्र, जहां आप चलाना चाहते हैं नहीं है

• यह किसी भी लाभ के बिना अतिरिक्त जटिलता कहते हैं। मैं इस तकनीक को उन स्थितियों के लिए आरक्षित कर दूंगा जहां आपके पास यूटीसी-केवल शेड्यूलर हो सकता है जिसे आप समय क्षेत्र समर्थन को फिर से निकालने का प्रयास कर रहे हैं।