भंडारण में टाइमज़ोन हैंडलिंग?

जीएमटी में सबकुछ स्टोर करें?

एक एम्बेडेड ऑफसेट के साथ जिस तरह से दर्ज किया गया था उसे स्टोर करें?

गणित हर बार जब आप प्रस्तुत करते हैं?

"1 मिनट पहले" रिश्तेदार टाइम्स प्रदर्शित करें?

0
ro fr bn

12 उत्तर

व्यक्तिगत रूप से, मुझे जीएमटी में सबकुछ स्टोर न करने का कोई कारण नहीं दिख रहा है और फिर स्थानीय टाइमज़ोन उपयोगकर्ताओं को समय प्रदर्शित करने के लिए उपयोग करने के लिए उपयोग करता है।

यदि आप सापेक्ष समय प्रदर्शित करना चाहते हैं, तो आपको स्पष्ट रूप से समय की आवश्यकता है और अनुवाद करना है, लेकिन यदि आप अनुवाद करना चाहते हैं तो मुझे लगता है कि जीएमटी अभी भी आपका सबसे अच्छा विकल्प है।

0
जोड़ा
मुद्दा यह है कि संचार प्रक्रियाओं, लोगों के लिए समय सीमा के दौरान स्वचालित प्रक्रियाओं का उपयोग किस समय किया जाता है? क्या आप उपयोगकर्ताओं को टाइमज़ोन स्टोर करते हैं क्योंकि उन्होंने इसे तय किया है और सभी संचारों में इसका उपयोग किया है?
जोड़ा लेखक DevelopingChris, स्रोत

इसलिए मैंने एमएसएसक्यूएल सर्वर के साथ थोड़ा प्रयोग चलाया।

मैंने एक टेबल बनाया और वर्तमान स्थानीयकृत टाइमज़ोन (ऑस्ट्रेलिया) के साथ एक पंक्ति जोड़ा। तब मैंने अपना डेटाटाइम जीएमटी बनने के लिए बदल दिया और एक और पंक्ति जोड़ा।

यहां तक ​​कि उन पंक्तियों को लगभग 10 सेकंड के अलावा जोड़ा गया था, वे SQL सर्वर में दिखाई देते हैं क्योंकि वे 10 घंटे अलग हैं।

यदि कुछ और नहीं है, तो कम से कम मुझे यह बताता है कि मुझे तारीखों को एक संयोग से संग्रहीत करना चाहिए, जो मेरे लिए, जीएमटी के रूप में उन्हें संग्रहीत करने के लिए तर्क में वजन बढ़ाता है।

0
जोड़ा
उन्हें एक एम्बेडेड ऑफ़सेट के साथ संग्रहीत करना, इसका मतलब भी हो सकता है, 2 कॉलम, जीएमटी समय, और ऑफसेट चुने गए व्यक्ति, स्वचालित रूप से एक वर्ग एसकल्स्सेवर या क्लाइंट मशीन नहीं।
जोड़ा लेखक DevelopingChris, स्रोत

आपको यूटीसी में स्टोर करना होगा - यदि आप नहीं करते हैं, तो डेलाइट सेविंग्स जैसी चीजों के दौरान आपकी ऐतिहासिक रिपोर्टिंग और व्यवहार ... मजेदार है। जीएमटी एक स्थानीय समय है, यूटीसी के सापेक्ष डेलाइट सेविंग्स (जो नहीं है) के अधीन है।

यदि आप स्थानीय समय संग्रहित कर रहे हैं तो विभिन्न समय-क्षेत्रों में उपयोगकर्ताओं को प्रस्तुतिकरण वास्तविक बेस्टर्ड हो सकता है। यदि आपका कच्चा डेटा यूटीसी में है तो स्थानीय में समायोजित करना आसान है - बस अपने उपयोगकर्ता का ऑफसेट जोड़ें और आप कर चुके हैं!

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

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

