समय क्षेत्र के बारे में सोचना बंद कैसे करें और जीना शुरू करें

क्या समय आपके सिस्टम में एक महत्वपूर्ण भूमिका निभाता है? क्या आपके उपयोगकर्ताओं / घटकों को दुनिया भर में वितरित किया जाता है, या कम से कम हमारी विशाल मातृभूमि? इसलिए आपको समय क्षेत्र की आवश्यकता है। खैर, यह आसान है। आपको जो सबसे मुश्किल काम करना है, वह उलझना नहीं है। हम इस बारे में बात करेंगे पहले आपको सही ढंग से सोचने के लिए सीखने की जरूरत है। सही ढंग से सोचने पर, बाकी सब कुछ आपके लिए स्वयं स्पष्ट या सरल होगा।



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



हमें कुछ सरल और बुलेटप्रूफ चाहिए, जैसे ... पूर्णांक। यह इस प्रकार है कि समय में तुरंत (तुरंत समय, यूनिक्स समय, पॉसिक्स समय, यूनिक्स (यूनिक्स) के बाद का समय) की अवधारणा दिखाई दी, जो 1 जनवरी, 1970, 00:00:00 से पारित सेकंड (जावा में मिलीसेकंड) में सेकंड की संख्या है। जीएमटी। समय का क्षण दुनिया भर में समान है - यदि आप कल्पना करते हैं कि किसी ने "ठहराव" पर क्लिक किया और समय का प्रवाह रुक गया, तो पृथ्वी भर में समय के क्षण के अनुरूप संख्या समान होगी, समय क्षेत्र की परवाह किए बिना। अगर किसी ने ग्रीनविच को नया 1970 शुरू करने के एक घंटे बाद रोका, तो पृथ्वी भर में एक बिंदु 3,600,000 दिखाएगा। और अब, उदाहरण के लिए, यह पहले से ही नंबर 1 280 720 431.859 है।



तो, समय का क्षण कंप्यूटिंग की एक सार्वभौमिक परिवर्तनीय मुद्रा है। यह केवल पर निर्भर करता है, हम्म, समय, क्षणों की तुलना की जा सकती है (क्रमशः, यह निर्धारित करने के लिए कि कौन सी घटना पहले हुई थी और कौन सी बाद में), और इसमें भौगोलिक स्थान, समय क्षेत्र और घड़ी स्थानांतरण से संबंधित कोई भी बकवास शामिल नहीं है, जो नाटकीय रूप से बढ़ सकता है इस तरह की गणना की विश्वसनीयता। वास्तव में, यह है कि जावा में समय के साथ काम कैसे लागू किया जाता है (संस्करण 1.1 से), जहां java.util.Date एक लंबे समय से अधिक समय के लिए एक आवरण है (नकारात्मक लोंगो 1970 से पहले की तारीखों के अनुरूप हैं), तुलनीय है, और सभी मानव-कैलेंडर रूपांतरण हैं अलग कैलेंडर और DateFormat कक्षाओं में ले जाया गया।



