टाइम ज़ोन के बिना टाइमस्टैम्प का उपयोग करने के लिए एक वैध उपयोग मामला क्या है?

Question

के बीच के मतभेदों पर एक लंबा और काफी स्पष्ट जवाब है

• TIMESTAMP WITH TIME ZONE -वसेस-
• TIMESTAMP WITHOUT TIME ZONE

इस SO पोस्ट में उपलब्ध है । क्या मैं जानना चाहूंगा है: वहाँ वास्तव में उपयोग करने के लिए किसी भी वैध उपयोग के मामलों रहे हैं TIMESTAMP WITHOUT TIME ZONEया यह एक विरोधी पैटर्न माना जाना चाहिए।

Comments

यह सवाल बंद होने का जोखिम "मुख्य रूप से राय आधारित" होने पर चलता है। मैंने नीचे अपने उत्तर में कुछ वस्तुनिष्ठ विचार देने की कोशिश की है।

— कॉलिन की टी हार्ट

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

— तुलसी बोर्क

Answer 1

यह स्थानों के एक बहुत में कहा गया है, लेकिन मैं इसके लायक हमेशा उल्लेख है जब हम तुलना लगता है timestamp with time zoneके साथ timestamp without time zoneप्रकार: दुकान नहीं है समय क्षेत्र टाइमस्टैम्प के साथ जानकारी । डॉक्स में बताए अनुसार , UTC टाइम ज़ोन में हर डेटा को स्टोर करना है :timestamp WITH time zone

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

यह उन timestamp WITHOUT time zoneस्थितियों में उपयोग करने के लिए कुछ के लिए वैध माना जाता है जहां (1) सब कुछ एक ही समय क्षेत्र में है या (2) आवेदन परत समय क्षेत्र को संभालती है और बस एक निश्चित समय क्षेत्र (आमतौर पर यूटीसी) में सब कुछ स्टोर करती है। लेकिन इसे एक एंटी-पैटर्न भी माना जाता है, सरल क्योंकि (1) के लिए सही समाधान टाइमज़ोन सेटिंग को सिस्टम के लिए दिए गए वन टाइमज़ोन में कॉन्फ़िगर करना है और (2) पहले से ही हल है, क्योंकि PostgreSQL पहले से ही सब कुछ उसी टाइमज़ोन पर स्टोर करता है (यु.टी. सी)।

अब, उन दो डाउन के साथ, मैं उपयोग करने के लिए केवल एक अच्छे कारण के साथ आ सकता हूं timestamp WITHOUT time zone। यही कारण है कि जब आप भविष्य में घटनाओं को संग्रहीत करना चाहते हैं और उस समय के लिए किसी प्रकार का अलर्ट ट्रिगर करना होगा। timestamp WITH time zoneयदि इसके लिए अच्छा हो सकता है , और केवल तभी, समय क्षेत्र के बारे में क्षेत्र के कानूनों द्वारा परिभाषित नियम कभी नहीं बदले। सबसे आम नियम जो परिवर्तन को गोद लेने या दिन की रोशनी की बचत समय (डीएसटी) के बारे में है।

उदाहरण के लिए, कल्पना करें कि आप पर हैं, मान लें कि 2013-06-15(अभी तक डीएसटी में नहीं) कुछ घटना 2013-01-15 10:00(जो पहले से डीएसटी में होगी), और 2013-06-15आपके क्षेत्र में डीएसटी को अपनाने के लिए नामित किया गया था; लेकिन, कुछ समय बाद, सरकार ने नियम बदल दिया और कहा कि आपका क्षेत्र अब DST का उपयोग नहीं करेगा, और अचानक आपका निर्धारित समय 2013-01-15 11:00(इसके बजाय 10:00) बन जाता है , यदि आप उपयोग करते हैं timestamp WITH time zone, और अपने TZ कॉन्फ़िगरेशन को अद्यतित रखते हैं। बेशक आप यह भी देख सकते हैं कि ऐसे मामलों का इलाज समय क्षेत्र के साथ भी संभव है, यदि आप अपनी रुचि के क्षेत्रों / समयसीमाओं में नियम परिवर्तन का ट्रैक रखते हैं, और प्रभावित रिकॉर्ड को अपडेट करते हैं।

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

