मैं अपने वेब में समय क्षेत्र कैसे संभाल सकता हूं?

Question

मैं निम्नलिखित उपयोगकर्ता कहानी की बेहतर समझ के लिए देख रहा हूँ:

जॉन सिडनी में काम करता है। सुबह 9:00 बजे, वह ज्यूरिख में एक सर्वर पर चलने वाले एक वेब ऐप में एक घटना को लॉग करता है। अगले दिन, वह एक आपातकालीन बैठक के लिए न्यूयॉर्क की यात्रा करता है जिसमें इस घटना पर चर्चा की जानी चाहिए। बैठक के दौरान, वह तारीख और समय के आधार पर इस घटना को खोजता है।

जैसा कि मैंने देखा, यहाँ कम से कम दो मुद्दे हैं:

1. मुझे डेटाबेस में समय टिकटों को कैसे सहेजना चाहिए
2. मुझे उन्हें यूआई में कैसे प्रस्तुत करना चाहिए

जब जॉन घटना को खोजता है, तो उसे पता चलेगा कि यह 9:00 बजे हुआ था लेकिन उसे वेब ब्राउज़र में क्या दर्ज करना चाहिए? जब वह सिर्फ "9:00" टाइमस्टैम्प में प्रवेश करता है तो उसे कुछ भी नहीं मिलेगा क्योंकि वह ज्यूरिख या न्यूयॉर्क समय हो सकता है (क्योंकि घटना नहीं मिली है, ऐप के पास यह जानने का कोई तरीका नहीं है कि यह सिडनी में हुआ था, इसलिए यह स्वचालित रूप से सही समय क्षेत्र का चयन नहीं कर सकता है)।

टाइमस्टैम्प के लिए उपयोगकर्ता से पूछने का एक अच्छा तरीका क्या है जिसमें समय क्षेत्र शामिल हो सकता है?

दूसरा मुद्दा यह है कि परिणामों को कैसे प्रदर्शित किया जाए। यदि दुनिया भर की टीमों को इस घटना पर चर्चा करने की जरूरत है (और संबंधित घटनाओं को खोजने के लिए, एक पटाखा हमले के बारे में सोचें जो दुनिया भर में कई साइटों को एक साथ लक्षित करता है)।

टाइमस्टैम्प को प्रदर्शित करने के लिए एक अच्छा उदाहरण क्या है जो एक अलग समय क्षेत्र में बनाया गया हो सकता है?

नोट: कृपया आवश्यकता के प्रयोज्य पर ध्यान केंद्रित करें। मैं खुद को मैप करने वाले डेटाबेस का पता लगा सकता हूं। वर्तमान में, मैं कार्य प्रवाह के बारे में अनिश्चित हूं। इसे गैर-दखल / सहज तरीके से आवश्यक जानकारी को पूछना / प्रस्तुत करना चाहिए। यदि आप कर सकते हैं, तो एक मौजूदा वेब ऐप का लिंक दें जो पहले से ही इसे हल करता है।

Comments

स्टैक ओवरफ्लो सब कुछ यूटीसी में डालकर हल करता है। हमेशा सुविधाजनक नहीं, लेकिन यह निश्चित रूप से अस्पष्ट है, इसे लागू करना मुश्किल नहीं है, और काम करता है।

— Ry- Ry

UTC लुभा रहा है, लेकिन OTOH, SO को कई समय क्षेत्रों में घटनाओं को सिंक्रनाइज़ करने की आवश्यकता नहीं है।

— हारून दिगुल्ला

क्या होगा अगर इसमें शामिल देशों में से एक कानून लागू करता है जो घटना निर्धारित होने के बाद स्थानीय समय को बदलता है, लेकिन इससे पहले कि घटना होती है? सिस्टम को इसे कैसे संभालना चाहिए? en.wikipedia.org/wiki/…

— जूलियस मुसेऊ

इस प्रकार के क्लासिक टाइमज़ोन प्रश्न दशकों से पूरे इंटरनेट पर और प्रिंट में मौत को मात दे रहे हैं, मैं इस सवाल पर इस तरह के जीवंत इनपुट और इनामों को देखकर आश्चर्यचकित हूं!