अब, प्रदर्शित करने के लिए: निश्चित रूप से, आप "3 मिनट पहले" चीज कर सकते हैं, लेकिन केवल अगर आप यूटीसी स्टोर करते हैं - अन्यथा, विभिन्न टाइमज़ोन में दर्ज डेटा "-4 घंटे पहले" के रूप में प्रदर्शित होने वाली चीजें करने जा रहा है, जो होगा अजीब लोग बाहर। यदि आप वास्तविक समय प्रदर्शित करने जा रहे हैं, तो लोग इसे अपने स्थानीय समय में रखना पसंद करते हैं - और यदि डेटा कई टाइमज़ोन में दर्ज किया जा रहा है तो आप केवल यूटीसी को संग्रहीत करते समय आसानी से ऐसा कर सकते हैं।

0
जोड़ा
लेकिन, मान लें कि आपके पास आरक्षण प्रणाली है, और आप 3 पीएम पर डीएसटी के साथ एक टाइमज़ोन में एक कमरा बुक करते हैं। जब डीएसटी होता है, तो जीएमटी और मीटिंग रूम के टाइमज़ोन के बीच ऑफसेट एक घंटे तक बदल जाता है। अचानक बैठक अलग-अलग समय पर बुक की जाती है!
जोड़ा लेखक Joeri Sebrechts, स्रोत
कोई बात नहीं, मुझे पता नहीं चला कि बैठक के पल के समय आप डीएसटी ऑफसेट में समय को बदल देंगे, इसलिए यह हमेशा सही ऑफसेट में होगा।
जोड़ा लेखक Joeri Sebrechts, स्रोत
नहीं, जीएमटी में डेलाइट बचत नहीं है। अगर हम pedantic हैं, तो न तो यूटीसी एक समय क्षेत्र है। जीएमटी ग्रीनविच में औसत सौर समय पर आधारित है। यूटीसी परमाणु समय (टीएआई) पर आधारित है जो पृथ्वी के सौर चरण के करीब रहने के लिए सेकेंड की पूर्णांक संख्या (लीप सेकेंड सोचें) द्वारा समायोजित किया जाता है, हालांकि वे 0.9 सेकंड तक भिन्न हो सकते हैं। आपको पृथ्वी के घूर्णन समय को सराहनीय रूप से बदलने के लिए कुछ सालों तक बैठक करना होगा, लेकिन यही कारण है कि जटिलता यहां मौजूद है।
जोड़ा लेखक mc0e, स्रोत

एमएस डायनेमिक्स जीएमटी स्टोर करता है और उसके बाद उपयोगकर्ता स्तर पर जीएमटी के सापेक्ष आपके समय क्षेत्र को जानता है। फिर यह आपके समय क्षेत्र में आपको आइटम प्रदर्शित करता है।

बस सोचा कि मैं इसे वहां फेंक दूंगा क्योंकि यह एमएस में एक बहुत बड़ा समूह है और इस तरह उन्होंने इसे संभालने का फैसला किया।

0
जोड़ा

मैं आमतौर पर यूनिक्स समय का उपयोग करता हूं। जरूरी नहीं कि भविष्य सुरक्षित है, लेकिन यह बहुत अच्छी तरह से काम करता है।

0
जोड़ा

मुझे जीएमटी में स्टोर करना पसंद है और केवल रिश्तेदार दिखाना ("लगभग 10 सेकंड पहले", "5 महीने पहले")। उपयोगकर्ताओं को अधिकांश उपयोग मामलों के लिए वास्तविक टाइमस्टैम्प देखने की आवश्यकता नहीं है।

निश्चित रूप से अपवाद हैं, और एक व्यक्तिगत एप्लिकेशन में उनमें से कई हो सकते हैं, इसलिए यह 'एक-सही-रास्ता' उत्तर नहीं हो सकता है। जिन चीजों को मजबूत लेखापरीक्षा क्षमता (जैसे मतदान) की आवश्यकता होती है, और सिस्टम जहां समय व्याख्यान (खगोल विज्ञान, वैज्ञानिक अनुसंधान) के क्षेत्र का हिस्सा है, उपयोगकर्ता को दिखाए जाने के लिए सही टाइमस्टैम्प की मांग कर सकता है।

