हम लीप ईयर बग्स से बचाने के लिए कैसे कोडिंग प्रथाओं को विकसित कर सकते हैं? [बन्द है]

Question 1

बंद हो गया । यह सवाल राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

2 साल पहले बंद हुआ ।

इस प्रश्न को सुधारें

माइक्रोसॉफ्ट ने अभी घोषणा की है कि पिछले सप्ताह विंडोज एज़्योर में तारीखों (लीप वर्ष से अधिक) की गणना में एक सॉफ्टवेयर त्रुटि का कारण बना ।

क्या यह वास्तव में DateTime.Now.AddYears(1)एक लीप वर्ष पर काम करने वाले निर्णय में एक साधारण त्रुटि थी?

क्या कोडिंग प्रथाओं को रोका जा सकता था?

EDIT जैसा कि dcstraw ने DateTime.Now.AddYears(1)लीप ईयर पर बताया था कि वास्तव में .NET में सही तारीख है। तो यह एक ढांचा बग नहीं है, लेकिन स्पष्ट रूप से तिथि गणना में एक बग है।

Question 2

बेशर्म प्लग:

बेहतर दिनांक और समय API का उपयोग करें

बिल्ट-इन .NET दिनांक और समय पुस्तकालयों को ठीक से उपयोग करने के लिए बहुत कठिन हैं। वे आपको वह सब कुछ करने देते हैं जिसकी आपको ज़रूरत है, लेकिन आप अपने आप को स्पष्ट रूप से टाइप सिस्टम के माध्यम से व्यक्त नहीं कर सकते हैं । DateTimeएक गड़बड़ है , DateTimeOffsetआपको यह सोचने में सुस्त कर सकता है कि आप वास्तव में उस समय क्षेत्र की जानकारी को संरक्षित कर रहे हैं जब आप नहीं हैं, और TimeZoneInfoआपको वह सब कुछ सोचने के लिए मजबूर नहीं करता है जिसे आप विचार करना चाहते हैं।

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

इस सब के कारण मैं Noda Time का निर्माण कर रहा हूं - जोडा टाइम "इंजन" के एक पोर्ट पर निर्मित वैकल्पिक तिथि और टाइम लाइब्रेरी लेकिन शीर्ष पर एक नया (और लीनर) API के साथ।

कुछ बिंदु जिनके बारे में आप सोचना चाहते हैं, जिन्हें याद रखना आसान है यदि आप उनके बारे में नहीं जानते हैं:

किसी विशेष समय क्षेत्र में किसी स्थानीय दिनांक / समय को मैप करना उतना सरल नहीं है जितना आप सोच सकते हैं। दिन के उजाले की बचत के कारण एक विशिष्ट स्थानीय तिथि / समय एक बार, दो बार (अस्पष्टता) या शून्य समय (इसे छोड़ दिया गया) हो सकता है
समय क्षेत्र ऐतिहासिक रूप से भिन्न होते हैं - TimeZoneInfoआम तौर पर प्रकट करने के लिए तैयार से अधिक है , स्पष्ट रूप से। (यह एक समय क्षेत्र का समर्थन नहीं करता है जिसका विचार "मानक समय" समय के साथ बदलता है, या जो स्थायी डेलाइट सेविंग टाइम में चला जाता है)।
ज़ोनइनफो डेटाबेस के साथ भी, टाइम ज़ोन आईडी जरूरी स्थिर नहीं हैं। (सीएलडीआर इसे संबोधित करता है; मैं अंत में नोदा समय में समर्थन की उम्मीद कर रहा हूं।)
दिनांक और समय का शाब्दिक निरूपण एक बुरा सपना है, न केवल आदेश देने के संदर्भ में, बल्कि तिथि विभाजक, समय विभाजक, और अजीब बातें जैसे कि मूल महीने के नाम
दिन की शुरुआत हमेशा आधी रात को नहीं होती है - ब्राजील में, उदाहरण के लिए, स्प्रिंग डेलाइट सेविंग ट्रांजिशन दीवार घड़ी को रात 11:59:59 बजे से दोपहर 1 बजे तक चलती है
कुछ मामलों में (अच्छी तरह से, जिसके बारे में मुझे पता है) एक समय क्षेत्र को पूरा दिन छोड़ देने के लिए मजबूर कर सकता है - दिसंबर 30 2011 2011 समोआ में नहीं हुआ था! मुझे संदेह है कि अधिकांश डेवलपर्स शायद इसे अनदेखा कर सकते हैं, लेकिन ...
यदि आप ग्रेगोरियन के अलावा एक कैलेंडर का उपयोग करने जा रहे हैं, तो सावधान रहें और सुनिश्चित करें कि आप वास्तव में जानते हैं कि आप इसे कैसे व्यवहार करने की उम्मीद करते हैं।