— बेनस्वे

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

— fr13d

Answer 1

टाइमस्टैम्प के भंडारण का मुद्दा सरल है: उन्हें यूटीसी में स्टोर करें।

जैसा कि उन्हें प्रदर्शित करने के लिए, यह डिवाइस के टाइमज़ोन सेटिंग को लेने और वर्तमान टाइमज़ोन के रूप में उपयोग करने के लिए समझ में आता है। उस ने कहा, "टाइम इनपुट" बॉक्स के बगल में एक टाइमज़ोन ड्रॉपडाउन होना चाहिए, जो डिवाइस के वर्तमान टाइमज़ोन के लिए चूक करता है, इसलिए उपयोगकर्ता इसे ज़रूरत पड़ने पर बदल सकता है।

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

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

---

ऊपर संक्षेप में प्रस्तुत करने के लिए:

• पहले रन पर, डिवाइस को किस टाइमज़ोन पर सेट किया गया है, इसे सहेजें।
• डिफ़ॉल्ट समयक्षेत्र के रूप में उस समय क्षेत्र का उपयोग करें। हमेशा उस टाइमजोन को मानें।
• डिवाइस को टाइमज़ोन को स्विच करना चाहिए, ड्रॉपडाउन को यह चुनने के लिए जोड़ें कि कौन सा टाइमज़ोन इवेंट में है, डिवाइस के अपने टाइमज़ोन के लिए डिफ़ॉल्ट है।
• इस टाइमज़ोन ड्रॉपडाउन को मैन्युअल रूप से दिखाने / छिपाने के लिए एक विकल्प जोड़ें।
• हमेशा यूटीसी में टाइमस्टैम्प स्टोर करें।

Comments

"टाइमज़ोन" से हमारा क्या मतलब है यह अस्पष्ट रूप से उपयोग किया जाता है। यह एक संदर्भ की तरह दिखता है: en.wikipedia.org/wiki/Tz_database जो मैं "टाइमज़ोन" बता सकता हूं वह "क्षेत्र / स्थान" है, उदाहरण के लिए "अमेरिका / न्यू_यॉर्क"। यह भौगोलिक प्रतीत होता है जो महान है क्योंकि उदाहरण के लिए अमेरिका / Los_Angeles का अर्थ है BOTH PST और PDT, जो इस बात पर निर्भर करता है कि क्या विश्व डेलाइट सेविंग टाइम में चल रहा है। और अगर ऐसा है, तो सवाल यह है कि हम जोन के लिए यूटीसी ऑफसेट में द्वि-वार्षिक परिवर्तनों के लिए कैसे खाते हैं? इसके अलावा, हम उन आशंकाओं को क्या कहते हैं क्योंकि वे भौगोलिक रूप से "ज़ोन" नहीं हैं?

— iJames

यह एक बेहतरीन जवाब है। क्या टाइमज़ोन जानकारी को संग्रहीत करने के तरीके पर सबसे अच्छा अभ्यास है? उदाहरण के लिए - कौन सा बेहतर होगा - 'पीएसटी' या 'अमेरिका / प्रशांत'? मैं आसानी से UTC में एक टाइमस्टैम्प को कैप्चर किए गए उपयोगकर्ता टाइमज़ोन में कैसे परिवर्तित कर पाऊँगा? इस पर किसी भी सर्वोत्तम अभ्यास की सराहना की जाएगी।

— पत्तीबाग

Answer 2

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

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

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

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

यदि आपके पास टाइमज़ोन की जानकारी है, तो संपूर्ण वेब ऐप को टाइमज़ोन सेटिंग के साथ चलाया जाना चाहिए। इसलिए जब उपयोगकर्ता 9:00 के लिए खोज करता है, तो वह सिडनी टाइमज़ोन के साथ खोज करेगा। दूसरी ओर, अगर वह न्यूयॉर्क में बैठकर कोई इवेंट बनाता है, तो वह सिडनी टाइमज़ोन के साथ एक इवेंट बनाएगा। हम ऐसे मामलों को हमेशा तारीखों को प्रदर्शित करते हुए टाइमजोन द्वारा हल करते हैं।

