मेरे पास एक डेटाबेस है जिसमें यूटीसी (जीएमटी +0) टाइमस्टैम्प शामिल हैं। यहां समस्या है: वे इंडियाना राज्य में हुई बिलिंग गतिविधि का उल्लेख करते हैं।जब समय क्षेत्र नियम बदलते हैं तो जावा में ऐतिहासिक रूप से सटीक स्थानीय समय पर मानचित्र कैसे करें?
कुछ पता हो सकता है, इंडियाना ...
- डेलाइट सेविंग टाइम का पालन नहीं किया था सब से पहले 2006 में (राज्य के सबसे ईएसटी साल भर था)।
- 2006 में ईएसटी बने रहने के लिए मतदान किया, लेकिन यू.एस.
- के बाकी हिस्सों के साथ डेलाइट सेविंग्स समय को देखना शुरू करने के लिए 2007 में इसके नियमों को संशोधित किया गया; अमेरिकी संघीय सरकार में संशोधित डेलाइट सेविंग टाइम ताकि आरंभ और अंत नियम
बदल क्योंकि इस डेटाबेस में timestamps सरकार बिलिंग गतिविधि का उल्लेख है, यह यूटीसी स्थानीय बार है कि ऐतिहासिक रूप से कर रहे हैं के रूप में रिपोर्ट timestamps के लिए वास्तव में आवश्यक है लेखा परीक्षा सटीकता को सुरक्षित रखने के लिए सटीक। ऐसे में तीन परिदृश्य हैं जो इंडियाना के लिए विशिष्ट रूप से लागू होते हैं: 2006 से पहले टाइमस्टैम्प 2006-2007 के बीच की तुलना में टाइमज़ोन नियमों का एक पूरी तरह से अलग सेट का उपयोग करते हैं, और 2007 के बाद के लोग टाइमज़ोन नियमों का एक और पूरी तरह से अलग सेट का उपयोग करते हैं। आप कल्पना कर सकते हैं कि इस डेटाबेस में इंडियाना के अलावा अन्य लोगों के लिए गतिविधि शामिल है, और इसलिए चीजें और भी जटिल हो जाती हैं।
जावा कैलेंडर और टाइमज़ोन एपीआई में कोई भी कक्षा नहीं है जो प्रोग्रामर को टाइमज़ोन नियमों के एक से अधिक सेट के साथ ऑब्जेक्ट्स बनाने की अनुमति देती है और इसलिए उन्हें यूटीसी टाइमस्टैम्प के सही मैपिंग के लिए ऐतिहासिक रूप से सटीक स्थानीय समय के लिए उपयोग नहीं किया जा सकता है यदि विशेष, लागू टाइमज़ोन नियम कभी भी बदलते हैं।
मैं तरीके समय क्षेत्र नियमों को उसके साथ स्थानों में ऐतिहासिक रूप से सटीक स्थानीय बार करने के लिए मैपिंग की समस्या का समाधान करने के बारे में सोचा है ...
डेटाबेस अद्यतन किया जा सकता है, ताकि यूटीसी timestamps साथ संग्रहित किया जा सकता स्थानीय समय ऑफसेट और डेलाइट बचत ऑफ़सेट के साथ। यहां समस्या यह है कि डेटाबेस का आकार थोड़ा बढ़ता है और यदि मौजूदा डेटाबेस बड़ा है, तो सभी तालिकाओं को अपडेट करने के लिए एक विस्तृत ऑफ़लाइन रखरखाव चक्र की आवश्यकता हो सकती है।
डेटाबेस अद्यतन किया जा सकता है ताकि उस विशेष टाइमस्टैम्प के लिए उपयुक्त विशेष टाइमज़ोन ऑब्जेक्ट प्रत्येक टाइमस्टैम्प के साथ संग्रहीत किया जा सके। हालांकि मुझे लगता है कि टाइमज़ोन ऑब्जेक्ट्स बहुत हल्के हैं, मुझे लगता है कि यह उपर्युक्त की तुलना में अधिक लचीला है लेकिन फिर भी कम वांछनीय है क्योंकि इसे प्रत्येक टाइमस्टैम्प के लिए एक वस्तु को बनाए रखने की आवश्यकता होती है।
एक कस्टम एपीआई विकसित की जा सकती है जो ब्याज के स्थानीय लोगों के लिए ऐतिहासिक रूप से सटीक नियमों के डेटाबेस से उपयुक्त टाइमज़ोन ऑब्जेक्ट बनाता है। यह समाधान अतिरिक्त प्रोसेसिंग की आवश्यकता के साथ पिछले दो समाधानों की बढ़ी हुई स्टोरेज आवश्यकता को प्रतिस्थापित करता है। प्रदर्शित होने के लिए आवश्यक प्रत्येक टाइमस्टैम्प का अर्थ एक नई वस्तु बनाना या कम से कम किसी ऑब्जेक्ट पूल से उचित ऑब्जेक्ट के साथ जोड़ना होगा। इसके अलावा, इसका मतलब है कि एक टाइमज़ोन डेटाबेस बनाना और प्रशासन करना।
जावा समय और कैलेंडर API की सीमाओं इस समस्या वास्तव में कठिन की तुलना में यह (होना चाहिए आप नहीं, उदाहरण के लिए, एक मौजूदा SimpleTimeZone वस्तु क्वेरी और यह क्या दिन के उजाले पूछ सकते हैं करने के लिए एक सुरुचिपूर्ण समाधान खोजने बना दिया है बचत नियम यह वास्तव में गन्दा कोड लिखने के बिना पालन करता है)।
मैं सिर्फ यह पूछना चाहूंगा कि किसी और ने इस तरह की स्थिति से निपटने से पहले और इसे कैसे संभाला है।
मुझे जावा नहीं पता, लेकिन मुझे पूरा यकीन है कि यह [ओल्सन टाइमज़ोन डेटाबेस] (http://www.iana.org/time-zones) का उपयोग करता है (जैसा कि [tzdata की सामग्री से प्रमाणित है) -जावा डेबियन पैकेज] (http://packages.debian.org/squeeze/tzdata-java))। यदि हां, तो आप नहीं चिंता करने के लिए कुछ भी है। ओल्सन डेटाबेस सभी ऐतिहासिक नियमों को संभालता है और आपको सही स्थानीय समय देना चाहिए। – Celada
यह बहुत दुखी है कि हमें राजनेताओं के केक को साफ करने के लिए कड़ी मेहनत करनी है। – irreputable