अधिकांश ऐप्स, हालांकि, एक सापेक्ष सापेक्ष समय के साथ समझना आसान है।

0
जोड़ा

हमेशा जीएमटी (या यूटीसी) में स्टोर करें। वहां से किसी भी स्थानीय समय क्षेत्र मूल्य में कनवर्ट करना आसान है।

0
जोड़ा

जोश ऊपर से बिल्कुल सही है, लेकिन मेरे पास व्याख्या करने के लिए एक सूक्ष्म चेतावनी है। यह एक मामला है जिसमें भविष्य की घटनाओं और समय क्षेत्र के बारे में कोई सही जवाब नहीं है।

दोहराने की नियुक्ति के मामले पर विचार करें। यह जीएमटी 0000 (सादगी के लिए) में होता है, जो सिडनी ऑस्ट्रेलिया में 1200 एनजेएसटी (न्यूजीलैंड मानक समय) और 1000 एईटी है।

जब एक क्षेत्र में डेलाइट सेविंग प्रभावी होती है, तो नियुक्ति के लिए क्या होना चाहिए? इसे होना चाहिए:

1 क। यदि टीजेड परिवर्तन क्षेत्र में है     नियुक्ति का "मालिक" (कौन     इसे बुक किया) फिर रहने का प्रयास करें     एक ही डेस्क घड़ी का समय (जैसे 10:00 बजे)?
 1b। अगर     टीजेड परिवर्तन दूसरे में से एक में है     बैठक में उपस्थिति के क्षेत्र तो नहीं     परिवर्तन

नतीजे: यह चलता है     हर कोई, अप्रत्याशित रूप से, के कारण     मालिकों TZ परिवर्तन, लेकिन यह रहता है     जहां तक ​​10 बजे बैठक "     मालिक चिंतित है।

'2। ऊपर के रूप में, लेकिन उलट दिया।

नतीजे: यह बैठक के मालिक के लिए चलता है (10 बजे की बैठक 9 बजे की बैठक हो जाती है, या वी/वी), जिसे उम्मीद की जा सकती है लेकिन असुविधाजनक। यह अन्य उपस्थित लोगों के लिए उसी डेस्क घड़ी के समय पर रहता है जब तक कि वे अपने स्वयं के टीजेड संक्रमण से गुजरते हैं।

न तो सही है। दो नियुक्तियों के मामले पर विचार करें, एक व्यक्ति ए द्वारा बुक किया गया जो 10am स्थानीय समय पर होता है, दूसरा व्यक्ति व्यक्ति ए के साथ व्यक्ति ए के साथ 9 बजे होता है। यदि व्यक्ति ए और व्यक्ति बी अलग-अलग टीजेड में हैं तो एक डीएसटी परिवर्तन उन्हें आसानी से डबल बुक करने का कारण बन सकता है।

यदि इस बिंदु पर आपका दिमाग थोड़ा झुका हुआ है तो मैं काफी समझता हूं।

इस उदाहरण के पीछे बिंदु यह है कि इन व्यवहारों में से किसी एक को सही तरीके से करने के लिए आपको स्थानीय समय के यूटीसी संस्करण को नहीं जानना चाहिए, लेकिन टीजेड (और ऑफ़सेट नहीं) जिसे मालिक ने बुक किया था। अन्यथा आपके पास विकल्प 2 लेने के अलावा कोई विकल्प नहीं है, चुपचाप, किसी को सूचित किए बिना कि चीजें बदल गई हैं क्योंकि जीएमटी के समय में बदलाव नहीं आया है और केवल प्रस्तुति बदलती है ... सही? (नहीं, यह जाल है, प्रस्तुतिकरण मायने रखता है जब आपकी 10am मीटिंग स्वयं ही चलती है)

