AT TIME ZONE - SQL Server 2016 में एक नई पसंदीदा विशेषता

AT TIME ZONE इतनी अच्छी सुविधा है और मैंने हाल ही में इस पर ध्यान नहीं दिया था, भले ही Microsoft के पास दिसंबर से इसके बारे में एक पेज है।

मैं ऑस्ट्रेलिया में एडिलेड में रहता हूं। और दुनिया के एक अरब से अधिक लोगों की तरह, एडिलेड के लोगों को आधे घंटे के समय क्षेत्र में रहने का सामना करना पड़ता है। सर्दियों के समय में, हम UTC+9:30 होते हैं, और गर्मियों के समय में हम UTC+10:30 होते हैं। सिवाय इसके कि यदि आप इसे उत्तरी गोलार्ध में पढ़ रहे हैं, तो आपको यह याद रखना होगा कि 'सर्दियों' से मेरा मतलब अप्रैल से अक्टूबर है। गर्मियों का समय अक्टूबर से अप्रैल तक होता है, और सांता क्लॉज़ अपने मोटे लाल सूट और दाढ़ी से पसीना बहाते हुए कोल्ड ड्रिंक के साथ समुद्र तट पर बैठते हैं। बेशक, जब तक वह जान बचा रहा है।

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

डेटाबेस सर्वर अक्सर यूटीसी में चलते हैं, क्योंकि एसक्यूएल सर्वर में यूटीसी और स्थानीय (और रिवर्स) के बीच कनवर्ट करने से निपटना आसान नहीं है। कई साल पहले मुझे याद है कि मुझे एक रिपोर्ट को ठीक करना था जिसमें प्रतिक्रिया समय के साथ हुई घटनाओं को सूचीबद्ध किया गया था (मैंने तब से इस बारे में ब्लॉग किया है)। SLA को मापना काफी सीधा था - मैं देख सकता था कि ग्राहक के काम के घंटों के दौरान एक घटना हुई, और उन्होंने एक घंटे के भीतर जवाब दिया। मैं देख सकता था कि एक और घटना काम के घंटों के बाहर हुई, और प्रतिक्रिया दो घंटे के भीतर थी। समस्या तब आई जब उस अवधि के अंत में एक रिपोर्ट तैयार की गई जब समय क्षेत्र बदल गया, जिससे एक घटना जो वास्तव में शाम 5:30 बजे (घंटों के बाहर) हुई, को सूचीबद्ध किया गया जैसे कि यह शाम 4:30 बजे (घंटों के भीतर) हुई हो। . प्रतिक्रिया में लगभग 90 मिनट का समय लगा था, जो ठीक था, लेकिन रिपोर्ट कुछ और ही दिखा रही थी।

यह सब SQL सर्वर 2016 में तय किया गया है।

SQL सर्वर 2016 में AT TIME ZONE का उपयोग कैसे करें

अब, AT TIME ZONE के साथ, यह कहने के बजाय:'20160101 00:00 +10:30', मैं एक डेटाटाइम मान से शुरू कर सकता हूं जिसमें समय क्षेत्र ऑफ़सेट नहीं है, और यह समझाने के लिए AT TIME ZONE का उपयोग करें कि यह एडिलेड में है।

कन्वर्ट चुनें (डेटाटाइम,'20160101 00:00') टाइम ज़ोन 'सेन. ऑस्ट्रेलिया मानक समय'; -- 2016-01-01 00:00:0000 +10:30

और इसे फिर से AT TIME ZONE जोड़कर अमेरिकी समय में बदला जा सकता है।

कन्वर्ट चुनें (डेटाटाइम,'20160101 00:00') टाइम ज़ोन 'सेन. ऑस्ट्रेलिया मानक समय' AT TIME ZONE 'US पूर्वी मानक समय'; - 2015-12-31 08:30:00:00 -05:00

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

लेकिन इसकी लंबी हवा के बावजूद, मुझे यह पसंद है, क्योंकि किसी भी समय मुझे यह पता लगाने की ज़रूरत नहीं थी कि एडिलेड +10:30 में था, या वह पूर्वी -5:00 था - मुझे बस नाम से समय क्षेत्र जानने की जरूरत थी। यह पता लगाना कि मेरे लिए डेलाइट सेविंग लागू होनी चाहिए या नहीं, और मुझे कुछ बेसलाइन स्थापित करने के लिए स्थानीय से यूटीसी में कोई रूपांतरण नहीं करना पड़ा।