रूपांतरण के बारे में। संख्या 1 280 720 431.859 एक साधारण व्यक्ति के लिए बहुत कम कहेगी (हालांकि एक जिज्ञासु पाठक इन पंक्तियों को लिखते समय उससे समय की गणना कर सकता है), इसलिए आपको समय को दीवार घड़ी के समय में अनुवाद करने में सक्षम होना चाहिए, और, तदनुसार, पल दीवार घड़ी को समय पर वापस करें समय में। लेकिन इन परिवर्तनों के लिए पहले से ही समय क्षेत्र जानना आवश्यक है, और ये गणना बिल्कुल तुच्छ नहीं है। तथ्य यह है कि विभिन्न देशों / क्षेत्रों / स्थानों में, न केवल जीएमटी (जीएमटी) के संबंध में अलग-अलग ऑफसेट हैं, इन ऑफसेटों के नियमों में ऐतिहासिक रूप से कई बार बदलाव हुए हैं और बदलते रहते हैं (दिन के उजाले की बचत को रद्द / रद्द करें, बेल्ट को मिलाएं - सुना है) इस तरह की एक पहल के बारे में शायद हमारे पास है; या, उदाहरण के लिए याद रखें, नोवोसिबिर्स्क का मेरा गृहनगर, जो नब्बे के दशक की शुरुआत में GMT + 7 से GMT + 6 में स्थानांतरित किया गया था, और सदी की शुरुआत में यह आम तौर पर दो बेल्ट था - बेल्ट की सीमा ओब नदी के साथ गुजरती थी , और विभिन्न बैंकों पर अलग-अलग बेल्ट थे)। संक्षेप में, पागल न होने के लिए, ऑर्थर डेविड ओल्सन के संस्थापक के नाम पर ऑलसन tz डेटाबेस के रूप में यह सभी ऐतिहासिक जानकारी बड़े करीने से बनी हुई है, हालांकि संपादक पॉल एगर्ट हैं। इस डेटाबेस में, प्रत्येक बड़ी बस्ती एक कोड से मेल खाती है (नोवोसिबिर्स्क, उदाहरण के लिए, एशिया / नोवोसिबिर्स्क को इस डेटाबेस द्वारा कहा जाता है) और समय क्षेत्र द्वारा अपने सभी कारनामों की एक सूची, 1970 में शुरू होती है। इस डेटाबेस का उपयोग कई (सभी?) लिनक्स / यूनिक्स / बीएसडी प्रणालियों में किया जाता है, मैंने विंडोज़ के बारे में जावा रनटाइम एनवायरनमेंट में नहीं कहा है (उदाहरण के लिए, इसमें विशेष रूप से tz डेटाबेस को अपडेट करने से संबंधित कुछ अपडेट थे), और इसी तरह, सामान्य रूप से देखें, विकिपीडिया । हम इस डेटाबेस से / के लिए समय रूपांतरण एल्गोरिथ्म पर विचार नहीं करेंगे, हम मान लेंगे कि हमारे पास यह तैयार है। वह, वास्तव में, लगभग हर जगह तैयार है।



इसलिए, हम कई समय क्षेत्रों में चल रहे कार्यक्रमों के साथ समय को संभालने के लिए नियम बनाते हैं:

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

ऊपर से अंतिम आइटम का पालन नहीं होता है, इसलिए हम इसे अलग से विश्लेषण करेंगे। डेटाबेस के साथ काम करते समय (मेरे पास केवल Oracle और sqlite3 के साथ अनुभव है), अर्थात् जब किसी डेटाबेस से बचत / रीडिंग, किसी कारण से, समय क्षेत्र की आवश्यकता होती है। और इसका मतलब है कि बचत / पढ़ने के बाद, आप डेटा को खराब कर सकते हैं। कैसे बिगाड़ेंगे? गर्मी के मौसम (02) से सर्दियों के समय (02:00 - 03:00 अक्टूबर 27, 2002, उदाहरण के लिए) के संक्रमण से जुड़ी एक अप्रिय विशेषता है: एक घंटे के लिए संक्रमण के दौरान, प्रत्येक दीवार घड़ी समय मान समय में दो बिंदुओं से मेल खाती है (घंटे) दो बार दिखाओ 02:01, 02:02, 02:03, आदि, जबकि ये समय के अलग-अलग बिंदु हैं)। यही कारण है कि, हम स्पष्ट रूप से दीवार घड़ी समय 02:30 को 10.27.2002 पर निर्धारित नहीं कर सकते हैं कि यह समय क्या है, क्योंकि हम नहीं जानते कि यह गर्मी या सर्दियों का समय है। यदि हम समय पर एक निश्चित समय प्राप्त करते हैं और इसे 10:30 बजे 02.22 बजे बदल देते हैं, तो हम रिवर्स ट्रांसफ़ॉर्म को विशिष्ट रूप से पूरा नहीं कर पाएंगे।



