जीएमटी में सबकुछ स्टोर करें?भंडारण में समय क्षेत्र हैंडलिंग?
एम्बेडेड ऑफ़सेट के साथ जिस तरह से दर्ज किया गया था उसे स्टोर करें?
गणित हर बार जब आप प्रस्तुत करते हैं?
रिश्तेदार टाइम्स "1 मिनट पहले" प्रदर्शित करें?
आपको यूटीसी में स्टोर करना होगा - यदि आप नहीं करते हैं, तो डेलाइट सेविंग्स जैसी चीजों के दौरान आपकी ऐतिहासिक रिपोर्टिंग और व्यवहार ... मजेदार है। जीएमटी एक स्थानीय समय है, यूटीसी के सापेक्ष डेलाइट सेविंग्स (जो नहीं है) के अधीन है।
अलग-अलग समय में उपयोगकर्ताओं को प्रस्तुतिकरण यदि आप स्थानीय समय संग्रहित कर रहे हैं तो ज़ोन वास्तविक बेस्टर्ड हो सकते हैं। यदि आपका कच्चा डेटा यूटीसी में है तो स्थानीय में समायोजित करना आसान है - बस अपने उपयोगकर्ता का ऑफसेट जोड़ें और आप कर चुके हैं!
जोएल ने पॉडकास्ट में से एक (इसके बारे में एक तरह से) में इस बारे में बात की - उसने store your data in the highest resolution possible ('फिडेलिटी' की खोज) से कहा, क्योंकि आप इसे फिर से बाहर जाने पर हमेशा इसे बंद कर सकते हैं। यही कारण है कि मैं इसे यूटीसी के रूप में स्टोर करता हूं, क्योंकि स्थानीय समय के लिए आपको उस समय के लिए समायोजित करने की आवश्यकता होती है जो उस समय क्षेत्र में नहीं है, और यह बहुत मेहनत है। और आपको स्टोर करने की आवश्यकता है कि, उदाहरण के लिए, जब आप समय संग्रहीत करते हैं तो डेलाइट बचत प्रभावी होती है। युक।
अक्सर अतीत में डेटाबेस में मैंने दो - यूटीसी को सॉर्ट करने के लिए, स्थानीय समय के प्रदर्शन के लिए संग्रहीत किया है। इस तरह न तो उपयोगकर्ता और न ही कंप्यूटर भ्रमित हो जाता है।
अब प्रदर्शित करने के लिए: निश्चित रूप से, आप "3 मिनट पहले" चीज कर सकते हैं, लेकिन केवल अगर आप यूटीसी स्टोर करते हैं - अन्यथा, अलग-अलग टाइमज़ोन में दर्ज डेटा, जैसे -4 घंटे पहले प्रदर्शित होता है ", जो लोगों को फटकार देगा। यदि आप वास्तविक समय प्रदर्शित करने जा रहे हैं, तो लोग इसे अपने स्थानीय समय में रखना पसंद करते हैं - और यदि डेटा कई टाइमज़ोन में दर्ज किया जा रहा है तो आप केवल यूटीसी को संग्रहीत करते समय आसानी से ऐसा कर सकते हैं।
व्यक्तिगत रूप से, मुझे जीएमटी में सब कुछ स्टोर न करने का कोई कारण नहीं दिख रहा है और फिर उपयोगकर्ताओं को स्थानीय टाइमज़ोन का उपयोग समय के साथ प्रदर्शित करने के लिए करता है।
यदि आप सापेक्ष समय प्रदर्शित करना चाहते हैं, तो आपको स्पष्ट रूप से समय की आवश्यकता है और अनुवाद करना है, लेकिन यदि आप अनुवाद करना चाहते हैं तो मुझे लगता है कि जीएमटी अभी भी आपका सबसे अच्छा विकल्प है।
मुद्दा यह है कि, लोगों को संवाद करने, कहने, समय सीमा के दौरान स्वचालित प्रक्रियाओं का उपयोग किस समय किया जाता है? क्या आप उपयोगकर्ताओं को टाइमज़ोन स्टोर करते हैं क्योंकि उन्होंने इसे तय किया है और सभी संचारों में इसका उपयोग किया है? – DevelopingChris
मुझे जीएमटी में स्टोर करना पसंद है और केवल रिश्तेदार दिखाना ("लगभग 10 सेकंड पहले", "5 महीने पहले")। उपयोगकर्ताओं को अधिकांश उपयोग मामलों के लिए वास्तविक टाइमस्टैम्प देखने की आवश्यकता नहीं है।
निश्चित रूप से अपवाद हैं, और एक व्यक्तिगत एप्लिकेशन में उनमें से कई हो सकते हैं, इसलिए यह 'एक-सही-रास्ता' उत्तर नहीं हो सकता है। जिन चीजों को मजबूत लेखापरीक्षा क्षमता (जैसे मतदान) की आवश्यकता होती है, और सिस्टम जहां समय व्याख्यान (खगोल विज्ञान, वैज्ञानिक अनुसंधान) के क्षेत्र का हिस्सा है, उपयोगकर्ता को दिखाए जाने के लिए सही टाइमस्टैम्प की मांग कर सकता है।
अधिकांश ऐप्स, हालांकि, एक सापेक्ष सापेक्ष समय के साथ समझना आसान है।
तो मैंने एमएसएसक्यूएल सर्वर के साथ थोड़ा प्रयोग चलाया।
मैंने एक टेबल बनाया और वर्तमान स्थानीयकृत टाइमज़ोन (ऑस्ट्रेलिया) के साथ एक पंक्ति जोड़ा। फिर मैंने अपना डेटाटाइम जीएमटी बनने के लिए बदल दिया और एक और पंक्ति जोड़ा।
यहां तक कि उन पंक्तियों को लगभग 10 सेकंड के अलावा जोड़ा गया था, वे SQL सर्वर में दिखाई देते हैं क्योंकि वे 10 घंटे अलग हैं।
यदि कुछ और नहीं है, तो कम से कम मुझे यह बताता है कि मुझे एक संयोग से तारीखों को संग्रहित करना चाहिए, जो मेरे लिए, जीएमटी के रूप में उन्हें संग्रहीत करने के लिए तर्क में वजन बढ़ाता है।
उन्हें एक एम्बेडेड ऑफ़सेट के साथ संग्रहीत करने का अर्थ हो सकता है, 2 कॉलम, जीएमटी समय, और ऑफसेट चुने गए व्यक्ति, स्वचालित रूप से एक वर्ग sqlserver या क्लाइंट मशीन नहीं। – DevelopingChris
एमएस डायनेमिक्स जीएमटी स्टोर करता है और उसके बाद उपयोगकर्ता स्तर पर जीएमटी के सापेक्ष आपके समय क्षेत्र को जानता है। फिर यह आपके समय क्षेत्र में आपको आइटम प्रदर्शित करता है।
बस सोचा कि मैं इसे वहां फेंक दूंगा क्योंकि यह एमएस में एक बहुत बड़ा समूह है और इस तरह उन्होंने इसे संभालने का फैसला किया।
मैं आमतौर पर यूनिक्स समय का उपयोग करता हूं। जरूरी नहीं कि भविष्य सुरक्षित है, लेकिन यह बहुत अच्छी तरह से काम करता है।
हमेशा जीएमटी (या यूटीसी) में स्टोर करें। वहां से किसी भी स्थानीय समय क्षेत्र मूल्य में कनवर्ट करना आसान है।
जोश पूरी तरह से ऊपर सही है, लेकिन मेरे पास व्याख्या करने के लिए एक सूक्ष्म चेतावनी है। यह एक मामला है जिसमें भविष्य की घटनाओं और समय क्षेत्र के बारे में कोई सही जवाब नहीं है।
दोहराने वाली नियुक्ति के मामले पर विचार करें। यह जीएमटी 0000 (सादगी के लिए) में होता है, जो सिडनी ऑस्ट्रेलिया में 1200 एनजेएसटी (न्यूजीलैंड मानक समय) और 1000 एईटी है।
जब एक क्षेत्र में डेलाइट सेविंग प्रभावी हो जाती है, तो नियुक्ति के लिए क्या होना चाहिए? इसे चाहिए:
1 ए। यदि TZ परिवर्तन के क्षेत्र में है, तो नियुक्ति का "स्वामी" ( इसे बुक किया गया है) तो उसी डेस्क घड़ी के समय (उदाहरण के लिए 10:00 बजे) पर रहने का प्रयास करें?
1 बी। TZ परिवर्तन तो कोई परिवर्तन
परिणाम अन्य बैठक प्रतिभागी के क्षेत्रों में से एक में है, तो: यह कारण मालिकों TZ परिवर्तन के लिए और सब लोग, अप्रत्याशित रूप से के लिए ले जाता है, है, लेकिन यह "10:00 बैठक रहता है "जहां तक मालिक का संबंध है।
'2। ऊपर के रूप में, लेकिन उलट दिया।
परिणाम: यह मीटिंग के मालिक के लिए चलता है (10am मीटिंग 9 बजे मीटिंग या वी/वी) बन जाती है, जिसे उम्मीद की जा सकती है लेकिन असुविधाजनक। यह अन्य उपस्थित लोगों के लिए उसी डेस्क घड़ी के समय पर रहता है जब तक कि वे अपने स्वयं के टीजेड संक्रमण से गुजरते हैं।
न तो सही है। दो नियुक्तियों के मामले पर विचार करें, एक व्यक्ति ए द्वारा बुक किया गया जो 10am स्थानीय समय पर होता है, दूसरा व्यक्ति व्यक्ति ए के साथ व्यक्ति ए के साथ 9 बजे होता है। यदि व्यक्ति ए और व्यक्ति बी अलग-अलग टीजेड में हैं तो एक डीएसटी परिवर्तन उन्हें आसानी से डबल बुक करने का कारण बन सकता है।
यदि आपका दिमाग इस बिंदु पर थोड़ा झुकता है तो मैं काफी समझता हूं।
इस उदाहरण के पीछे बिंदु यह है कि इन व्यवहारों में से किसी एक को सही तरीके से करने के लिए आपको स्थानीय समय के यूटीसी संस्करण को जानने की आवश्यकता नहीं है, लेकिन टीजेड (और ऑफसेट नहीं) जिसे मालिक ने बुक किया था । अन्यथा आपके पास विकल्प 2 लेने के अलावा कोई विकल्प नहीं है, चुपचाप, किसी को सूचित किए बिना कि चीजें बदल गई हैं क्योंकि जीएमटी के समय में बदलाव नहीं आया है और केवल प्रस्तुति बदलती है ... सही? (नहीं, यह जाल है, प्रस्तुतिकरण महत्वपूर्ण है जब आपकी 10am मीटिंग स्वयं ही चलती है)
मुझे इस अंतर्दृष्टि के लिए मेरे सहयोगी और मित्र जेसन पोलॉक को श्रेय देना होगा।his view here पढ़ें, और फॉलो-अप यहां iCal and VTIMEZONE पर चर्चा करें।
आउटलुक मोबाइल वास्तव में इस व्यवहार बग द्वारा भ्रमित हो जाता है। जब मैं सक्रिय क्षेत्र बदलता हूं तो फ़ोन अपॉइंटमेंट शिफ्ट होता है। – devstuff
@devstuff - जब आप एक अलग टाइमज़ोन का चयन करते हैं तो नियुक्तियों को स्थानांतरित किया जा रहा है। वर्णित किया जा रहा है कि टाइमज़ोन स्वयं बदल गया है (डेलाइट बचत में विधायी परिवर्तनों के कारण) और इसलिए उस समय क्षेत्र जिसमें डेटा मूल रूप से वर्णित था, अब मौजूद नहीं है। यानी समय एक ही समय क्षेत्र में स्थानांतरित हो गया है। – Mark
उत्तर हमेशा के रूप में "निर्भर करता है" है।
यह उस समय पर निर्भर करता है कि आप उस समय के साथ क्या वर्णन कर रहे हैं, और डेटा आपको कैसे प्रदान किया गया था। समय मूल्यों को संग्रहीत करने का निर्णय लेने की कुंजी यह तय कर रही है कि क्या आप टाइमज़ोन छोड़कर जानकारी खो रहे हैं, साथ ही साथ आपके उपयोगकर्ताओं को आश्चर्यचकित नहीं करते हैं।
यूटीसी टाइम_टी में डेटा संग्रहीत करने में निश्चित लाभ हैं - यह एक एकल int है, जो त्वरित सॉर्टिंग और आसान संग्रहण की इजाजत देता है।
:
मैं विशिष्ट क्षेत्रों में टूट जा रहा है के रूप में समस्या को देखने प्रत्येक पर:
के एक बार में एक पर नजर डालते हैं।
सिस्टम प्रदान किया गया: मैं यूटीसी में चल रहे सिस्टम की अनुशंसा करता हूं, फिर आप टाइमज़ोन समस्या से बचें और फिर, कोई सूचना हानि नहीं देखी जाती है (यह हमेशा यूटीसी है)।
ऐतिहासिक डेटा: ये सिस्टम लॉग फ़ाइलें, प्रक्रिया के आँकड़े, अनुरेखण, टिप्पणी दिनांकों/बार, आदि जैसी चीजों के डेटा को बदलने के लिए नहीं जा रहा है कर रहे हैं, और समय क्षेत्र वर्णनकर्ता पूर्वव्यापी प्रभाव से बदलने के लिए नहीं जा रहा है। इस प्रकार के डेटा के लिए, यूटीसी में दी गई जानकारी को संग्रहीत करके खोई गई कोई जानकारी नहीं है, चाहे वह टाइमज़ोन प्रदान की गई हो। इसलिए, टाइमज़ोन ड्रॉप करें।
भविष्य, दीर्घकालिक डेटा: ये ऐसी घटनाएं हैं जो भविष्य में कहीं भी पर्याप्त हैं या हो रही हैं। अगर उन्हें काफी देर तक रखा जाता है, तो टाइमज़ोन डिस्क्रिप्टरों को गारंटीकृत परिवर्तन की गारंटी दी जाती है। इस प्रकार के डेटा का एक अच्छा उदाहरण है, "साप्ताहिक प्रबंधन मीटिंग"। यह वह डेटा है जो एक बार दर्ज किया जाता है, और हमेशा के लिए काम करने की उम्मीद है। इन मानों के लिए, यह निर्धारित करना महत्वपूर्ण है कि यह सिस्टम या उपयोगकर्ता प्रदान किया गया है या नहीं। उपयोगकर्ता द्वारा प्रदान किए गए डेटा के लिए, समय निर्माता के टाइमज़ोन के साथ संग्रहीत किया जाना चाहिए, कुछ और जानकारी हानि के परिणामस्वरूप। टाइमज़ोन परिभाषा में परिवर्तन होने पर यह जानकारी हानि स्पष्ट हो जाती है और निर्माता को पूरी तरह से अलग मूल्य होने के रूप में प्रदर्शित किया जाता है!
जैसा कि बोवोस ने इंगित किया है, कुछ भ्रम है जहां निर्माता और दर्शक अलग-अलग समय क्षेत्र में हैं। उस स्थिति में, मैं उम्मीद करता हूं कि एप्लिकेशन यह इंगित करेगा कि किस समय के मूल्य उनके पिछले स्थानों से टाइमज़ोन शिफ्ट के कारण स्थानांतरित हो गए हैं।
भविष्य, लघु अवधि डेटा: यह वह डेटा है जो जल्दी से ऐतिहासिक बनने जा रहा है, या केवल थोड़े समय के लिए मान्य है। उदाहरण अंतराल टाइमर, रेटिंग संक्रमण आदि हो सकते हैं। इस डेटा के लिए, क्योंकि संभावना कम है कि परिभाषा मूल्य के निर्माण और समय के ऐतिहासिक होने के बीच बदल जाएगी, समय-समय पर छोड़ना संभव हो सकता है।हालांकि, मुझे पता चला है कि इन मूल्यों में "भविष्य, दीर्घकालिक डेटा" बनने की बुरी आदत है।
एक बार जब आप टाइमज़ोन स्टोर करने का निर्णय लेते हैं, तो इसे कैसे संग्रहीत किया जाता है इसके साथ सावधानी बरतनी चाहिए।
यदि आप ऑफ़सेट के रूप में टाइमज़ोन स्टोर करते हैं, तो टाइमज़ोन में परिवर्तन होने पर आप क्या करते हैं? क्या आप सिस्टम के माध्यम से जाते हैं और मौजूदा डेटा पर कंबल बदलते हैं? यदि आप करते हैं, तो अब आपने कोई ऐतिहासिक मान गलत बना दिया है। इस गलती के अच्छे उदाहरण ओरेकल और आईकल हैं। ओरेकल यूटीसी से ऑफसेट के रूप में टाइमज़ोन जानकारी स्टोर करता है, और आईकॉल में निर्माण समय क्षेत्र के लिए पूर्ण वर्णनकर्ता शामिल है।
यह आपके मौजूदा मानों को संशोधित किए बिना टाइमज़ोन की परिभाषा को बदलने की अनुमति देता है। यह सॉर्टिंग को और अधिक कठिन बना देता है, क्योंकि जेनरेट किए गए किसी भी इंडेक्स को अमान्य हो सकता है यदि टाइमज़ोन डेटा बदलता है।
यदि डेवलपर्स यूटीसी में सब कुछ स्टोर करना जारी रखते हैं, तो टाइमज़ोन के बावजूद, हम उन समस्याओं को देखना जारी रखेंगे जिन्हें हमने टाइमज़ोन परिवर्तनों के अंतिम बैच के साथ देखा है।
एक संगठन में, सचिवों को डेलाइट बचत तिथि से पहले अपनी टीमों के लिए कैलेंडर प्रिंट करना था, और फिर परिवर्तन के बाद उन्हें फिर से मुद्रित करना पड़ा। आखिरकार, उन्होंने दो की तुलना की और सभी नियुक्तियों को फिर से बनाया जो स्थानांतरित हो गए थे। बेशक, वे कई याद करते थे, और कई हफ्तों तक दर्द होता था जब तक कि पुराने डेलाइट बचत की तारीख तक नहीं पहुंच जाती थी और समय फिर से सही हो जाता था।
मैं टाइमज़ोन के साथ सबकुछ स्टोर करना पसंद करता हूं। ग्राहक निर्णय ले सकता है, इसे बाद में प्रस्तुत किया जाना चाहिए। कनवर्ट करने के लिए मेरी पसंदीदा लाइब्रेरी PostgreSQL-Database है।
जीएमटी/यूटीसी में सबकुछ संग्रह करना मेरे लिए सबसे तार्किक लगता है। फिर आप जो भी समय चाहते हैं उसमें दिनांक और समय दिखा सकते हैं।
कुछ ceveats:
सौभाग्य से, जब सही ढंग से इस्तेमाल किया, (.NET) दिनांक समय प्रकार आप और इस सब के लिए कैलेंडर आदि रखने बहुत आसान होना चाहिए के सभी रक्तमय विवरण का ख्याल जब आप जानते हैं कि यह कैसे काम करता है लेता है।
यहां एक नज़र डालें, डब्ल्यू 3 सी ने सवाल का जवाब देने के लिए एक उत्कृष्ट काम किया है।
उपयोग मामलों को देखें।
http://www.w3.org/TR/timezone/
ध्यान दें कि वे यूटीसी के रूप में भंडारण datetimes की सिफारिश नहीं जीएमटी, GMT डेलाइट सेविंग टाइम के अधीन है।
लेकिन, मान लें कि आपके पास आरक्षण प्रणाली है, और आप 3 पीएम पर डीएसटी के साथ एक टाइमज़ोन में एक कमरा बुक करते हैं। जब डीएसटी होता है, तो जीएमटी और मीटिंग रूम के टाइमज़ोन के बीच ऑफसेट एक घंटे तक बदल जाता है। अचानक बैठक अलग-अलग समय पर बुक की जाती है! –
कोई बात नहीं, मुझे यह नहीं पता था कि बैठक के पल के समय आप डीएसटी ऑफसेट में समय को बदल देंगे, इसलिए यह हमेशा सही ऑफसेट में होगा। –
नहीं, जीएमटी में डेलाइट बचत नहीं है। अगर हम pedantic हैं, तो न तो यूटीसी एक समय क्षेत्र है। जीएमटी ग्रीनविच में औसत सौर समय पर आधारित है। यूटीसी परमाणु समय (टीएआई) पर आधारित है जो पृथ्वी के सौर चरण के करीब रहने के लिए सेकेंड की पूर्णांक संख्या (लीप सेकेंड सोचें) द्वारा समायोजित किया जाता है, हालांकि वे 0.9 सेकंड तक भिन्न हो सकते हैं। आपको पृथ्वी के घूर्णन समय को सराहनीय रूप से बदलने के लिए कुछ सालों तक बैठक करना होगा, लेकिन यही कारण है कि जटिलता यहां मौजूद है। – mc0e