उस सब के साथ, मैंने कहा, मेरा केवल एक और सुझाव है। यदि आपके पास अलग-अलग टाइमज़ोन पर उपयोगकर्ता, लॉग या कुछ भी हैं, तो वे उस समय का संग्रह करें जो वे कहीं से आ रहे हैं और चुनें और उपयोग करें timestamp with time zone। इस तरह से आप विभिन्न स्रोतों के लिए एक-दूसरे के करीब होने वाली (1) घटनाओं को पार कर सकते हैं (उनके टाइमज़ोन से स्वतंत्र) और (2) मूल समय (घड़ी का समय) दिखाते हैं कि घटना हुई है।

Comments

आप कह रहे हैं: "मैं टाइम ज़ोन के साथ टाइमस्टैम्प का उपयोग करने के केवल एक अच्छे कारण के साथ आ सकता हूं"। यदि वह टाइपो नहीं है, तो क्या आप वास्तव में सुझाव दे रहे हैं कि "टाइम ज़ोन के बिना टाइमस्टैम्प" वास्तव में "टाइम ज़ोन के साथ टाइमस्टैम्प" की तुलना में गलतफहमी पैदा करने के लिए अधिक उपयुक्त / कम प्रवण है? वह मुझे सहज लगता है।

— मार्कस जूनियस ब्रूटस

@MarcusJuniusBrutus, इसके बारे में क्षमा करें, यह वास्तव में एक टाइपो था और मुझे लगा कि इसके बारे में दूसरा तरीका है ... संपादित उत्तर की जाँच करें।

— माथेउसल

codeblog.jonskeet.uk/2019/03/27/… गहराई से इस भविष्य के घटना-नियमों-नियमों-परिवर्तन परिदृश्य (समान सहमति के साथ) पर चर्चा करता है

— बेनी चेर्नियव्स्की-पास्किन

Answer 2

हाँ। के लिए उपयोग-मामले हैं TIMESTAMP WITHOUT TIME ZONE।

• सामान्य व्यावसायिक एप्लिकेशन में इस प्रकार का उपयोग केवल इसके लिए किया जाएगा:
  • भविष्य की नियुक्तियों की बुकिंग
  • विभिन्न समय क्षेत्रों में एक ही समय के दिन का प्रतिनिधित्व करना, जैसे कि टोक्यो में 23 तारीख को दोपहर और पेरिस में (दो अलग-अलग क्षणों के अलावा, एक ही समय के दिन)
• ट्रैकिंग क्षणों के लिए, समयरेखा पर विशिष्ट बिंदु, हमेशा उपयोग करें TIMESTAMP WITH TIME ZONE, नहीं WITHOUT।

TIMESTAMP WITHOUT TIME ZONEमान हैं नहीं समय, पर एक बिंदु नहीं वास्तविक क्षणों। वे संभावित क्षणों के बारे में एक मोटे विचार का प्रतिनिधित्व करते हैं, समय रेखा पर संभव बिंदुओं के बारे में 26-27 घंटे (दुनिया भर में समय क्षेत्र की सीमा) के साथ। जब तक आप टाइम ज़ोन या ऑफ़सेट-यूटीसी लागू नहीं करते हैं, तब तक उनका कोई वास्तविक अर्थ नहीं है ।

Ex: क्रिसमस

उदाहरण के लिए, मान लें कि आपको छुट्टियों / पवित्र दिनों की शुरुआत रिकॉर्ड करने की आवश्यकता है।

Table: holiday_

Column: year_         Type: SMALLINT
Column: description_  Type: VARCHAR
Column: start_        Type: TIMESTAMP WITHOUT TIME ZONE