आप इस समस्या के विभिन्न समाधानों के साथ आ सकते हैं - विशेषता L / C को एक अलग कॉलम में स्टोर करने के लिए, NUMBER प्रकार के कॉलम में समय को स्टोर करने के लिए, लेकिन UTC में दिनांक / समय को संग्रहीत करने के लिए यह मुझे सबसे कम कट्टरपंथी और सरल लगता है। UTC टाइम ज़ोन में कोई डेलाइट सेविंग टाइम नहीं होता है, इसलिए समय रूपांतरणों में तुरंत दीवार घड़ी का समय हमेशा स्पष्ट रूप से प्रदर्शित किया जाता है। इस तथ्य के अलावा कि यह दृष्टिकोण आपको डेटाबेस में समय के सभी क्षणों को स्टोर करने की अनुमति देता है, जिसमें घड़ी स्थानांतरण भी शामिल है, यह भी है:

1. विषयों (यदि आप परिवर्तनों में कहीं समय क्षेत्र निर्दिष्ट करना भूल जाते हैं, तो आप तुरंत देखेंगे कि कुछ सही नहीं है, कम से कम यदि आप यूटीसी में नहीं रहते हैं);
2. डेटाबेस में जानकारी अलग-अलग समय क्षेत्रों से आने पर आपको तारीखों / समय में भ्रमित नहीं होने देता है - डेटाबेस में, समय हमेशा यूटीसी में होता है;
3. कोड को सरल करता है, क्योंकि डेटाबेस से समय को / में परिवर्तित करते समय, आप समय क्षेत्र के बारे में नहीं सोच सकते, यह हमेशा समान होता है।

अंत में, अजगर में समय क्षेत्र के साथ काम करने के बारे में कुछ शब्द। पाइथन में, डेटटाइम लाइफटाइम लाइफटाइम क्लास का उपयोग डेट्स के साथ काम करने के लिए किया जाता है, और उसी ओल्सन tz डेटाबेस पर आधारित pytz मॉड्यूल का उपयोग टाइम जोन के साथ काम करने के लिए किया जाता है। उनके पास प्रत्यक्ष समय बिंदु नहीं हैं, इसके बजाय दो अवधारणाएँ हैं: टाइमज़ोन-अवगत डेटाटाइम और भोले डेटाटाइम। पहला, निश्चित रूप से, निर्दिष्ट समय क्षेत्र के साथ एक तारीख-समय है, दूसरा एक भोली तारीख-समय है, अपने शुद्ध रूप में, दीवार घड़ी समय निर्दिष्ट किए बिना जहां ये दीवार घड़ियां लटकाते हैं। डेटाटाइम को संरचनाओं के रूप में संग्रहीत किया जाता है "वर्ष माह दिन घंटे मिनट दूसरा माइक्रोसेकंड" और साथ ही tzinfo ऑब्जेक्ट के लिए tz- अवगत डेटाटाइम। समय का एक समय केवल time.time () के माध्यम से प्राप्त किया जा सकता है, यह एक फ्लोट होगा और यह कुछ हद तक सीमित होगा जैसे [1970, 2038], यानी यह आसानी से कुछ गणनाओं के लिए पर्याप्त नहीं हो सकता है। यही है, (जहां तक ​​मैं समझता हूं, शायद वे मुझे सही करेंगे?) अपने डेटाइम में, एक समय क्षेत्र से दूसरे में सीधे अनुवाद करने के लिए एक ही एल्गोरिदम जैसा कुछ लागू किया जाता है, समय के बिना, लेकिन सैद्धांतिक रूप से कोई भी तारीखों को समझ सकता है, 1 से 9999 वर्ष।



Naive को विधि का उपयोग करके tz-जागरूक डेटाटाइम में अनुवादित किया जाता है:



tzaware_datetime = some_timezone.localize(some_naive_datetime, is_dst=True)





