दिनांक समय (UTC) को संग्रहीत करना दिनांक DateOffset को संग्रहीत करना

Question

मेरे पास आमतौर पर एक "इंटरसेप्टर" होता है, जो डेटाबेस से पढ़ने / लिखने से ठीक पहले डेटाइम रूपांतरण (यूटीसी से स्थानीय समय और स्थानीय समय से यूटीसी तक) करता है, इसलिए मैं इसका उपयोग कर सकता हूं DateTime.Now चिंता के दौरान पूरे सिस्टम में (व्युत्पत्तियों और तुलनाओं) का समय क्षेत्र के बारे में।

कंप्यूटर के बीच क्रमांकन और गतिशील डेटा के बारे में, परेशान होने की आवश्यकता नहीं है, क्योंकि डेटाटाइम हमेशा यूटीसी होता है।

क्या मुझे UTC प्रारूप में अपनी तिथियाँ (एसक्यूएल 2008 - डेटाइम) का भंडारण जारी रखना चाहिए या क्या मुझे इसका उपयोग करके स्टोर करना चाहिए DateTimeOffset(एसक्यूएल 2008 - डेटाइमऑफ़सेट)?

डेटाबेस में UTC तिथियाँ (डेटाटाइम प्रकार) इतने लंबे समय से काम कर रही हैं और इसे क्यों जाना जाता है? क्या फायदे हैं?

मैंने पहले ही इस तरह के लेखों को देखा है , लेकिन मैं 100% आश्वस्त नहीं हूं। कोई विचार?

Comments

संबंधित प्रश्न: stackoverflow.com/questions/2532729/…

— Oded

इसे भी देखें: DateTime बनाम DateTimeOffset - .Net के लिए लिखा गया है, लेकिन अवधारणात्मक रूप से SQL पर भी लागू होता है।

— मैट जॉनसन-पिंट

Answer 1

एक बहुत बड़ा अंतर है, जहाँ आप अकेले UTC का उपयोग नहीं कर सकते।

• यदि आपके पास इस तरह का परिदृश्य है

  • एक सर्वर और कई क्लाइंट (सभी भौगोलिक रूप से अलग-अलग टाइमज़ोन में )
  • ग्राहक डेटाटाइम जानकारी के साथ कुछ डेटा बनाते हैं
  • ग्राहक इसे केंद्रीय सर्वर पर संग्रहीत करते हैं

• फिर:

  • डेटाइमऑफ़सेट स्टोर ग्राहक का स्थानीय समय और ALSO यूटीसी समय की भरपाई करता है
  • सभी ग्राहक सभी डेटा के UTC समय को जानते हैं और उस स्थान पर स्थानीय समय भी है जहाँ सूचना उत्पन्न हुई थी

• परंतु:

  • UTC डेटाटाइम केवल UTC डेटाटाइम संग्रहीत करता है , इसलिए आपके पास क्लाइंट स्थान पर डेटा की उत्पत्ति के समय के बारे में जानकारी नहीं है
  • अन्य ग्राहकों को उस स्थान का स्थानीय समय नहीं पता है, जहां से डेटाटाइम जानकारी आई थी
  • अन्य ग्राहक केवल डेटाबेस से अपने स्थानीय समय की गणना कर सकते हैं (यूटीसी समय का उपयोग करके) ग्राहक के स्थानीय समय की नहीं, जहां डेटा की उत्पत्ति हुई है

