बग?

Question

जब मैं सूत्र DATEVALUE ("1900/01/01") मैं 1 मिलता है और एक तिथि यह पता चलता है के रूप में स्वरूपित का उपयोग 1900/01/01 के रूप में

जब मैं का उपयोग VBA

.Range("A1").Value = DateValue("01/01/1900") 

यह पता चलता है सेल में "02/01/1900" के रूप में ऊपर

यह कैसे संभव है?

अगर मैं उदाहरण

.Range("A1").Value = DateValue("01/01/1901") 

के लिए उपयोग यह ठीक काम करता है!

हेड पिघला हुआ !!!

माइक्रोसॉफ्ट का कहना है कि -

Answer 1

संक्षेप में "विंडोज के लिए माइक्रोसॉफ्ट एक्सेल में डिफ़ॉल्ट दिनांक प्रणाली का उपयोग करना, DATE_TEXT तर्क 1 जनवरी, 1900 और 31 दिसंबर, 9999 के बीच एक तारीख से प्रस्तुत करना चाहिए", एक्सेल का दिनांक समय युग नहीं है वीबीए के डेटटाइम युग के समान। हालांकि, वे एक ही बार आप पिछले फरवरी 28 वें मिलता है, 1900

हैं Joel Spolksy's blog से:

सबसे आधुनिक प्रोग्रामिंग वातावरण में, दिनांक असली संख्या के रूप में जमा हो जाती है। संख्या का पूर्णांक भाग के बाद से दिनों की संख्या है, जो अतीत में कुछ सहमत-तिथि है, जिसे युग कहा जाता है। एक्सेल, आज के तारीख, 16 जून, 2006 में, 38,884 के रूप में संग्रहीत किया जाता है, दिन गिनती जहां जनवरी 1, 1900 है 1.

मैं मूल में विभिन्न दिनांक और समय कार्यों के माध्यम से काम करना शुरू किया और तारीख और समय Excel में फ़ंक्शंस, चीजों को आजमाते हुए, जब मैं ने विजुअल बेसिक प्रलेखन में कुछ अजीब देखा: मूल किसी भी कारण से 31 दिसंबर, 18 99 को युग के रूप में उपयोग करता है, लेकिन किसी कारण से, आज की तारीख Excel में समान थी क्योंकि यह बेसिक में था।

हू?

मैं एक एक्सेल डेवलपर खोजने गया जो याद रखने के लिए पुराना था। एड फ्राइज़ जवाब को जानना प्रतीत होता था।

"ओह," उसने मुझे बताया। "28 फरवरी, 1 9 00 को देखें।"

"यह 59 है," मैंने कहा।

"अब 1 मार्च का प्रयास करें।"

"यह 61 है!"

"60 से क्या हुआ?" एड ने पूछा।

"2 9 फरवरी 1 9 00 एक लीप वर्ष था! यह 4 से विभाजित है!"

"अच्छा अनुमान है, लेकिन कोई सिगार नहीं है," एड ने कहा, और मुझे के लिए सोचने के लिए छोड़ दिया।

ओह। मैंने कुछ शोध किया।साल जो 100 से विभाजित होते हैं वे लीप साल नहीं होते हैं, जब तक कि वे 400 तक विभाजित नहीं होते हैं।

1 9 00 एक लीप वर्ष नहीं था।

"यह एक्सेल में एक बग है!" मैंने कहा।

"ठीक है, वास्तव में नहीं," एड ने कहा। "हमें इसे ऐसा करना था क्योंकि हमें कमल 123 वर्कशीट आयात करने में सक्षम होने के लिए की आवश्यकता है।"

"तो, यह कमल 123 में एक बग है?"

"हाँ, लेकिन शायद एक जानबूझकर एक। लोटस 640K में फिट करने के लिए किया था। स्मृति का एक बहुत नहीं है यही कारण है कि। आप चाहें है 1900 की अनदेखी, तो आप पता लगा सकते हैं बस के लिए देख द्वारा यदि एक दिए गए वर्ष एक अधिवर्ष है देखें कि सही दो बिट्स शून्य हैं। यह वास्तव में तेज़ और आसान है। कमल लोग शायद यह अनुमान लगाया गया था कि अतीत में उन दो महीनों के लिए के लिए गलत नहीं था। ऐसा लगता है कि मूल लोग गुदा होना चाहते थे उन दो महीनों के बारे में , इसलिए उन्होंने एक दिन पहले युग को स्थानांतरित कर दिया। "