आशा करता हूँ की ये काम करेगा! :)

Comments

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

— रासमुस्सल

यह एक बेहतरीन जवाब है। क्या टाइमज़ोन जानकारी को संग्रहीत करने के तरीके पर सबसे अच्छा अभ्यास है? उदाहरण के लिए - कौन सा बेहतर होगा - 'पीएसटी' या 'अमेरिका / प्रशांत'? मैं आसानी से UTC में एक टाइमस्टैम्प को कैप्चर किए गए उपयोगकर्ता टाइमज़ोन में कैसे परिवर्तित कर पाऊँगा? इस पर किसी भी सर्वोत्तम अभ्यास की सराहना की जाएगी।

— पत्तीबाग

Answer 3

1. यु.टी. सी। इसे सरल रखें।

2. उस समयक्षेत्र का उपयोग करें जो उपयोगकर्ता के लिए सबसे अधिक प्रासंगिक है।

   यदि आप जानते हैं कि उपयोगकर्ता घटना के लिए सिडनी में जा रहा है या यात्रा कर रहा है, तो वे उस समय क्षेत्र में सोच रहे होंगे जब घटना के लिए परिवहन की व्यवस्था करेंगे। यह तथ्य कि वे इस समय न्यूयॉर्क में हैं, काफी हद तक अप्रासंगिक है। और हां, अगर आपका ऐप कई तरह के टाइमज़ोन में तारीखें दिखाता है, तो उसे हमेशा तारीख के बगल में टाइमज़ोन दिखाना चाहिए, जैसे कि 09:00 ईएसटी ।

   यदि यह आपके इंटरफ़ेस को बहुत अधिक अव्यवस्थित नहीं करता है, तो आप ईवेंट टाइमज़ोन और स्थानीय टाइमज़ोन में दिनांक प्रदर्शित कर सकते हैं, जैसे 2012-06-13 09:00 ईएसटी (2012-06-12 19:00 ईडीटी) ।

   मैं तर्क दूंगा कि खोज करना एक समान समस्या है, एक चेतावनी के साथ: हम झूठी सकारात्मक को सहन कर सकते हैं (ऐसा परिणाम प्राप्त करना जिसकी हम उम्मीद नहीं कर रहे थे), लेकिन हम झूठी नकारात्मक (हम उम्मीद नहीं कर रहे थे परिणाम प्राप्त नहीं कर सकते हैं)।

   फिर से, मैं उपयोगकर्ता के लिए सबसे अधिक प्रासंगिक टाइमज़ोन खोज करने पर ध्यान केंद्रित करूँगा (जैसे ईवेंट टाइमज़ोन), और इन परिणामों को खोज परिणामों में प्राथमिकता दें, लेकिन आप अन्य टाइमज़ोन में मेल खाने वाली घटनाओं को भी लौटा सकते हैं जो उपयोगकर्ता के लिए प्रासंगिक हैं (जैसे स्थानीय समय)। यदि आप ऐसा करते हैं, तो आपको मिलान समय में घटना की तारीख दिखानी चाहिए, खासकर यदि आप मिलान पाठ को उजागर करते हैं।

Answer 4

यहां मैं कार्यान्वयन की व्यवहार्यता के बारे में बहुत परेशान किए बिना सर्वोत्तम प्रयोज्य के लिए सुझाव दे रहा हूं।
1. db में घटनाओं को संग्रहीत करने के पहले अंक के लिए, हर कोई इसे UTC में संग्रहीत करने के लिए सहमत होगा

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

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

3. टाइमस्टैम्प के लिए उपयोगकर्ता से पूछने का एक अच्छा तरीका क्या है जिसमें समय क्षेत्र शामिल हो सकता है?

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

4. परिणाम प्रदर्शित करने के लिए कैसे, अगर दुनिया भर से टीमों को घटना पर चर्चा करने की आवश्यकता है:

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

ये सुझाव इस आशय से दिए गए हैं कि उपयोगकर्ता को अपने स्थानीय समय में कोई गणना करने की आवश्यकता नहीं है, लेकिन साथ ही वह अन्य उपयोगकर्ताओं के साथ अपने पसंदीदा समय क्षेत्र में धाराप्रवाह संवाद करने में सक्षम होना चाहिए।

