2008-09-30 11 views
6

मुझे डेटाबेस में विभिन्न विश्व क्षेत्रों के लिए ग्रीष्मकालीन समय (डेलाइट सेविंग टाइम) परिवर्तन-ओवर नियमों को स्टोर करने की आवश्यकता है। मेरे पास पहले से ही क्षेत्रों और उप-क्षेत्रों को संग्रहीत करने का एक तरीका है (इसलिए पूरे "half of Australia"/Arizona/Navaho समस्या का ख्याल रखा जाता है), लेकिन मुझे आश्चर्य है कि यह करने के लिए सबसे कुशल स्कीमा क्या होगा। दो विकल्प मैं उन्हें देखने के रूप में:ग्रीष्मकालीन समय नियमों का प्रतिनिधित्व करने का सबसे अच्छा तरीका क्या है?

  • एक मेज जो प्रत्येक वर्ष के लिए अद्वितीय एक पंक्ति है और इस क्षेत्र गर्मी के समय के लिए प्रारंभ और समाप्ति समय देने के साथ ही होता है विशिष्ट ऑफसेट के रूप में
  • जो भंडार एक मेज किया है एक सूत्र और प्रभावी तिथि सीमा प्रत्येक क्षेत्र के लिए (प्रभावी सीमा इसराइल की तरह क्षेत्रों के लिए आवश्यक)

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

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

क्या किसी के पास ऐसा कुछ करने का अनुभव है? इसी तरह, क्या किसी के पास कोई शानदार विकल्प है जो मुझे याद आ सकता है?

+1

मुझे लगता है कि हमें एक 'डीएसटी' टैग चाहिए, मेरे प्रोग्रामिंग का पचास प्रतिशत डीएसटी पर काबू पा रहा है। –

उत्तर

16

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

यही कारण है कि सभी ओएस विक्रेता वर्ष में एक या दो बार टाइमज़ोन फ़ाइल परिवर्तन करते हैं - उन्हें करना है, क्योंकि वे प्रोग्रामिंग रूप से 100% सटीक फ़ाइल उत्पन्न नहीं कर सकते हैं।

4

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

1

ओरेकल डीबीएमएस स्वचालित रूप से आपके लिए इसे संभालता है। तारीख को आंतरिक प्रतिनिधित्व में संग्रहीत किया जाता है (तर्क के लिए यूएमटी की कल्पना करें) और एक स्ट्रिंग में परिवर्तित होने पर टाइमज़ोन के नियमों के अनुसार स्वरूपित किया गया है।

यह समय के साथ परिवर्तन के दौरान क्या करना है इसके बारे में तर्क हल करता है। अर्थात। जब आप घड़ी को 1/2 घंटे वापस लेते हैं तो वास्तव में उसी दिन 3:25 बजे के 2 उदाहरण होते हैं।

2

समय क्षेत्र नियमों के बारे में जानकारी के सर्वोत्तम स्रोतों में से एक ओल्सन डेटाबेस है, जो elsie.nci.nih.gov से उपलब्ध था। सितंबर 2008 में, डेटा का वर्तमान संस्करण tzdata2008f.tar.gz था, कोड का वर्तमान संस्करण tzcode2008e.tar.gz था (और हाँ, डेटा तब था जब डेटा हमेशा जारी नहीं किया गया था)। यह कई अन्य प्रणालियों (विशेष रूप से, ओरेकल जानकारी सहित) के लिए जानकारी का स्रोत बनता है। एक मेलिंग सूची भी उपलब्ध है। जैसा कि आप देख सकते हैं, 2008 में अब तक डेटा के छह संस्करण रहे हैं; मेरे पास 2005r, 2006l, 2007k की प्रतियां मेरी मशीन पर छिपी हुई हैं, इसलिए चीजें अक्सर बदल सकती हैं।

आजकल (मार्च 2017), ओल्सन डेटाबेस आईएएनए से उपलब्ध है - https://iana.org/time-zones और ftp://ftp.iana.org/tz देखें (विशेष रूप से ftp://ftp.iana.org/tz/releases)।

सामान्य लोकेल डेटा रिपोजिटरी CLDR भी है जिसमें समय क्षेत्र के बारे में जानकारी भी है।

संबंधित मुद्दे

 संबंधित मुद्दे