यह विंडोज रजिस्ट्री का उपयोग करके काम करता है, जिसमें वह सारी जानकारी है, लेकिन दुख की बात है कि समय में पीछे मुड़कर देखने पर यह सही नहीं है। ऑस्ट्रेलिया ने 2008 में तारीखें बदल दीं, और अमेरिका ने 2005 में अपनी तारीखें बदल दीं - दोनों देश साल के अधिक समय के लिए दिन के उजाले की बचत कर रहे हैं। AT TIME ZONE इसे समझता है। लेकिन ऐसा प्रतीत नहीं होता है कि ऑस्ट्रेलिया में वर्ष 2000 में सिडनी ओलंपिक के लिए धन्यवाद, ऑस्ट्रेलिया ने लगभग दो महीने पहले दिन के उजाले की बचत शुरू की थी। यह थोड़ा निराशाजनक है, लेकिन यह एसक्यूएल की गलती नहीं है - हमें इसके लिए विंडोज़ को दोष देना होगा। मुझे लगता है कि विंडोज रजिस्ट्री को उस वर्ष के आसपास चला गया हॉटफिक्स याद नहीं है। (स्वयं को ध्यान दें:मुझे इसे ठीक करने के लिए Windows टीम में किसी से पूछने की आवश्यकता हो सकती है...)

हालांकि उपयोगिता अभी भी जारी है!

उस समय क्षेत्र का नाम स्थिर होने की भी आवश्यकता नहीं है। मैं वेरिएबल पास कर सकता हूं, और यहां तक ​​कि कॉलम का उपयोग भी कर सकता हूं:

 PeopleAndTZs AS के साथ (चुनें * FROM (VALUES ('Rob', 'Cen. Australia Standard Time'), ('Paul', 'New Zealand Standard Time'), ('Aaron', 'US Eastern Standard Time') ) ) t (व्यक्ति, tz)) tz.person का चयन करें, SYSDATETIMEOFFSET () टाइम ज़ोन tz.tz से PeopleAndTZs tz; /* रोब 2016-07-18 18:29:11.9749952 +09:30 पॉल 2016-07-18 20:59:11.9749952 +12:00 हारून 2016-07-18 04:59:11.9749952 -04:00*/

(क्योंकि मैं यहां एडिलेड में शाम 6:30 बजे से पहले दौड़ा था, जो न्यूजीलैंड में लगभग 9 बजे होता है, जहां पॉल है, और आज सुबह लगभग 5 बजे अमेरिका के पूर्वी हिस्से में जहां हारून है।)

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

वे समय क्षेत्र sys.time_zone_info . में सूचीबद्ध हैं , साथ ही वर्तमान ऑफ़सेट क्या है, और क्या वर्तमान में डेलाइट सेविंग लागू है।

sys.time_zone_info से पंक्तियों का नमूनाकरण

मुझे केवल वास्तव में दिलचस्पी है कि नाम क्या है, लेकिन वैसे भी। और यह देखना दिलचस्प है कि "ऑस सेंट्रल डब्ल्यू मानक समय" नामक एक समय क्षेत्र है जो तिमाही घंटे पर है। जाओ पता लगाओ। यह भी ध्यान देने योग्य है कि स्थानों को उनके मानक समय नाम का उपयोग करने के लिए संदर्भित किया जाता है, भले ही वे वर्तमान में डीएसटी देख रहे हों। जैसे कि उलानबटार उस सूची में ऊपर है, जिसे उलानबटार डेलाइट टाइम के रूप में सूचीबद्ध नहीं किया गया है। जब लोग AT TIME ZONE का उपयोग करना शुरू करते हैं, तो इससे लोगों को परेशानी हो सकती है।

क्या AT TIME ZONE प्रदर्शन संबंधी समस्याएं पैदा कर सकता है?

अब, मुझे यकीन है कि आप सोच रहे होंगे कि AT TIME ZONE के उपयोग का अनुक्रमण पर क्या प्रभाव पड़ सकता है।