Comments

+1 यह एक बहुत ही दिलचस्प विचार है क्योंकि मुझे पता है कि उपयोगकर्ता ने सिडनी में 9:00 बजे एक कार्यक्रम में प्रवेश किया था, इसलिए जब एक ही उपयोगकर्ता एक समय के लिए खोज करता है (स्पष्ट समय क्षेत्र के बिना), मुझे यह मान लेना चाहिए कि वह "जहां मैं था उस समय "

— हारून डिगुल्ला

Answer 5

ठीक है मुझे दूसरों की तुलना में एक अलग दृष्टिकोण मिला:

सबसे पहले, मैंने हाथ से पहले कुछ चीजें ग्रहण कीं।

व्यक्ति जो किसी ईवेंट को सूचीबद्ध कर रहा है उसके पास स्मार्टफ़ोन है (यदि यह एक ब्राउज़र है, तो मुझे इन मान्यताओं को बनाने की ज़रूरत नहीं है):

1. GPS

2. एचटीएमएल 5 क्षमता।

3. जावास्क्रिप्ट क्षमता

मुझे डेटाबेस में समय टिकटों को कैसे बचाना चाहिए?

समाधान: स्पष्ट रूप से UTC , मैं नीचे की प्रक्रिया को समाप्त करता हूं:

चरण 1. उपयोग जियोलोकेशन Geolocation API का उपयोग उपयोगकर्ता के

    window.onload = getMyLocation;

    function getMyLocation() {
        if (navigator.geolocation) {
            navigator.geolocation.getCurrentPosition(displayLocation);
        } else {
            alert("Oops, no geolocation support");
        }
    }

    function displayLocation(position) {
        var latitude = position.coords.latitude;
        var longitude = position.coords.longitude;
        var div = document.getElementById("location");
        div.innerHTML = "You are at Latitude: " + latitude + ", Longitude: " + longitude;
    }

चरण 2. यूजर्स को टाइमजोन प्राप्त करने के लिए TimeZone api जैसे याहू एपीआई (फ्लैग आर का उपयोग अक्षांश को टाइमजोन में बदलने के लिए) करने के लिए (लाट, लॉन्ग) में से कुछ के तर्क के रूप में (लॉन्ग, लाट) दें ।

=> उपयोगकर्ता टाइमजोन उपयोगकर्ता इनपुट के बिना निर्धारित किया जाता है (मैं इसका उपयोग कर रहा हूं क्योंकि आप बस यह नहीं मान सकते हैं कि उपयोगकर्ता उस स्थान का समय-क्षेत्र जानता है जिसमें वह रहता है, मुझे कुछ समय या कुछ समय के बाद ही मेरा समय क्षेत्र पता था: पी, सुंदर गूंगा! )

प्रत्येक ईवेंट टेबल में है Timezone, Eventऔर इसलिए एस के CityName आधार पर वर्गीकरण के साथ एक और डेटाबेस तालिका बना सकते हैं CityName। इसलिए यहां यूजर के पास दो कॉलम होंगे

|---------------------------------------|
|_____NewYork________|______Sydney______|
|                    |                  |
|Event 1             |  Event 2         |
|____________________|__________________| 

यूआई के लिए

=> Google कैलेंडर API या कुछ कैलेंडर API का उपयोग करें

संबंधित रीडिंग:

1. Geonames.org जैसी वेब सेवाओं का उपयोग किए बिना अक्षांश / देशांतर से समयक्षेत्र निर्धारित करें

2. अक्षांश देशांतर से टाइमजोन की खोज

मैं इस समस्या को हल करने के बारे में कुछ विचार दिखाने के बारे में जानता हूं। लेकिन यह देखें कि टाइमजोन डिवाइस एपीआई का उपयोग करके निर्धारित किए जाने पर उपयोगकर्ताओं पर कितना सटीक और हल्का होता है

आशा करता हूँ की ये काम करेगा!

Comments

जियोलोकेशन के बिना किसी के टाइमज़ोन को ढूंढना बहुत आसान है। new Date().getTimezoneOffset()UTC के पीछे मिनटों में देता है।

