गलतफहमी का क्षेत्र

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

यहाँ कुछ सामान्य गलत कारण हैं जो मैंने सुना है कि टाइम ज़ोन प्रकार के साथ टाइमस्टैम्प का उपयोग नहीं करना है:

• मैं यूटीसी प्रारूप में सब कुछ स्टोर करना चाहता हूं;
• मैं अनुरोध से कई अलग-अलग समय क्षेत्र प्राप्त नहीं करना चाहता हूं;
• हम समय क्षेत्र के प्रसंस्करण के लिए एक विशेष पुस्तकालय का उपयोग करते हैं;
• मैं समय क्षेत्र को संग्रहीत करने के लिए डिस्क स्थान को बर्बाद नहीं करना चाहता हूं।

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



सहज रूप से, यह माना जा सकता है कि वर्तमान में टाइमस्टैम्पटज को लगभग संग्रहीत किया गया है:

"2011-06-11 15:53:22 PDT"

यानी समय क्षेत्र की जानकारी समय के साथ ही जुड़ती जाती है। यह मामले से बहुत दूर है।

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

मान लीजिए कि जोश कैलिफोर्निया में रहता है (समय क्षेत्र "अमेरिका / लॉस_एंगल")। यह तालिका में इस तरह एक पंक्ति जोड़ता है:

INSERT INTO messages ( user_id, message, left_at )
VALUES ( 3, ' !', '2011-09-27 17:17:25' );

... फिर ब्रूस , जो फिलाडेल्फिया में रहते हैं ("अमेरिका / न्यू_यॉर्क" का समय क्षेत्र), डेटा का अनुरोध करने के बाद, देखेंगे:

user_id | 3
message | !
left_at | 2011-09-27 20:17:25-04

... और मैग्नस , जो स्वीडन में रहते हैं ("यूरोप / स्टॉकहोम"), बदले में, प्राप्त करेंगे:

user_id | 3
message | !
left_at | 2011-09-28 02:17:25+02

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

टाइम ज़ोन के बिना टाइमस्टैम्प बस कोई परिवर्तन नहीं करता है, यह मानते हुए कि सभी समय डेटा एक ही समय क्षेत्र के हैं।

अधिकांश प्रोग्रामिंग भाषाओं के लिए, पोस्टग्रेएसक्यूएल सर्वर की अंतरात्मा पर अस्थायी डेटा के प्रसंस्करण को छोड़ने का कोई मतलब नहीं है, बल्कि एक अतिरिक्त सॉफ़्टवेयर परत पर निर्भर है। पूरी जिम्मेदारी के साथ, आप घोषणा कर सकते हैं: “पोस्टग्रेज में अस्थायी डेटा के लिए समर्थन एक संदर्भ है। और कुल मिलाकर, PHP, अजगर या पर्ल के लिए पुस्तकालयों की तुलना में अधिक विश्वसनीय और अद्यतित है। " यह भी ध्यान देने योग्य है कि PostgreSQL गर्मियों / सर्दियों के समय पर स्विच करने की समस्याओं का सामना करता है।

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

बेशक, समय क्षेत्र की जानकारी संग्रहीत नहीं करने के कई अच्छे कारण हैं:

• आपका ड्राइवर या ORM टाइम ज़ोन का समर्थन नहीं करता है (हालाँकि यह नए के पक्ष में एक तर्क हो सकता है);
• आपके कोड को पर्याप्त समय क्षेत्र समर्थन के बिना DBMS के साथ भी काम करना चाहिए;
• आप दिनांक कॉलम द्वारा तालिका को विभाजित करने जा रहे हैं और आपको पूर्ण मूल्यों की आवश्यकता है;
• एक डेटाबेस का उपयोग कभी भी एक से अधिक समय क्षेत्र में नहीं किया जाएगा।

लेकिन अगर इनमें से कोई भी कारण आप पर लागू नहीं होता है, तो आपको टाइमस्टैम्पटीजेड प्रकार का उपयोग करना चाहिए।

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