मुझे इस अंतर्दृष्टि के लिए अपने सहयोगी और दोस्त जेसन पोलॉक को श्रेय देना है। यहां उसका विचार पढ़ें, और अनुवर्ती iCal और VTIMEZONE पर चर्चा यहां।

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

उत्तर, हमेशा के रूप में, "निर्भर करता है" है।

यह उस समय पर निर्भर करता है कि आप उस समय के साथ क्या वर्णन कर रहे हैं, और डेटा आपको कैसे प्रदान किया गया था। समय मूल्यों को स्टोर करने का निर्णय लेने की कुंजी यह तय कर रही है कि क्या आप टाइमज़ोन छोड़कर जानकारी खो रहे हैं, साथ ही साथ अपने उपयोगकर्ताओं को आश्चर्यचकित नहीं करते हैं।

यूटीसी टाइम_टी में डेटा संग्रहीत करने में निश्चित लाभ हैं - यह एक सिंगल इंट है, जो त्वरित सॉर्टिंग और आसान स्टोरेज की इजाजत देता है।

मैं समस्या को विशिष्ट क्षेत्रों में विभाजित करने के रूप में देखता हूं:

  1. ऐतिहासिक डेटा
  2. भविष्य, लघु अवधि डेटा
  3. भविष्य, दीर्घकालिक डेटा

प्रत्येक पर निम्नलिखित उपखंडों के साथ:

  1. सिस्टम प्रदान किया गया
  2. उपयोगकर्ता प्रदान किया गया

आइए उन्हें एक समय में देखें।