इस तथ्य को दर्ज करने के लिए कि इस वर्ष 25 दिसंबर की आधी रात के बाद क्रिसमस शुरू होता है, हमें 2016-12-25 00:00:00बिना किसी समय क्षेत्र के कहने की आवश्यकता है । सांता के दिन के शुरू में वह आधी रात के बाद ऑकलैंड एनजेड का दौरा करता है, क्योंकि यह दुनिया के सबसे पुराने मिडनाइट्स में से एक है। फिर वह पश्चिम की ओर अपने तरीके से काम करता है, जैसा कि अगली आधी रात को होता है, जल्द ही फिलीपींस पहुंचता है। फिर बारहसिंगा एक दिशा में आगे बढ़ता है, आधी रात को भारत पहुंचता है जो कि ऑकलैंड में आधी रात के कई घंटे बाद होता है। बहुत बाद में अभी भी पेरिस FR में आधी रात है, और अभी भी बाद में मॉन्ट्रियल CA में आधी रात है। सांता द्वारा की जाने वाली ये सभी यात्राएं अलग-अलग समय पर होती हैं , फिर भी सभी आधी रात के तुरंत बाद, प्रत्येक इलाके के अपने मध्य रात्रि में होती हैं।

तो 2016-12-25 00:00:00क्रिसमस की शुरुआत के रूप में किसी भी समय क्षेत्र के बिना रिकॉर्डिंग जानकारीपूर्ण और वैध है, लेकिन केवल अस्पष्ट। जब तक आप "ऑकलैंड में क्रिसमस" या "मॉन्ट्रियल में क्रिसमस" नहीं कहते हैं, तब तक हमारे पास समय में एक विशिष्ट क्षण नहीं है। यदि आप वास्तविक समय को हर बार रिकॉर्ड कर रहे हैं, जब स्लीप को नीचे छुआ जाता है, तो आप टाइप के TIMESTAMP WITH TIME ZONEबजाय उपयोग करेंगे WITHOUT।

क्रिसमस के समान ही नए साल की पूर्व संध्या है। जब टाइम्स स्क्वायर बॉल न्यूयॉर्क में गिरती है , तो सिएटल में लोग अभी भी अपनी शैंपेन को ठंडा कर रहे हैं और अपनी पार्टी के सींग तैयार कर रहे हैं । फिर भी हम नव वर्ष के विचार को 2017-01-01 00:00:00एक के रूप में दर्ज करेंगे TIMESTAMP WITHOUT TIME ZONE। इसके विपरीत, यदि हम रिकॉर्ड करना चाहते हैं कि गेंद न्यूयॉर्क में कब गिरी, या जब सिएटल में लोगों ने अपने सींग उड़ाए, तो हम इसके बजाय उन वास्तविक क्षणों को रिकॉर्ड करने के लिए TIMESTAMP WITH TIME ZONE(नहीं WITHOUT) का उपयोग करेंगे , प्रत्येक तीन घंटे दूसरे से अलग।

Ex: फैक्टरी शिफ्ट्स

एक अन्य उदाहरण एक नीति की रिकॉर्डिंग कर सकता है जिसमें विभिन्न स्थानों पर दीवार-घड़ी का समय शामिल है । कहें कि हमारे पास डेट्रायट, डसेलडोर्फ और दिल्ली में कारखाने हैं। यदि हम कहते हैं कि तीनों कारखानों में पहली पारी सुबह 6 बजे शुरू होती है, तो 11:30 बजे लंच ब्रेक होता है, जो कि रिकॉर्ड किया जा सकता है TIMESTAMP WITHOUT TIME ZONE। फिर से, यह जानकारी अस्पष्ट तरीके से उपयोगी है, लेकिन समय क्षेत्र में एक विशिष्ट क्षण को इंगित नहीं करता है जब तक हम एक समय क्षेत्र लागू नहीं करते हैं। एक नया दिन पूर्व में पूर्व में होता है। इसलिए दिल्ली कारखाना सुबह 6 बजे खुलने वाला पहला कारखाना होगा। घंटे बाद, डसेलडोर्फ कारखाना अपने सुबह 6 बजे काम करना शुरू करता है। लेकिन डेट्रायट फैक्ट्री वास्तव में छह घंटे बाद तक नहीं खुलेगी, जब इसका एएम 6 बजे होगा।

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