योजना के आकार के संदर्भ में, यह सामान्य रूप से डेटाटाइमसेट से निपटने के लिए अलग नहीं है। यदि मेरे पास डेटाटाइम मान हैं, जैसे कि एडवेंचरवर्क्स कॉलम Sales.SalesOrderHeader.OrderDate (जिस पर मैंने rf_IXOD नामक एक इंडेक्स बनाया है), तो यह दोनों क्वेरी चला रहे हैं:

सेल्स से ऑर्डरडेट, सेल्सऑर्डरआईडी चुनें।सेल्सऑर्डरहेडर जहां ऑर्डरडेट>=कन्वर्ट (डेटाटाइम,'20110601 00:00') टाइम ज़ोन 'यूएस ईस्टर्न स्टैंडर्ड टाइम' और ऑर्डरडेट <कन्वर्ट (डेटटाइम,'20110701 00:00') पर समय क्षेत्र 'यूएस पूर्वी मानक समय';

और यह प्रश्न:

 सेल्स से ऑर्डरडेट, सेल्सऑर्डर आईडी चुनें। सेल्स ऑर्डर हैडर जहां ऑर्डरडेट> =कन्वर्ट (डेटाटाइमऑफसेट, '20110601 00:00 -04:00') और ऑर्डरडेट <कन्वर्ट (डेटटाइमऑफसेट, '20110701 00:00 -04:00');

दोनों ही मामलों में, आपको ऐसे प्लान मिलते हैं जो इस तरह दिखते हैं:

लेकिन अगर हम थोड़ा और बारीकी से देखें, तो एक समस्या है।

जो AT TIME ZONE का उपयोग करता है, वह आँकड़ों का बहुत अच्छी तरह से उपयोग नहीं करता है। यह सोचता है कि यह उस इंडेक्स सीक से 5,170 पंक्तियों को देखने जा रहा है, जबकि वास्तव में केवल 217 है। 5,170 क्यों? खैर, हारून की हालिया पोस्ट, "पेइंग अटेंशन टू एस्टीमेट्स", इसे पॉल से "एकाधिक विधेय के लिए कार्डिनैलिटी एस्टीमेशन" पोस्ट का हवाला देते हुए बताती है। 5,170 31,465 है (तालिका में पंक्तियाँ) * 0.3 * sqrt(0.3)।

दूसरी क्वेरी 217 का अनुमान लगाते हुए सही हो जाती है। कोई फ़ंक्शन शामिल नहीं है, आप देखें।

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

अगर मैं अतिरिक्त विधेय जोड़ता हूं जो मुझे पता है कि कोई समस्या नहीं हो सकती है, तो मेरे अनुमान वास्तव में और भी कम हो जाते हैं - 89.9 पंक्तियों तक।

सेल्स से ऑर्डरडेट, सेल्सऑर्डरआईडी चुनें।सेल्सऑर्डरहेडर जहां ऑर्डरडेट>=कन्वर्ट (डेटाटाइम,'20110601 00:00') टाइम ज़ोन 'यूएस ईस्टर्न स्टैंडर्ड टाइम' और ऑर्डरडेट <कन्वर्ट (डेटटाइम,'20110701 00:00') पर टाइम ज़ोन 'यूएस ईस्टर्न स्टैंडर्ड टाइम' और ऑर्डरडेट> =कन्वर्ट (डेटाटाइमऑफ़सेट, '20110601 00:00 +14:00') और ऑर्डरडेट <कन्वर्ट (डेटटाइमऑफ़सेट, '20110701 00:00 -12:00');

बहुत अधिक पंक्तियों का अनुमान लगाने का मतलब है कि बहुत अधिक मेमोरी आवंटित की गई है, लेकिन बहुत कम का अनुमान लगाने से बहुत कम मेमोरी हो सकती है, संभावित रूप से समस्या को ठीक करने के लिए स्पिल की आवश्यकता होती है (जो अक्सर प्रदर्शन के दृष्टिकोण से विनाशकारी हो सकती है)। खराब अनुमान कैसे खराब हो सकते हैं, इस बारे में अधिक जानकारी के लिए हारून की पोस्ट पढ़ें।

