एक वेब एप्लिकेशन विकसित करना जो उपयोगकर्ता को अपने टाइमजोन के आधार पर नियुक्ति को शेड्यूल करने की अनुमति दे। और मैं डेटाबेस के क्षेत्र में सर्वर डेटाटाइम के रूप में उपयोगकर्ता शेड्यूल किए गए डेटाटाइम को संग्रहीत कर रहा हूं। शेड्यूल जानकारी दिखाते समय डेटाबेस से मान प्राप्त किया और उपयोगकर्ता टाइमज़ोन में परिवर्तित हो गया। कोड बेस में प्रोसेसिंग मैं उपयोगकर्ता टाइमजोन के आधार पर डेटटाइम परिवर्तित कर रहा हूं। कृपया सुझाव दें कि यह सबसे अच्छा अभ्यास है या कोई आसान तरीका मौजूद है?
जवाबों:
गैर-कम्प्यूटेशनल प्रोग्रामिंग में सबसे कठिन समस्याओं में से एक में आपका स्वागत है - उपयोगकर्ताओं को समाप्त करने के लिए दिनांक और समय का ठीक से प्रतिनिधित्व करना।
वास्तविक रूप से, टाइमस्टैम्प को एक निश्चित एकल प्रतिनिधित्व में संग्रहीत किया जाना चाहिए, भले ही उनकी व्याख्या कैसे की जाए, क्योंकि आप कितनी भी कोशिश कर लें, आपके पास हमेशा अस्पष्ट मामले होंगे, और आप उन्हें एक निश्चित प्रतिनिधित्व के बिना हल नहीं कर सकते। और आपने उपयोग के सबसे खराब मामलों में से एक उठाया है - एक नियुक्ति का समय निर्धारण। एकमात्र बदतर आम उपयोग का मामला हवाई यात्रा है, जहां एक यात्रा एक समय क्षेत्र में शुरू हो सकती है और दूसरे में समाप्त हो सकती है, जो पहले के स्थानीय समय में संभव है।
हमेशा, हमेशा, यूटीसी में ALWAYS स्टोर और उपयोगकर्ता की पसंदीदा या स्पष्ट रूप से निर्दिष्ट समय क्षेत्र में प्रदर्शित होता है। यदि संभव हो, तो उपयोगकर्ता को यह बताएं कि टाइमज़ैम्प का मानना है कि वे टाइमस्टैम्प में हैं जब वे इसे इनपुट करते हैं ( उदाहरण के लिए , एक स्पष्ट समय क्षेत्र है और इसे अपने पसंदीदा क्षेत्र के साथ पूर्व-आबाद करें)।
तारीख / समय की जानकारी से निपटने का सबसे आसान तरीका आपके आवेदन की आवश्यकताओं पर निर्भर करता है।
यदि उपयोगकर्ता द्वारा दिनांक और समय दर्ज किया जाता है और सर्वर उस डेटाबेस में संग्रहीत करने के अलावा उस तिथि / समय की जानकारी के साथ कोई प्रसंस्करण नहीं करता है और इसमें कोई उम्मीद नहीं है कि दर्ज समय उस स्थान के अनुकूल हो जाता है जहां उसे देखा जाता है (उदाहरण के लिए) , जहां उपयोगकर्ता ने "8:00 PM" दर्ज किया और इसे "8:00 PM" के रूप में प्रदर्शित किया जाना चाहिए, भले ही दुनिया में इसे कहां देखा गया हो), तो सबसे आसान तरीका है कि किसी भी समयक्षेत्र जानकारी के बिना डेटाइम को स्थानीय समय के रूप में संग्रहीत किया जाए।
दूसरी ओर, यदि सर्वर को कुछ करने के लिए ट्रिगर के रूप में दर्ज डेटटाइम का उपयोग करना चाहिए, या यदि समय को वर्तमान टाइमज़ोन में सही ढंग से समायोजित किया जाना चाहिए, तो आपका सबसे अच्छा विकल्प डेटाइम को यूटीसी समय के रूप में संग्रहीत करना और इसे स्थानीय में समायोजित करना है। समय (उपयोगकर्ता के वर्तमान स्थान के लिए) हर बार जब आप इसे डेटाबेस से पढ़ते हैं।
यह महत्वपूर्ण है कि आप दो संबंधित अवधारणाओं का सामना न करें।
यदि आप समय में एक वास्तविक बिंदु में हेरफेर कर रहे हैं, जो एक विशिष्ट दिन पर एक विशिष्ट समय है, तो ऐसा करने का एकमात्र तरीका हमेशा सार्वभौमिक यूटीसी समय मूल्य का उपयोग करना है। इसे कभी भी समय-संगत मान के रूप में संग्रहीत करने का प्रयास न करें। किसी उपयोगकर्ता के लिए इस समय मान को प्रदर्शित करते समय, उस समय हमेशा उपयोगकर्ता समय क्षेत्र में परिवर्तित करें। (और समय और दिनांक दोनों समय क्षेत्र पर निर्भर न हों।)
दूसरी अवधारणा "टाइम एक्सप्रेशन" जैसे कि "हर मंगलवार को रात 8:00 बजे" है। आपने विशेष रूप से लोगों को नियुक्तियों को शेड्यूल करने की अनुमति देने का उल्लेख किया है, और यदि आपके पास पुनरावर्ती नियुक्तियां हैं, तो आपको इस तरह की अभिव्यक्ति की आवश्यकता है। मुझे किसी भी मानक अभिव्यक्ति की भाषा का पता नहीं है, लेकिन आप जो भी उपयोग करते हैं, वह उस व्यक्ति के समय क्षेत्र के सापेक्ष होगा जिसने इसे निर्दिष्ट किया है। यह स्पष्ट करने के लिए सबसे अच्छा होगा जैसे "प्रशांत समय क्षेत्र में हर मंगलवार रात 8:00 बजे"। एक समय अभिव्यक्ति के मामले में, आप इसे हमेशा एक स्ट्रिंग के रूप में संग्रहीत करते हैं, और किसी भी सिस्टम समय प्रारूप को शामिल नहीं करते हैं।
यहां कई उत्तर यूटीसी के रूप में संग्रहीत करने का संकेत देते हैं। लेकिन इसके साथ वास्तव में सावधान रहें। उदाहरण के लिए, यदि आप 12:00 बजे अपॉइंटमेंट शेड्यूल करते हैं लेकिन नियुक्ति डेलाइट सेविंग टाइम में बदलाव के बाद होती है, तो क्या होगा? UTC इस बारे में कोई जानकारी नहीं रखता है कि नियुक्ति के समय क्या dst सक्रिय था। बहुत बड़ी, प्रसिद्ध प्रणालियों ने यह त्रुटि की है, जहां एक उपयोगकर्ता गर्मियों में सुबह 9 बजे एक ईमेल भेजता है, और फिर सर्दियों में भेजे गए समय में सुबह 8 बजे दिखाई देता है, क्योंकि यूटीसी से वापस गणना इस बात पर निर्भर करती है कि आप डेटाटाइम कब देखते हैं, जब डेटाटाइम रिकॉर्ड किया गया था तब नहीं।
बहुत बेहतर है मान लें कि आपका उपयोगकर्ता वह समय चाहता है जो उसने हमेशा उठाया था। कोई यूटीसी रूपांतरण, कोई समय रूपांतरण, कोई टाइमज़ोन जानकारी, कुछ नहीं। २१ मार्च २०१६ को ० from:०० से १२:०० तक की नियुक्ति करना सिर्फ इतना ही है। स्थानीय समय या UTC समय का उपयोग न करें, लेकिन अनिर्दिष्ट समय (json में न तो z है और न ही +, मूल रूप से, .NET में यह DateTime.Kind = DateTimeKind.Unspecified) है।
बेशक, यदि आपका उपयोग मामला यह है कि आप एक ऐसी कंपनी हैं, जो अलग-अलग टाइमज़ोन से किसी के साथ मीटिंग करती है और आप इस जानकारी को कंपनी कैलेंडर के अनुसार देखना चाहते हैं, लेकिन उपयोगकर्ताओं को यह देखने की अनुमति दें कि उनके टाइमज़ोन में क्या समय है, यह अधिक जटिल हो जाता है। अलग-अलग टाइमज़ोन (आपूर्तिकर्ता और ग्राहक) में अलग-अलग लोगों के लिए समय सही होना चाहिए।
उन मामलों में, आप यह भी रिकॉर्ड करना चाह सकते हैं कि जब नियुक्ति डेटाबेस में सेव की गई थी, तो किस समय में और अगर इसमें डीएसटी शामिल है या नहीं। इस तरह, आप हमेशा स्थानीय समय की गणना किसी और चीज़ के लिए कर सकते हैं, या तो यह अब क्या होगा या ऐतिहासिक रूप से इसका क्या उद्देश्य था। क्योंकि टाइमज़ोन बहुत अधिक स्थिर नहीं हैं, जिससे चीजें और भी जटिल हो जाती हैं।
सौभाग्य से, यह वह जगह है जहाँ http://nodatime.org/ जैसे पुस्तकालय आते हैं और अत्यधिक अनुशंसित हैं। वे बहुत अधिक लगातार तारीखों के साथ काम करते हैं। फिर भी मैं आपके सभी रैपरटाइम वैरिएबल और लॉजिक को अपने स्वयं के रैपर में लपेटने की सलाह दूंगा, इंटरफेस का उपयोग करके ताकि उनका मजाक उड़ाया जा सके, और फिर आप बाद में भी लॉजिक को बदल सकते हैं।