तो, हाँ, के लिए वैध उपयोग के मामले हैं TIMESTAMP WITHOUT TIME ZONE। लेकिन व्यावसायिक ऐप के साथ मेरे अनुभव में, वे अपेक्षाकृत दुर्लभ हैं। व्यवसाय में, हम वास्तविक क्षणों के बारे में परवाह करते हैं: वास्तव में चालान कब आया, जब वास्तव में यह अनुबंध लागू होता है, तो उस क्षण में बैंक लेनदेन किस समय निष्पादित होता है। तो ऐसी सामान्य स्थितियों में, हम TIMESTAMP WITH TIME ZONEप्रकार चाहते हैं ।

अधिक चर्चा के लिए, इसी तरह के प्रश्न के लिए मेरा उत्तर देखें , क्या मुझे पाली के लिए यूटीसी टाइमस्टैम्प या स्थानीय समय संग्रहित करना चाहिए

postgres

ध्यान दें कि पोस्टग्रेज विशेष रूप से टाइमस्टैम्प सम्मिलित करते समय निर्दिष्ट समय क्षेत्र की जानकारी को कभी नहीं बचाता है।

• TIMESTAMP WITH TIME ZONE
  • इनपुट डेटा के साथ शामिल किसी भी निर्दिष्ट समय क्षेत्र या ऑफसेट का उपयोग यूटीसी और संग्रहीत करने के लिए मूल्य को समायोजित करने के लिए किया जाता है। पारित ज़ोन / ऑफसेट जानकारी तब खारिज कर दी जाती है। के TIMESTAMP WITH TIME ZONEरूप में सोचो TIMESTAMP WITH RESPECT FOR TIME ZONE।
  • भारत में इस वर्ष 7 मार्च को दोपहर 12:00 बजे के इनपुट का समय दिन के UTC से साढ़े पांच घंटे घटाकर 6:30 बजे होगा।
• TIMESTAMP WITHOUT TIME ZONE
  • इनपुट डेटा के साथ शामिल किसी भी निर्दिष्ट समय क्षेत्र या ऑफसेट को पूरी तरह से नजरअंदाज कर दिया जाता है।
  • भारत में इस वर्ष 7 मार्च को दोपहर 12:00 बजे का इनपुट इस वर्ष 7 मार्च को 12:00 के रूप में दर्ज किया गया है, जिसमें कोई समायोजन नहीं है।

SQL मानक मुश्किल से डेट-टाइम डेटा प्रकार और व्यवहार के मुद्दों पर छूता है। इसलिए डेट-टाइम की हैंडलिंग में डेटाबेस व्यापक रूप से भिन्न होता है ।

Comments

आगे फैक्ट्री (या अस्पताल) शिफ्ट्स के साथ, डीएसटी

— चेंजओवर

मुझे लगता है कि पिछले उदाहरण में एक टाइपो है: '7 मार्च को दोपहर 12:00 बजे का एक इनपुट ..' 12 : 00 के रूप में दर्ज किया जाना चाहिए '(नहीं 21:00)

— TmTron

Answer 3

मैं इसमें एक और दृष्टिकोण जोड़ना चाहूंगा, जो अन्य उत्तरों में लिखे गए बहुत से के खिलाफ जाता है। मेरी राय timestamp with time zoneमें बहुत कम वैध उपयोग के मामले हैं, और timestamp without time zoneसामान्य तौर पर इसे प्राथमिकता दी जानी चाहिए।

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

यदि आप इस पैटर्न का अनुसरण कर रहे हैं, तो timestamp with time zoneएक विरोधी पैटर्न है। यह सब प्रकार आपके PostgreSQL TimeZoneसत्र के चर के आधार पर टाइमस्टैम्प को पढ़ते और लिखते समय PostgreSQL समय-सीमा रूपांतरण करता है । अपने आवेदन के बहुत किनारों पर टाइमज़ोन से निपटने के बजाय, आपने उन्हें अपने दिल में पेश किया है, अपने डेटाबेस के साथ बहुत ही संचार में। TimeZoneअसफलता और भ्रम के एक और अनावश्यक बिंदु को जोड़ते हुए, आपको हमेशा ध्यान रखना चाहिए कि PostgreSQL को हर समय ठीक से कॉन्फ़िगर किया गया है।