जब मैं पहले से उन लोगों के लिए प्रदर्शित मूल्यों को संभालने के तरीके पर विचार करता हूं, तो मैं इस तरह के प्रश्नों का उपयोग कर सकता हूं:

 PeopleAndTZs AS के साथ (चुनें * FROM (VALUES ('Rob', 'Cen. Australia Standard Time'), ('Paul', 'New Zealand Standard Time'), ('Aaron', 'US Eastern Standard Time') ) ) t (व्यक्ति, tz)) सेलेक्ट tz.person, o.SalesOrderID, o.OrderDate at TIME ZONE 'UTC' AT TIME ZONE tz.tzFROM PeopleAndTZs tzCROSS जॉइन सेल्स.SalesOrderHeader oWHERE o.SalesOrderID AND 44010; 

 और यह योजना प्राप्त करें:
 

 
 

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

 AT TIME ZONE से पहले, मेरे पसंदीदा में से एक, लेकिन अक्सर इसकी सराहना नहीं की जाती थी, SQL 2008 की विशेषताएँ डेटा प्रकार डेटाटाइमऑफ़सेट थीं। यह दिनांक/समय डेटा को समय क्षेत्र के साथ भी संग्रहीत करने की अनुमति देता है, जैसे कि '20160101 00:00 +10:30', जब हमने इस वर्ष एडिलेड में नया साल मनाया। यह देखने के लिए कि वह यूएस ईस्टर्न में कब था, मैं SWITCHOFFSET फ़ंक्शन का उपयोग कर सकता हूं।
 
चुनें स्विचऑफ़सेट('20160101 00:00 +10:30', '-05:00'); - 2015-12-31 08:30:000000000 -05:00
 

 यह समय में एक ही क्षण है, लेकिन दुनिया के एक अलग हिस्से में है। अगर मैं उत्तरी कैरोलिना या न्यूयॉर्क में किसी को फोन पर होता, उन्हें नए साल की शुभकामनाएं देता, क्योंकि एडिलेड में अभी आधी रात थी, तो वे कह रहे होंगे "आपका क्या मतलब है? नव वर्ष की पूर्व संध्या पर यहाँ अभी भी नाश्ते का समय है!"
 

 समस्या यह है कि ऐसा करने के लिए, मुझे यह जानना होगा कि जनवरी में एडिलेड +10:30 है और यूएस ईस्टर्न -5:00 है। और यह अक्सर दर्द होता है। खासकर अगर मैं मार्च के अंत, अप्रैल की शुरुआत, अक्टूबर की शुरुआत, नवंबर की शुरुआत के बारे में पूछ रहा हूं - साल के वे समय जब लोग यह सुनिश्चित नहीं कर सकते कि दूसरे देशों के लोग किस समय क्षेत्र में थे क्योंकि वे दिन के उजाले की बचत के लिए एक घंटे से बदलते हैं, और वे सभी अलग-अलग नियमों के अनुसार ऐसा करते हैं। मेरा कंप्यूटर मुझे बताता है कि लोग अब किस समय क्षेत्र में हैं, लेकिन यह बताना बहुत कठिन है कि वे वर्ष के अन्य समय में किस समय क्षेत्र में होंगे। 
 

 समय क्षेत्रों के बीच रूपांतरण के बारे में कुछ अन्य जानकारी के लिए, और हारून जैसे लोगों ने दिन के उजाले की बचत से कैसे निपटा है, निम्नलिखित लिंक देखें:
 
 
एक पुरानी रिपोर्ट को ठीक करने के लिए AT TIME ZONE का उपयोग करना (वह मैं हूं!) 
SQL सर्वर में समय क्षेत्रों के बीच रूपांतरण को संभालें - भाग 1 
SQL सर्वर में समय क्षेत्रों के बीच रूपांतरण को संभालें - भाग 2 
SQL सर्वर में समय क्षेत्रों के बीच रूपांतरण को संभालें - भाग 3
 

 और कुछ आधिकारिक Microsoft दस्तावेज़:
 
 
समय क्षेत्र में (लेनदेन-एसक्यूएल) 
sys.time_zone_info (ट्रांजैक्ट-एसक्यूएल) 
डेलाइट सेविंग टाइम सहायता और समर्थन
 
क्या आपको AT TIME ZONE का उपयोग करना चाहिए?
 

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

 यह वास्तव में SQL सर्वर 2016 की मेरी पसंदीदा विशेषताओं में से एक है। मैं बहुत लंबे समय से कुछ इस तरह से रो रहा हूं।
 

 ओह, और आधे घंटे के समय क्षेत्र में उन अरब लोगों में से अधिकांश भारत में हैं। लेकिन आप शायद पहले से ही जानते थे कि…