सरल उदाहरण है फ्लाइट टिकट रिजर्वेशन सिस्टम ... फ्लाइट टिकट में 2 बार होना चाहिए: - "टेक ऑफ" टाइम ("फ्रॉम" सिटी "के टाइमज़ोन में) -" लैंडिंग "टाइम (" डेस्टिनेशन "सिटी के टाइमज़ोन में)

Comments

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

— एंड्रयू बैकर

आपने कहा "डेटाइमऑफ़सेट स्टोर UTC समय और ALSO क्लाइंट के स्थानीय समय के लिए ऑफसेट", लेकिन डेटाटाइमऑफ़सेट LOCAL समय + ऑफसेट, या UTC समय + ऑफसेट समान +0 को संग्रहीत करता है।

— सेरही किसली 12

हालाँकि, आप केवल DTO को DT को कास्ट कर सकते हैं क्योंकि DT बेस UTC है (हालाँकि यह डेटाबेस का उपयोग करने वाले सभी के लिए एक अतिरिक्त कदम होगा, और यकीनन केवल UTC समय का उपयोग करने की तुलना में कोई सरल नहीं है)

— iliketocode

DateTmeOffset स्टोर "लोकल टाइम और UTC ऑफ़सेट" की तरह लगता है, न कि "UTC टाइम और UTC ऑफ़सेट"। यदि आप डेटटाइम के लिए काम करते हैं या किसी भी तिथि कार्यों का उपयोग करते हैं, तो आपको स्थानीय दिनांक और समय घटक मिलते हैं।

— त्रिनको

" सभी क्लाइंट सभी डेटा के UTC समय को जानते हैं और उस स्थान पर स्थानीय समय भी है जहाँ जानकारी उत्पन्न हुई है" हालांकि दिनांक फ़ील्ड के भाग के रूप में संग्रहीत करना उस मामले में अप्राकृतिक लगता है। उपयोग का मामला क्या है - अर्थात, आप UTC का उपयोग क्यों नहीं करेंगे और ऑफ़सेट को InputLocationId(या समान सामान्यीकृत इकाई को) बाहर निकालेंगे । इसमें गणना शामिल होगी (हैलो, अपवाद ... विशेष रूप से आप, इंडियाना ), लेकिन यह अभी भी एक निर्धारक प्रक्रिया है - और फिर ऐप के डेटाइम लॉजिक का संतुलन सीधा है।

— रफिन

Answer 2

आप सभी ऐतिहासिक समय के लिए यूटीसी का उपयोग करने के लिए बिल्कुल सही हैं (अर्थात रिकॉर्डिंग की गई घटनाएं)। हमेशा यूटीसी से स्थानीय समय पर जाना संभव है लेकिन हमेशा दूसरे तरीके के बारे में नहीं।

स्थानीय समय का उपयोग कब करें? इस प्रश्न का उत्तर दो:

यदि सरकार अचानक दिन के उजाले की बचत को बदलने का निर्णय लेती है, तो क्या आप इस डेटा को बदलना चाहेंगे?

केवल स्थानीय समय ही स्टोर करें यदि उत्तर "हां" है। जाहिर है कि यह केवल भविष्य की तारीखों के लिए होगा, और आमतौर पर केवल उन तारीखों के लिए जो किसी तरह से लोगों को प्रभावित करते हैं।

क्यों एक समय क्षेत्र / ऑफसेट स्टोर?

सबसे पहले, यदि आप यह रिकॉर्ड करना चाहते हैं कि उपयोगकर्ता ने कार्रवाई को अंजाम दिया था, तो आप क्या कर रहे हैं, आप शायद सबसे अच्छा कर रहे हैं, यानी लॉगिन पर उस उपयोगकर्ता के लिए स्थान और समय क्षेत्र रिकॉर्ड करें।

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

Comments

Windows UTC स्थानीय समय में रूपांतरण को ध्यान में रखता है जब दिन की बचत का समय ऐतिहासिक तिथियों के लिए बदल जाता है। मैं नहीं देखता कि आप उस स्थिति में स्थानीय समय क्यों संग्रहीत करना चाहते हैं।

— 13

@Jamiegs विंडोज केवल ऐतिहासिक रूप से "अंतिम ऐतिहासिक जानकारी" जानता है (जैसा कि .NET डेटटाइम प्रलेखन में उल्लेखित है / नोट किया गया है)। यह व्यापक नहीं है।

बेशक, आपको घटना के स्थान को संग्रहीत करना होगा, अन्यथा आप यह नहीं कह सकते हैं कि "स्थानीय समय" क्या हुआ था।

— keuleJ

Answer 3

DATETIMEOFFSET आपको एक क्षेत्र में स्थानीय समय और UTC समय संग्रहीत करने की क्षमता देता है।

यह किसी भी तरह से प्रदर्शन के लिए डेटा को संसाधित करने की आवश्यकता के बिना स्थानीय या यूटीसी समय में बहुत सरल और कुशल रिपोर्टिंग के लिए अनुमति देता है।

ये दो सबसे आम आवश्यकताएं हैं - स्थानीय रिपोर्टों के लिए स्थानीय समय और समूह रिपोर्टों के लिए यूटीसी समय।

DATETIMEOFFSET के DATETIME भाग में स्थानीय समय संग्रहीत किया जाता है और UTC से OFFSET को OFFSET भाग में संग्रहीत किया जाता है, इस प्रकार रूपांतरण सरल है और, क्योंकि डेटा के आने के समय का कोई ज्ञान नहीं होना चाहिए, यह सभी डेटाबेस स्तर पर किया जा सकता है ।

यदि आपको मिलीसेकंड तक समय की आवश्यकता नहीं है, जैसे कि केवल मिनट या सेकंड के लिए, आप DATETIMEOFFSET (0) का उपयोग कर सकते हैं। DATETIMEOFFSET फ़ील्ड को केवल 8 बाइट्स संग्रहण की आवश्यकता होगी - DATETIME के ​​समान।

इसलिए UTC DATETIME के ​​बजाय DATETIMEOFFSET का उपयोग करना रिपोर्टिंग के लिए अधिक लचीलापन, दक्षता और सरलता देता है।

Comments

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

— त्रिनको

@ ट्रायनको क्या आप समझा सकते हैं कि आपका क्या मतलब है? उदाहरण?

— १६:१६ को