टिप्पणी:1.
पिछले लेख में, "
टाइम ज़ोन " मैंने "
टाइम ज़ोन " के रूप में अनुवाद किया था, क्योंकि यह एक विशिष्ट नाम के साथ यूएस टाइम ज़ोन का प्रश्न था। इस मामले में, "
समय क्षेत्र " का उपयोग करना अधिक सही है। यहां अधिक सही अनुवाद का उपयोग किया जाता है।
2. विकिपीडिया के एक छोटे से साइडबार से आपको अंदाजा होगा कि UTC क्या है और यह GMT से कैसे भिन्न है?
समन्वित यूनिवर्सल टाइम (UTC) वह मानक है जिसके द्वारा समाज घंटे और समय को नियंत्रित करता है। यह परमाणु समय से सेकंड की एक पूर्णांक संख्या और सार्वभौमिक समय UT1 से सेकंड के एक अंश संख्या द्वारा भिन्न होता है।UTC को अप्रचलित ग्रीनविच मीन टाइम (GMT) के बजाय पेश किया गया था। जीएमटी स्केल एक असमान स्केल है और पृथ्वी के दैनिक रोटेशन से संबंधित होने के कारण एक नई यूटीसी टाइमलाइन शुरू की गई है। यूटीसी स्केल एक समान परमाणु समय स्केल (टीएआई) पर आधारित है और नागरिक उपयोग के लिए अधिक सुविधाजनक है।दुनिया भर के टाइम ज़ोन को यूटीसी से सकारात्मक और नकारात्मक ऑफसेट के रूप में व्यक्त किया जाता है।यह याद रखना चाहिए कि यूटीसी समय का अनुवाद सर्दियों में या गर्मियों में नहीं किया जाता है। इसलिए, उन जगहों के लिए जहां दिन के समय की बचत के लिए स्विच है, यूटीसी के सापेक्ष ऑफसेट बदलता है।अब हम तारीखों और समय जैसी संस्थाओं की संरचना के साथ काम करना जारी रखते हैं।
Noda Time के बारे में एक ट्वीट पोस्ट करने के कुछ समय बाद, लोग मुझसे पूछने लगे कि Noda Time का उपयोग करने का क्या मतलब है - लोगों का मानना था कि .NET में दिनांक और समय के लिए समर्थन काफी अच्छा था। बेशक, मैंने उनका कोड नहीं देखा था, लेकिन मुझे संदेह है कि दिनांक के साथ काम करने वाला लगभग कोई भी कोड आधार स्पष्ट हो जाएगा यदि यह Noda Time का उपयोग करता है, और यह भी, संभवतः, उस दृष्टिकोण के कारण अधिक सही हो जाएगा, जिसके द्वारा Noda Time आपको स्वीकार करने के लिए बाध्य करता है .NET में कुछ समाधान स्पष्ट नहीं हैं। इस लेख में, हम दिनांक और समय के साथ काम करने के लिए .NET एपीआई की कमियों पर चर्चा करेंगे। इस विषय पर मेरा रवैया कुछ हद तक पक्षपाती लगता है, लेकिन मुझे उम्मीद है कि यह लेख बीसीएल (बेस क्लास लाइब्रेरी -
लगभग अनुवादक ) पर काम करने वाली टीम के लिए अपमानजनक नहीं दिखता है - क्योंकि, अन्य चीजों के अलावा, वे उन परिस्थितियों में काम करते हैं जो बल देते हैं। COM, आदि के साथ खाते में बातचीत
DateTime का क्या अर्थ है?जब मैं स्टैक ओवरफ्लो वेबसाइट पर एक सवाल आता हूं जो कहता है कि डेटटाइम वह नहीं कर रहा है जो उससे अपेक्षित है, तो मैं अक्सर खुद को प्रतिबिंब की स्थिति में पाता हूं - क्या वास्तव में संकेतित मूल्य का प्रतिनिधित्व करना चाहिए? उत्तर सरल है - तारीख और समय, सही? लेकिन जैसे ही आप समस्या से अधिक सावधानी से निपटना शुरू करते हैं, सब कुछ बहुत अधिक जटिल हो जाता है। उदाहरण के लिए, मान लीजिए कि नीचे दिए गए कोड में
दो संपत्तियों पर कॉल के बीच घड़ी टिक नहीं करती है । तो रहस्य चर क्या मूल्य लेगा?
DateTime utc = DateTime.UtcNow;<br>DateTime local = DateTime.Now;<br>bool mystery = local == utc;मुझे ईमानदारी से पता नहीं है कि इस कोड का निष्पादन किसके लिए होगा। तीन संस्करण हैं, जिनमें से प्रत्येक का कम या ज्यादा औचित्य है:
- मान हमेशा सत्य होगा : दो मान समय में एक ही क्षण से जुड़े होते हैं, केवल एक स्थानीय रूप से व्यक्त किया जाता है, और दूसरा सार्वभौमिक है
- मान हमेशा गलत होगा : दो मान दो भिन्न दिनांक मानों का प्रतिनिधित्व करते हैं, अर्थात् स्वतः असमान
- और फिर से सच है - यदि आपका स्थानीय समय क्षेत्र यूटीसी ( समन्वित यूनिवर्सल टाइम ) के साथ सिंक्रनाइज़ है, अर्थात। तब जब समय क्षेत्र को ध्यान में नहीं रखा जाता है - दोनों मूल्य समान होंगे
मुझे बहुत परवाह नहीं है कि कौन सा उत्तर सही है - कोड व्यवहार के तर्क की गैर-स्पष्टता गहरी समस्याओं का संकेत है। वास्तव में, DateTime.Kind संपत्ति में सब कुछ वापस आ जाता है, जो DateTime को तीन प्रकार के मूल्यों का प्रतिनिधित्व करने की अनुमति देता है:
DateTimeKind.Utc : UTC दिनांक और समय
DateTimeKind.Local : दिनांक और समय उस प्रणाली के लिए स्थानीय जिसमें कोड निष्पादित होता है
DateTimeKind.Unspecified : मम्म, धूर्तता से। इस पर निर्भर करता है कि आप इसके साथ क्या करते हैं।
एक संपत्ति के मूल्य का अलग-अलग कार्यों पर एक अलग प्रभाव पड़ता है। उदाहरण के लिए, यदि आप ToUniversalTime () विधि को "अनिर्दिष्ट" DateTime मान पर लागू करते हैं, तो विधि यह मान लेगी कि आप स्थानीय मान को बदलने का प्रयास कर रहे हैं। दूसरी ओर, यदि आप ToLocalTime () पद्धति को "अनिर्दिष्ट" DateTime मान पर लागू करते हैं, तो आपको यह मानकर बनाया जाएगा कि मूल रूप से UTC में आपका मूल्य था। यह व्यवहार का एक मॉडल है।
यदि आप DateTimeOffset DateTime और TimeSpan से बनाते हैं, तो व्यवहार थोड़ा अलग है:
- UTC मान के साथ सब कुछ सरल है - हम UTC को स्थानांतरित करते हैं, हम "UTC + निर्दिष्ट ऑफ़सेट" प्रतिनिधित्व प्राप्त करना चाहते हैं
- स्थानीय मान कभी-कभी ही सही होता है: निर्माणकर्ता यह जाँचता है कि सिस्टम द्वारा उपयोग किए गए समय क्षेत्र में निर्दिष्ट स्थानीय समय में UTC से ऑफ़सेट डिफ़ॉल्ट रूप से आपके द्वारा निर्दिष्ट ऑफसेट के साथ है।
- एक अनिर्दिष्ट मूल्य ("अनिर्दिष्ट") हमेशा सही होता है और कुछ अनिर्दिष्ट समय क्षेत्र में स्थानीय समय का प्रतिनिधित्व करता है ताकि उस समय ऑफसेट सही हो।
मुझे आपके बारे में पता नहीं है, लेकिन मेरे लिए यह स्थिति थोड़ी सी हिस्टीरिया का कारण बनती है। यह "संख्यात्मक" प्रकार के होने के समान है जिसमें अंकों का एक अनुक्रम होता है, लेकिन आपको दशमलव या हेक्साडेसिमल अंक का पता लगाने के लिए किसी अन्य संपत्ति का उपयोग करना चाहिए, और कभी-कभी इसका उत्तर "ठीक है, आपको क्या लगता है?"
बेशक, .NET 1.1 में, DateTimeKind संपत्ति पूरी तरह से अनुपस्थित थी। इसका मतलब यह नहीं है कि समस्या मौजूद नहीं थी। इसका मतलब है कि एक भ्रामक व्यवहार जो एक प्रकार को अर्थ देने की कोशिश करता है जो विभिन्न प्रकार के मूल्यों को संग्रहीत करता है और कुछ भी सुसंगत होने की कोशिश नहीं करता है। यह इस धारणा पर आधारित था कि तिथि मान स्थायी रूप से अनिर्दिष्ट है।
क्या DateTimeOffset संरचना का उपयोग करने से समस्या ठीक हो जाती है?सब ठीक है। अब हम जानते हैं कि हम वास्तव में डेटाइम प्रकार की तरह नहीं हैं। क्या DateTimeOffset हमारी मदद करेगा? हाँ, भाग में। दिनांक टाइमऑफसेट के प्रकार का एक स्पष्ट अर्थ है: इसमें UTC से निर्दिष्ट ऑफसेट के साथ स्थानीय दिनांक और समय शामिल है। शायद अब मुझे पीछे हटना चाहिए और आपको समझाना चाहिए कि "स्थानीय" तारीख और समय से मेरा क्या मतलब है, साथ ही साथ (लौकिक) क्षण भी।
स्थानीय दिनांक और समय एक विशिष्ट समय क्षेत्र से बंधे नहीं हैं। वर्तमान क्षण बाद में है या पहले "16:00 मार्च 13, 2012"? इस पर निर्भर करता है कि आप इस दुनिया में कहां हैं (यह, वैसे, मैं अभी भी गैर-आईएसओ कैलेंडर को ध्यान में नहीं रखता हूं)। इसलिए, DateTimeOffset में एक घटक होता है जो समय क्षेत्र से स्वतंत्र होता है (यह "16:00 ...") है, लेकिन UTC से एक ऑफसेट भी है - जो एक समय रेखा पर एक
बिंदु पर इसके रूपांतरण की संभावना को इंगित करता है। यदि आप सापेक्षता के सिद्धांत को अनदेखा करते हैं, तो ग्रह पर सभी लोग एक ही समय में वर्तमान क्षण का अनुभव करते हैं। यदि मैं अपनी उंगलियों को काटता हूं (असीम रूप से तेज), तो ब्रह्मांड में कोई भी घटना इस घटना से पहले या बाद में होगी। आप किसी विशेष समय क्षेत्र में थे या नहीं, इससे कोई फर्क नहीं पड़ता। इस संबंध में, स्थानीय तारीख और समय की तुलना में, क्षण वैश्विक हैं, जो प्रत्येक व्यक्ति समय में एक विशेष क्षण में देख सकता है।
(क्या आप अभी भी यहां हैं? चलिए जारी रखते हैं - मुझे उम्मीद है कि इस अनुच्छेद में पिछले पैराग्राफ सबसे कठिन था। हालांकि यह एक बहुत ही महत्वपूर्ण अवधारणा का वर्णन करता है।)
इसलिए, DateTimeOffset समय में (वैश्विक) बिंदु को संदर्भित करता है, लेकिन स्थानीय दिनांक और समय के साथ भी काम करता है। इसका मतलब है कि यह संरचना स्थानीय तिथियों और समय का प्रतिनिधित्व करने के लिए एक आदर्श प्रकार नहीं है - लेकिन डेटटाइम नहीं है। DateTimeKind के साथ DateTime.Local संपत्ति सेट वास्तव में समान कारणों के लिए स्थानीय नहीं है - यह उस सिस्टम पर डिफ़ॉल्ट समय क्षेत्र से बंधा है जिसमें इसका उपयोग किया जाता है। दिनांक समयरेखा प्रपत्र का DateTimeKind.Unspecified कुछ मामलों में थोड़ा बेहतर है - उदाहरण के लिए, जब DateTimeOffset बनाते हैं - लेकिन शब्दार्थ अन्य मामलों में अजीब लगते हैं, जैसा कि ऊपर वर्णित है। परिणामस्वरूप, न तो DateTimeOffset और न ही DateTime वास्तव में स्थानीय दिनांक और समय प्रदर्शित करने के लिए अच्छे प्रकार हैं।
DateTimeOffset संरचना भी एक विशिष्ट समय क्षेत्र के लिए बाध्य करने के लिए एक अच्छा विकल्प नहीं है, क्योंकि यह पता नहीं है कि किस समय क्षेत्र ने पहले ऑफसेट को दिया था। .NET 3.5 में एक काफी पर्याप्त TimeZoneInfo वर्ग है, लेकिन ऐसा कोई प्रकार नहीं है जो कहता है कि "विशिष्ट समय क्षेत्र में स्थानीय समय"। इसलिए, DateTimeOffset का एक वैरिएबल होने से, आप एक निश्चित समय क्षेत्र में विशिष्ट समय को जानते हैं, लेकिन आपको नहीं पता कि स्थानीय समय एक मिनट बाद क्या होगा, क्योंकि इस क्षेत्र के लिए ऑफसेट बदल सकता है (आमतौर पर दिन के समय की बचत के कारण)।
तारीखों और समय के बारे में क्या?इससे पहले, हमने केवल "तारीख और समय" स्टोर के मूल्यों पर चर्चा की। और उन प्रकारों के बारे में क्या है जिनमें केवल दिनांक या केवल समय संग्रहीत है? अक्सर, निश्चित रूप से, आपको केवल तारीख को संग्रहीत करने की आवश्यकता होती है, लेकिन ऐसे समय होते हैं जब आपको केवल समय संग्रहीत करने की आवश्यकता होती है।
और फिर भी, हाँ, आप दिनांक - नरक को संग्रहीत करने के लिए DateTime प्रकार का उपयोग कर सकते हैं, हाँ यहाँ तक कि DateTime.Date गुण भी है जो एक विशिष्ट तिथि और समय के लिए एक तारीख देता है ... लेकिन केवल एक अन्य DateTime मान आधी रात को सेट किए गए समय के साथ। यह एक अलग प्रकार के होने के समान नहीं है जो कि "केवल दिनांक" (या "केवल समय" के रूप में पहचानना आसान है - .NET ऐसा करने के लिए TimeSpan का उपयोग करता है, जो फिर से मुझे वास्तव में सही नहीं लगता है)।
और समय क्षेत्रों के बारे में क्या? यहाँ TimeZoneInfo काफी सभ्य दिखता है।जैसा कि मैंने कहा, TimeZoneInfo बुरा नहीं है। सच है, उसके पास दो बड़ी समस्याएं हैं और कुछ छोटी हैं।
सबसे पहले, विंडोज टाइमज़ोन पहचानकर्ताओं को एक आधार के रूप में लिया जाता है। एक ओर, यह तार्किक है, लेकिन दूसरी ओर, यह ऐसा कुछ नहीं है जिसका शेष दुनिया उपयोग करती है। सभी गैर-विंडोज सिस्टम जिन्हें मैंने क्रमशः ओल्सन टाइम ज़ोन डेटाबेस (जिसे tz या ज़ोनइन्फो के रूप में भी जाना जाता है) का उपयोग किया है, इसके अपने स्वयं के पहचानकर्ता हैं। शायद आपने उन्हें देखा - "यूरोप / लंदन" या "अमेरिका / लॉस_अंगेल्स" - ये ओल्सन के पहचानकर्ता हैं। एक वेब सेवा के साथ काम करना जो जियोइन्फॉर्मेशन प्रदान करता है - संभावना है कि यह ओल्सन पहचानकर्ताओं का उपयोग करता है। एक अलग कैलेंडर प्रणाली के साथ काम करें - संभावना है कि यह ओल्सन पहचानकर्ताओं का भी उपयोग करता है। यहां भी समस्याएं हैं। उदाहरण के लिए, पहचानकर्ताओं की स्थिरता के साथ कि
यूनिकोड कंसोर्टियम सीएलडीआर का उपयोग करके हल करने
की कोशिश कर रहा है ... लेकिन कम से कम आपके पास एक अच्छा मौका है। यह बहुत अच्छा होगा अगर TimeZoneInfo ने दो पहचानकर्ता योजनाओं के बीच पत्राचार स्थापित करने के लिए किसी तरह की पेशकश की या इसे .NET में कहीं और लागू किया जाएगा। (नोदा टाइम पहचानकर्ताओं के दोनों सेटों के बारे में जानता है, हालांकि मैपिंग अभी तक सभी के लिए उपलब्ध नहीं है। यह अंतिम रिलीज से पहले तय हो जाएगा।)
दूसरे, यह वर्ग DateTime और DateTimeOffset के उपयोग पर आधारित है, अर्थात इसका उपयोग करते समय आपको सावधान रहना चाहिए - यदि आप एक प्रकार का डेटाइम सेट करते हैं और दूसरे को पास करते हैं, तो आपको समस्या हो सकती है। वर्ग काफी अच्छी तरह से प्रलेखित है, लेकिन ईमानदार होने के लिए, इस तरह की बात को स्पष्ट रूप से समझा जाना संघर्षपूर्ण शब्दों का उपयोग करके स्थिति को भ्रमित किए बिना काफी मुश्किल है।
स्थानीय तिथियों और समय के अस्पष्ट या गलत मूल्यों के साथ समस्याएं हैं। वे गर्मियों / सर्दियों के समय में संक्रमण के दौरान होते हैं: यदि समय को आगे बढ़ाया जाता है (उदाहरण के लिए, 1:00 से 2:00 तक), तो गलत स्थानीय समय होने का एक मौका है (उदाहरण के लिए, 1:30 उस दिन नहीं आएगा)। यदि घड़ी को वापस सेट किया जाता है (उदाहरण के लिए, 2:00 से 1:00 तक), तो यह अस्पष्टता की ओर जाता है: 1.30 दो बार होता है। आप स्पष्ट रूप से TimeZoneInfo के साथ जांच कर सकते हैं जब कोई विशेष मूल्य गलत या अस्पष्ट है, लेकिन ऐसी संभावना के बारे में बस भूलना आसान है। यदि आप समय क्षेत्र का उपयोग करके UTC के दौरान स्थानीय समय को परिवर्तित करने का प्रयास करते हैं, तो समय गलत होने पर अपवाद को फेंक दिया जाएगा। लेकिन अस्पष्ट समय को मानक डिफ़ॉल्ट के रूप में लिया जाएगा (और दिन की बचत समय के रूप में नहीं)। इस तरह का समाधान डेवलपर्स को उपयोग की जाने वाली सुविधाओं को भी ध्यान में रखने की अनुमति नहीं देता है। जिसके बारे में बात करें ...
बहुत जटिल हैअब आप बहुत अच्छी तरह से सोच सकते हैं: “मैंने एक हाथी को एक मक्खी से उड़ा दिया। मैं इसके बारे में नहीं सोचना चाहता - आप चीजों को इतना जटिल बनाने की कोशिश क्यों कर रहे हैं? मैंने वर्षों से .NET API का उपयोग किया है और किसी भी समस्या का अनुभव नहीं किया है। " यदि आपने ऐसा सोचा है, तो मैं तीन विकल्प दे सकता हूं:
- आप मुझसे बहुत अधिक होशियार हैं, और आप इन सभी कठिनाइयों को सहज स्तर पर समझते हैं। आप हमेशा डेटाइम प्रकार के चर के लिए सही दृश्य का उपयोग करते हैं; जहाँ आवश्यक हो - DateTimeOffset का उपयोग करें और हमेशा गलत या अस्पष्ट स्थानीय दिनांक / समय के साथ सही काम करें। बिना किसी संदेह के, आप सबसे कुशल और एक ही समय में विश्वसनीय तरीके से वस्तु की स्थिति तक साझा पहुंच के साथ गैर-अवरुद्ध बहु-थ्रेडेड कोड भी लिखते हैं। तो आप ये सब क्या पढ़ रहे हैं, मुझे बताइए?
- आपको इन समस्याओं का सामना करना पड़ा, लेकिन अधिकांश भाग उनके बारे में भूल गए - अंत में, उन्होंने आपके जीवन के केवल 10 मिनट का समय लिया, जबकि आप एक स्वीकार्य परिणाम प्राप्त करने के लिए प्रयोग कर रहे थे (या कम से कम परीक्षा पास करने के लिए; हालांकि ऐसे परीक्षण अच्छी तरह से वैचारिक रूप से गलत हो सकते हैं) । हो सकता है कि आप इस समस्या से घबरा गए हों, लेकिन यह निर्णय लिया कि समस्या आपके साथ है, एपीआई की नहीं।
- आपने इस समस्या का सामना नहीं किया, क्योंकि आप कोड परीक्षण को एक उबाऊ कार्य मानते हैं, क्योंकि यह उसी समय क्षेत्र में काम करता है, जो कंप्यूटर पर हमेशा रात में बंद हो जाते हैं (यानी, वे सर्दी / गर्मी के संक्रमण से प्रभावित नहीं होते हैं)। आप कुछ हद तक भाग्यशाली हैं, लेकिन फिर भी आप समय क्षेत्र के बारे में भूल जाते हैं।
कोई मजाक नहीं, लेकिन समस्या वास्तव में वास्तविक है। और अगर आपने इस लेख से पहले "स्थानीय" समय और "वैश्विक" क्षण के बीच अंतर के बारे में कभी नहीं सोचा था, तो आपने ऐसा किया। यह एक महत्वपूर्ण अंतर है - यह बाइनरी फ़्लोटिंग-पॉइंट नंबरों और दशमलव फ़्लोटिंग-पॉइंट नंबरों के बीच अंतर के समान है। त्रुटियां स्पष्ट नहीं हो सकती हैं, निदान करना मुश्किल है, खराब तरीके से समझाया गया है, खराब रूप से सही है और कार्यक्रम में कहीं और फिर से हो रहा है।
दिनांक / समय को संग्रहीत करने वाले चर के मूल्यों को संसाधित करना वास्तव में आसान नहीं है। ऐसे अप्रिय मामले हैं जैसे कि दिन आधी रात को शुरू नहीं होते हैं - गर्मी / सर्दियों के समय में संक्रमण के कारण (उदाहरण के लिए, रविवार, 17 अक्टूबर, 2010, ब्राजील में यह 1:00 बजे शुरू हुआ)। यदि आप विशेष रूप से अशुभ हैं, तो आपको मल्टी-कैलेंडर सिस्टम (ग्रेगोरियन, जूलियन, कॉप्टिक, बौद्ध, आदि) के साथ काम करना होगा। यदि आप 20 वीं शताब्दी की शुरुआत की तारीखों और समय के साथ काम कर रहे थे, तो आपने शायद समय क्षेत्रों के बहुत ही अजीब बदलावों को देखा क्योंकि सख्ती से देशांतर गैसों को अधिक "गोल" मूल्यों (उदाहरण के लिए, 1911 में पेरिस में) में स्थानांतरित कर दिया गया था। वास्तविक शिफ्ट से कुछ हफ़्ते पहले आप इस चेतावनी के साथ समय क्षेत्र बदलते हुए सरकारों का सामना कर सकते हैं। आप समय क्षेत्र पहचानकर्ताओं (उदाहरण के लिए, एशिया / कलकत्ता से एशिया / कोलकाता) में भी बदलाव कर सकते हैं।
यह सब, निश्चित रूप से, उन प्रासंगिक व्यावसायिक नियमों की सतह पर निहित है जिन्हें आप लागू करने की कोशिश कर रहे हैं। और वे मुश्किल भी हो सकते हैं। इन सभी जटिलताओं को देखते हुए, आपके पास कम से कम एक एपीआई होना चाहिए जो आपको अपेक्षाकृत स्पष्ट रूप से व्यक्त करने की अनुमति देता है कि आपका क्या मतलब है।
तो क्या नोदा टाइम परफेक्ट है?बिल्कुल नहीं। Noda Time में कुछ समस्याएँ हैं:
1. उपरोक्त सभी के बावजूद, मैं एक शौकिया हूँ जब यह तारीख और समय के सिद्धांत की बात आती है।
समन्वय का दूसरा मुझे भ्रमित करता है। जूलियन कैलेंडर के ग्रेगोरियन में बदलने के बिंदु के विचार में, रोने की इच्छा मुझे कवर करती है, और इसलिए मुझे अभी तक इसका एहसास नहीं हुआ है। जहां तक मुझे पता है, एक भी नोदा टाइम प्रोजेक्ट प्रतिभागी एक विशेषज्ञ नहीं है, हालांकि
जोडा टाइम के लेखक स्टीफेन कोलबोर्न और
जेएसआर -310 के प्रमुख
ने मेलिंग सूची पर जोर दिया है। (वैसे, उन्होंने पहली बार Noda Time प्रस्तुति में भाग लिया। मैंने पूछा कि क्या कमरे में किसी को भी ग्रेगोरियन कैलेंडर और ISO-8601 मानक कैलेंडर के बीच का अंतर पता है। उन्होंने हाथ उठाया और सही जवाब दिया। मैंने पूछा कि ऐसा कैसे हुआ कि उन्हें जवाब पता था। और उसने उत्तर दिया: "मैं स्टीफन कोलेबॉर्न हूं।" मैं लगभग गिर गया)।
2. हम अभी तक नहीं किए गए हैं। एक महान एपीआई डिजाइन बेकार है अगर कोई कार्यान्वयन नहीं है।
3. निश्चित रूप से त्रुटियां होंगी - बीसीएल कमांड कोड को दुनिया भर में सैकड़ों हजारों मशीनों पर लगातार निष्पादित किया जाता है। त्रुटियां जल्दी से दिखाई देंगी।
4. हमारे पास संसाधन नहीं हैं - हम केवल खुशी में काम करने वाले डेवलपर्स का एक सक्रिय समूह हैं। मैं अफसोस के साथ इस बारे में बात नहीं कर रहा हूं (यह वास्तव में बहुत अच्छा है), लेकिन समय के साथ अपरिहार्य समस्याएं हैं जो अतिरिक्त चिप्स, प्रलेखन आदि पर काम करने के लिए आवंटित की जा सकती हैं।
5. हम बीसीएल का हिस्सा नहीं हैं। LINQ to SQL (या यहां तक कि NHibernate) प्रश्नों में Noda Time का उपयोग करना चाहते हैं? सौभाग्य है। यहां तक कि अगर हम मेरी उम्मीदों से परे सफल होते हैं, तो मुझे नहीं लगता कि अन्य ओपन सोर्स प्रोजेक्ट होंगे जो सदियों तक हमारे ऊपर निर्भर रहेंगे। मुझे कहना होगा कि मैं परिणामस्वरूप डिजाइन से संतुष्ट हूं। हमने किसी विशिष्ट लक्ष्य को प्राप्त करने के लचीलेपन और सादगी के बीच संतुलन बनाए रखने की कोशिश की (अधिक प्रयासों के साथ, निश्चित रूप से)। किसी तरह मैं उपयोग किए गए डिज़ाइन शैली के बारे में एक और नोट लिखूंगा, जोडा टाइम डिज़ाइन और .NET में उपयोग होने वाले दोनों के साथ तुलना करता है। सबसे अच्छा परिणाम प्रकारों का परिणामी सेट है, जिनमें से प्रत्येक की अपनी बहुत स्पष्ट भूमिका है। मैं आपको विवरण के साथ बोर नहीं करूंगा - इसके लिए प्रलेखन और अन्य नोट्स होंगे।
अजीब तरह से पर्याप्त है, यह हर किसी के लिए बेहतर होगा यदि बीसीएल पर काम करने वाली टीम इस लेख पर ध्यान देती है और .NET 6 के लिए एपीआई को मौलिक रूप से नया करने का निर्णय लेती है (मेरा मानना है कि ".NET 5" जहाज पहले ही लॉन्च हो चुका है)। और जब मैं ऐसा कर रहा हूं, मुझे यकीन है कि कई अन्य परियोजनाएं हैं जो मुझे खुशी देगी - स्पष्ट रूप से, दिनांक और समय के मुद्दे .NET समुदाय के लिए लंबे समय तक मेरे कंधों पर पूरी तरह से झूठ बोलने के लिए बहुत महत्वपूर्ण हैं।
निष्कर्षमुझे आशा है कि मैंने आपको आश्वस्त किया है कि .NET एपीआई में महत्वपूर्ण खामियां हैं। शायद मैंने आपको यह भी आश्वस्त किया कि नोदा टाइम एक करीबी परिचित का हकदार है, लेकिन यह मुख्य लक्ष्य नहीं था। — DateTime — . .
( , —
. ).
() .. aka hDrummer,
.