(दूसरे पैरामीटर पर ध्यान दें, यह केवल अस्पष्ट परिवर्तन के कारण आवश्यक है), या



another_tzaware_datetime = tzaware_datetime.astimezone(another_tz)





(tz- अवगत दिनांक-समय को अन्य समय क्षेत्र में अनुवाद करना)।



चूँकि यह सब एक ही datetime.datetime क्लास के माध्यम से लागू किया गया है और tzinfo प्रॉपर्टी की उपलब्धता में पूरे अंतर के लिए, आपको यह ध्यान रखने की ज़रूरत है कि हम जहाँ समय क्षेत्र के साथ तारीखें हैं और जहाँ नहीं है, वहाँ मिश्रण न करें। इधर, अजगर इस मायने में जावा से भी बदतर है कि जब आप प्रिंट करना चाहते हैं, तो आप नहीं चाहते हैं, लेकिन आपको एक DateFormat बनाने और टाइम ज़ोन को निर्दिष्ट करने की आवश्यकता है, पायथन में, कई ऑपरेशन, सहित और मुद्रण, भोली तारीखों के लिए किया जा सकता है। यह स्पष्ट है कि एक जटिल आवेदन में यह ध्यान रखना उचित है कि सभी तिथियां एक समय क्षेत्र के साथ हैं, क्योंकि यदि आवेदन के कुछ बिंदु पर यह पता चलता है कि यह वहां नहीं है, तो आप पहले से ही अंजीर का पता लगा लेंगे और इसमें क्या होना चाहिए। और बेल्ट और तारीखों की तुलना सही ढंग से, और प्रिंट आउट, और सामान्य रूप से की जाएगी। इसके अलावा, चूंकि डेटाबेस से पढ़ने / लिखने पर केवल भोले भाग (वर्ष माह दिन घंटे मिनट सेकेंड माइक्रोसेकंड) को बचाया जाता है, इसके साथ काम करने का एकमात्र समझदार तरीका डेटाबेस में यूटीसी में एक भोली प्रतिनिधित्व है।

बोनस

कैलेंडर तिथियों के साथ काम करने वाले व्यक्ति के नियम याद रखें कि:

1. हर साल 365 दिन नहीं;
2. हर दिन 24 घंटे नहीं;
3. सौभाग्य से, हर घंटे 60 मिनट है;
4. हर मिनट 60 सेकंड नहीं (यह 59 और 61 हो सकता है। 61 वें को लीप सेकंड कहा जाता है, 30 जून या 31 दिसंबर को या तो जोड़ा जाता है, उस समय यूटीसी में घड़ी 23:59:60 दिखाना चाहिए। 61 वें सेकंड का जोड़ धीमा होने के कारण होता है। पृथ्वी का घूमना। एक सेकंड लेने का अवसर उन मामलों के लिए प्रदान किया जाता है जब पृथ्वी तेजी से घूमना शुरू करती है, लेकिन इस अवसर की आवश्यकता नहीं होती है)।

जीएमटी समय की गणना उस क्षण से नहीं की जाती है जब सूरज मेरेडियन को पार करता है, लेकिन इस घटना के कुछ औसत समय से। पृथ्वी की कक्षा की अण्डाकारता के कारण मेरिडियन का वास्तविक चौराहा 16 मिनट तक भिन्न हो सकता है।



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



UNIX सिस्टम पर 32 हस्ताक्षरित तारीख में तारीख जमा करने से 2038 समस्या होने की उम्मीद है , जब 31 बिट्स ओवरफ्लो और नकारात्मक संख्या समय के बाद के क्षणों के अनुरूप होंगे, जो सभी तुलना विधियों को तोड़ देगा। नए 64-बिट सिस्टम और प्रोग्राम पहले से ही समय को स्टोर करने के लिए 64 बिट्स का उपयोग करते हैं, लेकिन क्या ऐसे सिस्टम में 2038 तक 32-बिट्स को पूरी तरह से बदलने का समय होगा?