SQL सर्वर 2012 में SQLCLR असेंबली में TimeZoneInfo का उपयोग कैसे करता है?

अपडेट किया गया उत्तर

मैंने मूल उत्तर में जिस उपयोगिता के बारे में बात की थी, मैंने लिखा है, जिसे आप यहां पा सकते हैं ।

साथ ही, SQL Server 2016 (और Azure SQL डेटाबेस) के रूप में, अब आप AT TIME ZONE का उपयोग कर सकते हैं समय क्षेत्रों के बीच कनवर्ट करने के लिए कीवर्ड।

मूल उत्तर

दुर्भाग्य से, SQL सर्वर में समय क्षेत्रों के साथ काम करने के लिए कोई बढ़िया समाधान नहीं है।

मैंने यह वाला के साथ, आपके द्वारा लिंक की गई समस्या की गहन जांच-पड़ताल की। भी। कोई अंतर्निहित समय क्षेत्र फ़ंक्शन नहीं हैं, और TimeZoneInfo . का कोई उपयोग नहीं है SQLCLR में असेंबली को "असुरक्षित" के रूप में पंजीकृत करने की आवश्यकता होती है। यह आमतौर पर वांछित नहीं है।

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

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

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

TimeZoneInfo बदलने की संभावना नहीं है। इसलिए जब तक SQL सर्वर टीम कभी भी समय क्षेत्र के कार्यों को सीधे SQL सर्वर में ठीक से नहीं लाती है (जैसे Oracle और Postgres करते हैं), तो आपके पास केवल कुछ विकल्प हैं:

• डेटा स्तर में समय क्षेत्र रूपांतरणों का प्रयास न करें। datetime के साथ काम करें या datetime2 UTC में मान, या datetimeoffset . का उपयोग करें किसी भी ऑफसेट के साथ मान। लेकिन अनुप्रयोग परत में समय क्षेत्रों के बीच सभी रूपांतरण करें। अभी के लिए यह मेरी सबसे अच्छी सिफारिश है।

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

• xp_regread सक्षम करें और विंडोज़ रजिस्ट्री कुंजियों से सीधे टाइमज़ोन डेटा के साथ काम करें। अपडेट आपके लिए किए जाएंगे, लेकिन इन कार्यों को लिखने में आपको अभी भी वही चुनौतियां हैं। और रजिस्ट्री रीडिंग को सक्षम करना उतना ही सुरक्षा जोखिम हो सकता है जितना कि असुरक्षित सीएलआर असेंबलियों को सक्षम करना।

एक और विचार जिस पर मैं विचार कर रहा हूं वह है एक IANA/Olson TZDB लिखना पार्सर और विशेष रूप से SQL सर्वर के लिए कार्य करता है। यह ऊपर दिए गए विकल्प 2 के समान होगा, लेकिन इसे बनाए रखने योग्य तरीके से और विंडोज टाइम ज़ोन के बजाय IANA मानक डेटा के साथ किया जाएगा। हो सकता है कि मैं किसी दिन इस तक पहुंच जाऊं, या हो सकता है कि कोई मुझे इसके लिए हरा दे। दोबारा, मैं किसी भी मौजूदा परियोजना से अवगत नहीं हूं जो ऐसा करता है, लेकिन अगर किसी को एक के बारे में पता है, तो कृपया मुझे टिप्पणियों में बताएं। (हो गया - शीर्ष पर अपडेट देखें )

SWITCHOFFSET के संबंध में - यह तभी काम करता है जब आप पहले से ही लक्ष्य ऑफसेट को जानते हैं। यह आधी लड़ाई है, और शायद यही कारण है कि Microsoft अभी भी datetimeoffset marks को चिह्नित करता है दस्तावेज़ में "डेलाइट सेविंग अवेयरनेस" के रूप में नहीं ।