— Ry-

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

— uday

इसलिए? दोनों जगहों पर समय समान होगा, इसलिए कोई समस्या नहीं है। -1

— Ry-

@ मिनिटेक, आप इस लिंक को देख सकते हैं कि मैं अन्य तरीकों की तुलना में डिवाइस एपीआई का उपयोग करने की सलाह क्यों देता हूं । webdirections.org/sotmw2011

— uday

ठीक है, लेकिन यहाँ मुद्दा उपयोगकर्ता के शहर को प्राप्त करने का नहीं है। यह केवल समय क्षेत्र प्राप्त करने के बारे में है। एक जियोलोकेशन एपीआई का उपयोग करना जो प्रत्येक ब्राउज़र / कंप्यूटर पर काम नहीं करता है, फिर एक कैलेंडर API पर पुनर्निर्देशित करना, उपयोगकर्ता की टाइमज़ोन प्राप्त करने का एक बुरा तरीका है जब यह कोड की एक पंक्ति में उपलब्ध होता है।

— Ry-

Answer 6

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

आपकी एक बैठक है:

12:00 Monday (UTC)
9:00 Monday (Sydney, creation local time)
11:00 Monday (Zurich, local time)

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

Answer 7

1. मुझे डेटाबेस में समय टिकटों को कैसे सहेजना चाहिए

घटना के निर्माण में, मैं यूटीसी समय और स्थानीय समय क्षेत्र (उर्फ creation time zone) स्टोर करूंगा । मैं यूटीसी समय को स्थानीय समय (उर्फ creation time) में परिवर्तित करने के लिए जो कुछ संग्रहीत करता हूं उसका उपयोग करता हूं और इसे यूटीसी समय के साथ संग्रहीत करता हूं और creation time zone।

नोट: मैं स्थानीय समय को गेट-गो से स्टोर कर सकता हूं, लेकिन जब उपयोगकर्ता किसी ईवेंट की खोज करता है, तो मुझे उम्मीद है कि स्थानीय समय मौजूद है। मुझे यह भी उम्मीद है कि सर्वर यह पता लगा सकता है कि क्लाइंट किस समय क्षेत्र में है।

1. मुझे उन्हें यूआई में कैसे प्रस्तुत करना चाहिए

"09:00" की खोज करता है, मैं घटनाओं है कि "09:00" शामिल या तो यूटीसी में के लिए खोज करेंगे जब या creation time या स्थानीय समय। परिणामों के लिए, मैं परिणामों की एक तालिका प्रदर्शित करूंगा creation time(इसका उद्देश्य टाइमस्टैम्प को प्रदर्शित करना है जो एक अलग समय क्षेत्र में बनाया गया हो सकता है, जैसा कि हम मानते हैं कि उपयोगकर्ता उस समय की तलाश कर रहा है, जहाँ वह जहाँ भी था, उसके लिए एक कार्यक्रम बनाया है।) , और संबंधित परिणामों के साथ नीचे दिए गए परिणामों की एक दूसरी तालिका प्रदर्शित करते हैं, शायद हेडर के साथ, "वह नहीं जो आप खोज रहे हैं? संबंधित परिणाम देखें" (इनमें बचे हुए यूटीसी और स्थानीय समय के परिणाम शामिल हैं)।

कुल मिलाकर, मैं UTC समय, स्थानीय समय, creation timeऔर creation time zone(और स्थानीय समय और उस क्षेत्र का समय क्षेत्र जहाँ इसे बनाया गया था) को प्रदर्शित करेगा, जो कि UTC समय द्वारा सॉर्ट किया गया है, इसलिए आप देख सकते हैं कि कौन सा ईवेंट पहले आता है, यदि दो अलग-अलग हैं घटनाओं को दो अलग-अलग समय क्षेत्रों में 9:00 के लिए निर्धारित किया गया था।

Comments

+1 मुझे सभी समय क्षेत्रों में सभी घटनाओं को दिखाने का विचार पसंद है जहां स्थानीय समय मेल खाता है; मैं SQL (24x BETWEENस्थितियों) से नाखुश हूँ ।

— आरोन दिगुल्ला