और किस लिए? यदि आप हर जगह UTC का अनुसरण कर रहे हैं, तो आपके आवेदन में वैसे भी केवल UTC टाइमस्टैम्प हैं; तो अपने डेटाबेस को उन पर टाइमज़ोन रूपांतरण करने के लिए क्यों कहें? आप बस उन्हें एक timestamp without time zoneकॉलम में स्टोर कर सकते हैं , और इसका इलाज कर सकते हैं जैसे कि यह हमेशा यूटीसी है। कोई रूपांतरण नहीं, कोई टाइमज़ोन नहीं, कोई जटिलता नहीं।

Comments

मुझे लगता है कि टाइमस्टैम्प्ट के प्रस्तावक "यूटीसी हर जगह" पैटर्न का भी समर्थन करते हैं। यह सिर्फ नियम है कि इसे लागू करने के लिए केवल ऐप / एपीआई डेवलपर्स पर निर्भर रहने के बजाय डेटाबेस स्तर पर लागू किया जाता है? यदि आप उस अभ्यास को लागू करने में सक्षम हैं, तो क्यों नहीं? इसके अलावा, आप केवल यह लागू कर सकते हैं कि सभी पोस्टग्रैड कनेक्शन यूटीसी पर अपना समय क्षेत्र निर्धारित करते हैं। यहां तक ​​कि अगर वे नहीं करते हैं, तो आईएसओ प्रारूप में tz ऑफसेट शामिल होगा। तो यह है कि UTC के रूप में एक ही बात हर जगह नहीं बल्कि लागू है?

— Iamnat

सबसे पहले, अगर आपका PostgreSQL TimeZone कुछ भी करने के लिए सेट है, लेकिन UTC और आपके टाइमस्टैम्प्ट्ज़ का उपयोग कर रहे हैं, तो आपका प्रोग्राम नॉन-यूटीसी टाइमस्टैम्प पढ़ रहा है। यह केवल "यूटीसी हर जगह" पैटर्न नहीं है, और आपकी ग्राहक भाषा के आधार पर बहुत सारी जटिलताएं पैदा हो सकती हैं या नहीं हो सकती हैं। या तो आप हर जगह UTC हैं, या आप स्थानीय टाइमस्टैम्प का उपयोग कर रहे हैं ....

— Shay Rojansky

दूसरा, एक बार फिर, यदि आप अपने आवेदन में हर जगह यूटीसी हैं, तो आपके टाइमस्टैम्प के लिए आईएसओ प्रारूप में भेजने के लिए बस कोई tz ऑफसेट नहीं है। विशिष्टताओं को भाषाओं में अलग-अलग किया जा रहा है, लेकिन आपको आदर्श रूप से एक क्लाइंट प्रकार का उपयोग करना चाहिए जो कि यूटीसी टाइमस्टैम्प (जैसे InstanceNodaTime / JodaTime में) का प्रतिनिधित्व करने में असमर्थ है । आप मूल रूप से एक ऐसी स्थिति का वर्णन कर रहे हैं, जहां "यूटीसी हर जगह" का लगभग पालन किया जाता है, या थोड़े पालन किया जाता है ...

— Shay Rojansky

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

— Shay Rojansky

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

— श्ये रंजनस्की

Answer 4

dateसमय मोहर समयक्षेत्र जानकारी शामिल नहीं है, फिर भी बहुत से लोगों को इसका इस्तेमाल करते हैं।

बेशक, खुद का जवाब नहीं है।

यह उपयोग करने के लिए वैध है timestampऔर dateकिसी भी टाइम स्टांप और तारीखें जो एक ही समय क्षेत्र में हमेशा से रहे हैं, या कुछ ज्ञात समय क्षेत्र के रिश्तेदार संग्रहीत किया जा रहा है के लिए।

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