System Provided: I would recommend running systems in UTC, then you avoid the timezone problem and again, no information loss is seen (it's always UTC).

Historical Data: These are things like system log files, process statistics, tracing, comment dates/times, etc. The data isn't going to change, and the timezone descriptor isn't going to change retroactively. For this type of data, there is no information lost by storing the information in UTC regardless of the timezone it was provided in. So, drop the timezone.

Future, Long Term Data: These are events that are either far enough in the future or will keep happening. If they are kept around long enough, the timezone descriptors are guaranteed change. A good example of this type of data is, "The Weekly Management Meeting". This is data that is entered once, and expected to keep working into perpetuity. For these values, it is important to determine if it is system or user provided. For user-provided data, the time should be stored with the creator's timezone, anything else results in information loss. This information loss becomes apparent when the timezone definition changes and the time is displayed to the creator as having an entirely different value!

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

Future, Short Term Data: This is data that is quickly going to become historical, or is only valid for a short period of time. Examples could be interval timers, rating transitions, etc. For this data, since the likelihood is low that the definition will change between the creation of the value and the time it becomes historical, it might be possible to get away with dropping the timezone. However, I have found that these values have a bad habit of becoming "Future, Long Term Data".

एक बार जब आप टाइमज़ोन स्टोर करने का निर्णय ले लेते हैं, तो इसे कैसे रखा जाता है इसके साथ सावधानी बरतनी चाहिए।

  • टाइमज़ोन को ऑफ़सेट, या पूर्ण वर्णनकर्ता के रूप में संग्रहीत न करें।

यदि आप ऑफ़सेट के रूप में टाइमज़ोन स्टोर करते हैं, तो टाइमज़ोन बदलते समय आप क्या करते हैं? क्या आप सिस्टम के माध्यम से जाते हैं और मौजूदा डेटा पर कंबल बदलते हैं? यदि आप करते हैं, तो अब आपने कोई ऐतिहासिक मान गलत बना दिया है। इस गलती के अच्छे उदाहरण ओरेकल और आईकल हैं। ओरेकल यूटीसी से ऑफसेट के रूप में टाइमज़ोन जानकारी स्टोर करता है, और आईकॉल में निर्माण समय क्षेत्र के लिए पूर्ण वर्णनकर्ता शामिल है।

  • इसे नाम के रूप में स्टोर करें।

यह आपके मौजूदा मानों को संशोधित किए बिना टाइमज़ोन की परिभाषा को बदलने की अनुमति देता है। यह सॉर्टिंग को और अधिक कठिन बना देता है, क्योंकि जेनरेट किए गए किसी भी इंडेक्स को अमान्य हो सकता है यदि टाइमज़ोन डेटा बदलता है।

यदि डेवलपर्स यूटीसी में सब कुछ स्टोर करना जारी रखते हैं, चाहे टाइमज़ोन के बावजूद, हम उन समस्याओं को देखना जारी रखेंगे जिन्हें हमने टाइमज़ोन परिवर्तनों के अंतिम बैच के साथ देखा है।

एक संगठन में, सचिवों को डेलाइट बचत तिथि से पहले अपनी टीमों के लिए कैलेंडर प्रिंट करना था, और फिर परिवर्तन के बाद उन्हें फिर से मुद्रित करना पड़ा। आखिरकार, उन्होंने दो की तुलना की और सभी नियुक्तियों को फिर से बनाया जो स्थानांतरित हो गए थे। बेशक, वे कई याद करते थे, और कई हफ्तों तक दर्द होता था जब तक कि पुराने डेलाइट बचत की तारीख तक नहीं पहुंच जाती थी और समय फिर से सही हो जाता था।

0
जोड़ा

मैं टाइमज़ोन के साथ सबकुछ स्टोर करना पसंद करता हूं। ग्राहक तय कर सकता है, इसे बाद में प्रस्तुत किया जाना चाहिए। कनवर्ट करने के लिए मेरी पसंदीदा लाइब्रेरी PostgreSQL-Database है।

0
जोड़ा

जीएमटी/यूटीसी में सब कुछ संग्रह करना मेरे लिए सबसे तार्किक लगता है। फिर आप जो भी समय चाहते हैं उसमें दिनांक और समय दिखा सकते हैं।

कुछ छतें:

  1. यदि एक समय केवल एक के रूप में निर्दिष्ट है दीवार घड़ी का समय और वह है अग्रणी प्रतिनिधित्व, तो यह है एक बिल्कुल निर्दिष्ट समय नहीं है। आपको इसे परिवर्तित करना चाहिए (और नहीं कर सकता) किसी भी जीएमटी प्रतिनिधित्व में। E.G. 9:00 हर सुबह सुबह। दूसरे शब्दों में: यह कोई (तारीख) समय नहीं है।
  2. यदि आप     भविष्य की तारीख और समय बचाएं     नियुक्ति, आप का उपयोग करना चाहिए     इनपुट द्वारा निर्दिष्ट जीएमटी ऑफसेट     टाइमज़ोन और समय में पल     खुद । तो अगर यह एक नियुक्ति है     ग्रीष्म ऋतु में सर्दी में बना     पश्चिमी यूरोप, यह +2: 00 है,     हालांकि सामान्य (शीतकालीन समय)     ऑफ़सेट +1: 00 है। यह हल करेगा     कैलेंडर समस्या है कि Bwooce     उल्लेख किया।
  3. बेशक, वही जो सही उपयोग करने पर लागू होता है जीएमटी में कनवर्ट करते समय ऑफसेट एक पर वापस कनवर्ट करते समय लागू होता है किसी भी विशेष तिथि और समय समय क्षेत्र।

सौभाग्य से, जब सही तरीके से उपयोग किया जाता है, तो (.NET) डेटटाइम प्रकार आपके लिए कैलेंडर्स इत्यादि रखने के सभी गौरी विवरणों का ख्याल रखता है और यह सब बहुत आसान होना चाहिए जब आप जानते हैं कि यह कैसे काम करता है।

0
जोड़ा

यहां एक नज़र डालें, डब्ल्यू 3 सी ने सवाल का जवाब देने के लिए एक उत्कृष्ट काम किया है।

उपयोग के मामलों को देखो।

http://www.w3.org/TR/timezone/

ध्यान दें कि वे यूटीसी जीएमटी के रूप में डेटटाइम्स को स्टोर करने की सलाह देते हैं, जीएमटी डेलाइट सेविंग टाइम के अधीन है।

0
जोड़ा