जहाँ तक विशिष्ट विकास पद्धतियाँ हैं:

इस बारे में सोचें कि आप वास्तव में क्या प्रतिनिधित्व करने की कोशिश कर रहे हैं। मुझे उम्मीद है कि डेवलपर्स को अपने डेटा का प्रतिनिधित्व करने के लिए विभिन्न प्रकारों के बीच चयन करने के लिए मजबूर करने के लिए Noda Time का मुख्य लाभ होगा। उस अधिकार को प्राप्त करें, और बाकी सब कुछ सरल है।
यूनिट परीक्षण सब कुछ आप के बारे में सोच सकते हैं। यह इस बात पर निर्भर करेगा कि आपका सिस्टम निश्चित रूप से क्या करता है, लेकिन विशेष रूप से अलग-अलग समय क्षेत्रों पर विचार करें, दिन के उजाले की बचत में क्या होता है, और निश्चित रूप से लीप वर्ष।
मैं "क्लॉक-लाइक इंटरफ़ेस" इंजेक्ट करने की सलाह दूंगा - जो वर्तमान समय को बताने के लिए एक सेवा है - बजाय स्पष्ट रूप से कॉल करने के DateTime.Nowया DateTime.UtcNow; यह इकाई परीक्षण के लिए आसान (व्यवहार्य!) बनाता है
यदि आप "अब" के साथ कई ऑपरेशन कर रहे हैं, तो उस तारीख / समय को एक बार प्राप्त करें और इसे याद रखें, बजाय "अब" का अनुरोध करने के - अन्यथा मूल्य कॉल के बीच दुर्भाग्यपूर्ण तरीके से बदल सकता है।
"क्या सब कुछ UTC में है" हमेशा इसका उत्तर नहीं होता है - अगर मैं जानना चाहता हूँ "जब मेरे स्थानीय समय क्षेत्र में 'अभी से दो सप्ताह बाद' होता है?" फिर मुझे स्थानीय दिनांक / समय के साथ-साथ समय क्षेत्र को संग्रहीत करने की आवश्यकता है ।

Question 3

यह ध्यान देने योग्य है कि बग शायद आपके द्वारा पोस्ट की गई रेखा के कारण नहीं था:

DateTime.Now.AddYears(1)

वह अमान्य दिनांक नहीं बनाता है। यदि आप चलाते हैं:

(new DateTime(2012, 2, 29)).AddYears(1)

आप 28 फरवरी, 2013 को प्राप्त कर रहे हैं। मुझे नहीं पता कि एज़्योर का अतिथि एजेंट क्या लिखा है, लेकिन यह एक अलग कॉल रहा होगा जो विफल रहा। .NET में ऐसा करने का एक बुरा तरीका है:

new DateTime(today.Year + 1, today.Month, today.Day)

यदि todayलीप दिन है तो यह एक अपवाद फेंकता है। हालाँकि Azure समस्या के बारे में Microsoft ब्लॉग ने कहा कि उन्होंने 29 फरवरी, 2013 को एक अमान्य तारीख बनाई, जो मुझे यकीन नहीं है कि DateTime.NET में संभव है ।

मैं यह नहीं कह रहा हूं DateTimeऔर DateTimeOffsetत्रुटि-रहित नहीं हैं, बस मुझे नहीं लगता कि वे इस विशेष मुद्दे का कारण बनेंगे।

Question 4

हम लीप ईयर बग्स से बचाने के लिए कैसे कोडिंग प्रथाओं को विकसित कर सकते हैं? क्या कोडिंग प्रथाओं को रोका जा सकता था?

जॉन द्वारा बताई गई यूनिट की विशिष्ट तिथियों का परीक्षण एक कोड अभ्यास है जो कि किसी भी चीज की सहायता नहीं करेगा, जिसे मैं 'मैनुअल एकीकरण परीक्षण' के रूप में परिभाषित करता हूं।

अपने विकास / परीक्षण किए गए सर्वर पर घड़ी बदलें और देखें कि जब समय टिक जाता है तो क्या होता है।

चाहे वह 'कोडिंग प्रैक्टिस' हो या न हो, इस बारे में बताएं - जाहिर तौर पर आप कैलेंडर पर हर तारीख के लिए ऐसा नहीं कर सकते - उन तारीखों को चुनें जिनसे आप चिंतित हैं, 29 वें फरवरी को, महीने के अंत में तारीख या दिन के उजाले बचत बदलाव की तारीखें।