टाइमस्टैम्प का उपयोग तकनीकी जानकारी संग्रहीत करने के लिए भी किया जा सकता है जैसे कि एप्लिकेशन लॉग में या प्रदर्शन माप के लिए। इस मामले में, समयक्षेत्र भी महत्वहीन हो सकता है।

---

इसके विपरीत, यदि आप किसी वितरित सिस्टम पर डिज़ाइन कर रहे हैं या किसी सिस्टम में काम कर रहे हैं, जहां सिस्टम के कुछ हिस्सों को अलग-अलग टाइमज़ोन में वितरित किया जाएगा, तो इसे उपयोग न करने के लिए एक विरोधी पैटर्न माना जा सकता है timestamp with timezone, हालांकि कुछ सिस्टम चलाने के लिए डिज़ाइन किए जा सकते हैं एक समयक्षेत्र में, उदाहरण के लिए यूटीसी। इस मामले में टाइमज़ोन लॉजिक को एप्लिकेशन लेयर में धकेला जा सकता है - लेकिन मैं इसे एक एंटी-पैटर्न मानूंगा, हां।

Comments

मैं समझता हूं कि कुछ मामलों में इसका उपयोग करने में कोई दिक्कत नहीं है timestamp without timezone, लेकिन क्या यह मुझे कभी खरीदता है? अन्यथा, मुझे परेशान क्यों होना चाहिए यदि timestamp with timezone dataप्रकार हमेशा समान या अधिक उपयुक्त होता है?

— मार्कस जूनियस ब्रूटस

अनावश्यक जानकारी संग्रहीत करना मेरा मुख्य तर्क नहीं होगा। मुझे लगता है कि अंकगणित की तारीख timestamp without timezoneतेजी से होगी, भी, लेकिन यह केवल तभी महत्वपूर्ण है जब आप अरबों पंक्तियों का प्रसंस्करण कर रहे हों ...

— कॉलिन टी हार्ट

@ Colin'tHart timestampऔर timestamptzदोनों एक ही तरह से संग्रहीत हैं। इसमें समय क्षेत्र की जानकारी संग्रहीत नहीं की जा रही है timestamptz, लेकिन इसके बजाय इसे भंडारण के लिए यूटीसी में बदल दिया जाता है। मैं कहता हूँ, हमेशा उपयोग करें timestamptzजब सवाल में टाइमस्टैम्प निरपेक्ष समय निरूपित करते हैं । यही सब timestamptzमतलब है। मैंने यहाँ इस बारे में लिखा है ।

— fphilipe

Answer 5

स्थानीय समय में दिनांक / समय को स्टोर और प्रोसेस करने के लिए यह टेम्परिंग लग सकता है यदि आपका आवेदन एक ही समय क्षेत्र तक सीमित है लेकिन मेरा मानना ​​है कि यह एक गलती है।

स्थानीय समय में एक घंटे के मानक समय पर दिन के समय की बचत के समय से वापस स्विच करते समय दोहराया जाता है (अंतर एक घंटे है)। जहां मैं रहता हूं यह आम तौर पर 2 बजे के आसपास होता है इसलिए स्थानीय समय 01:58, 01:59, 01:00 तक चलता है और केवल दोहराए जाने वाले घंटे के अंत में केवल 02:00 पर आगे बढ़ता है।

यदि आप स्थानीय समय का उपयोग करके समय पर घटनाओं को क्रमबद्ध करने का प्रयास करते हैं अर्थात दो अलग-अलग घंटों की घटनाओं को एक साथ मिलाया जाता है और उस क्रम में प्रकट नहीं होता है जिसमें वे वास्तव में हुए थे।

तुलना करके यूटीसी के पास यह समस्या नहीं है और सफाई से आदेश देता है। इसलिए, जब आप केवल एक समय क्षेत्र के साथ काम कर रहे हैं, तो आप चाहते हैं कि DB UTC में समय को संग्रहीत और संसाधित करें और इनपुट / प्रदर्शन के लिए स्थानीय समय से / में परिवर्तित करें। यह टाइम ज़ोन के साथ टाइमस्टैम्प का व्यवहार है।