"आर्ग!" मैंने कहा, और अध्ययन करने के लिए चला गया कि विकल्प संवाद में 1 9 04 दिनांक प्रणाली नामक एक चेकबॉक्स क्यों था।

---

नीचे दी गई जानकारी this Super User answer से लिया गया है।

---

माइक्रोसॉफ्ट KB 214058 में वर्णित है:

Days of the week before March 1, 1900 are incorrect in Excel

अधिक जानकारी

जब Microsoft Excel में दिनांक प्रणाली मूल रूप से बनाया गया था, यह डिजाइन किया गया था तारीख के साथ पूरी तरह से संगत होना करने के लिए अन्य स्प्रेडशीट कार्यक्रमों द्वारा उपयोग की जाने वाली प्रणालियों।

हालांकि, इस तिथि प्रणाली में, वर्ष 1 9 00 को गलत रूप से लीप वर्ष के रूप में व्याख्या किया गया है। क्योंकि 1 9 00 में कोई फरवरी 2 9 ("लीप डे") नहीं है, 1 मार्च, 1 9 00 से पहले किसी भी तारीख के लिए सप्ताह का दिन ("लीप डे" के बाद का दिन) सही ढंग से गणना नहीं किया जाता है।

"अन्य स्प्रेडशीट प्रोग्राम" Lotus 1-2-3, जो उस वक्त काफी लोकप्रिय था, और गलत तरीके से मान लिया है कि वर्ष 1900 एक लीप वर्ष था को देखें। यह KB 214326 में और भी विस्तार से समझाया गया है:

Excel 2000 incorrectly assumes that the year 1900 is a leap year

अधिक जानकारी

जब लोटस 1-2-3 पहले जारी किया गया था, इस कार्यक्रम मान लिया है कि वर्ष 1900 एक लीप वर्ष था, भले ही यह वास्तव में एक छलांग वर्ष नहीं था। इसने प्रोग्राम को लीप वर्षों को संभालने में आसान बना दिया और कमल 1-2-3 में लगभग सभी दिनांक गणनाओं को कोई नुकसान नहीं पहुंचाया।

जब माइक्रोसॉफ्ट मल्टीप्लान और माइक्रोसॉफ्ट एक्सेल जारी किए गए, तो उन्होंने यह भी माना कि 1 9 00 एक लीप वर्ष था।इस धारणा ने माइक्रोसॉफ्ट मल्टीप्लान और माइक्रोसॉफ्ट एक्सेल को लोटस 1-2-3 द्वारा उपयोग की जाने वाली एक ही धारावाहिक तिथि प्रणाली का उपयोग करने और कमल 1-2-3 के साथ अधिक संगतता प्रदान करने की अनुमति दी। एक लीप वर्ष के रूप में 1 9 00 का इलाज करने से उपयोगकर्ताओं के लिए वर्कशीट को एक प्रोग्राम से दूसरे प्रोग्राम में स्थानांतरित करना आसान हो गया।

हालांकि यह व्यवहार इस व्यवहार को सही करने के लिए तकनीकी रूप से संभव है ताकि माइक्रोसॉफ्ट एक्सेल के मौजूदा संस्करण यह नहीं मानते कि 1 9 00 एक लीप वर्ष है, तो फायदे से अधिक होने का नुकसान।

इस व्यवहार सही करने की थे, तो कई समस्याओं, पैदा होता निम्नलिखित शामिल हैं:

• लगभग वर्तमान Microsoft Excel कार्यपत्रक और अन्य दस्तावेजों में सभी तिथियों एक दिन से कम की जाएगी। इस शिफ्ट को सुधारने में काफी समय और प्रयास लगेगा, खासकर सूत्रों में जो तिथियों का उपयोग करते हैं।
• कुछ फ़ंक्शन, जैसे कि सप्ताहांत फ़ंक्शन, अलग-अलग मान वापस कर देगा; यह कार्यपत्रकों में सूत्रों को गलत तरीके से काम करने का कारण बन सकता है।
• इस व्यवहार को सुधारने से माइक्रोसॉफ्ट एक्सेल और तिथियों का उपयोग करने वाले अन्य कार्यक्रमों के बीच सीरियल डेट संगतता टूट जाएगी।

व्यवहार uncorrected रहता है, केवल एक ही समस्या होती है:

• WEEKDAY समारोह 1 मार्च, 1900 से पहले दिनांक के लिए गलत मान देता है क्योंकि अधिकांश उपयोगकर्ताओं 1 मार्च, 1900 से पहले दिनांक का उपयोग नहीं करते, यह समस्या दुर्लभ है।