2012-06-22 11 views
18

टाइमस्पेन। पर्स ("23:00:00") 23 घंटे देता है।सी # टाइमस्पैन। पर्स अमान्य प्रारूप अपवाद के बजाय गलत मान देता है

टाइमस्पैन। पर्स ("24:00:00") 24 दिन लौटाता है!

मुझे एहसास हुआ कि मैंने गलती की है कि घंटों की स्वीकार्य सीमा 0-23 है। लेकिन यदि आप रेंज वैल्यू से बाहर निकलने का प्रयास करते हैं तो आपको मिनट और सेकंड के लिए अपवाद मिलता है। सीमा मूल्य से बाहर के घंटों के मामले में, पार्सर गलत तरीके से आपको घंटों के बजाय दिन का अनुमान लगाता है।

क्या कोई इसे समझा सकता है?

यहाँ इस उदाहरण यह बहुत ही विषय को शामिल किया गया और पता चलता है कि http://msdn.microsoft.com/en-us/magazine/ee309881.aspx

ही TryParse के बारे में सच प्रतीत होता है। दस्तावेज़ों के बावजूद मुझे 24 दिन मिलते हैं कि पार्स विफल होना चाहिए।

http://msdn.microsoft.com/en-us/library/3z48198e

//   String to Parse    TimeSpan 
//   --------------- --------------------- 
//       0  00:00:00 
//       14  14.00:00:00 
//      1:2:3  01:02:03 
//     0:0:0.250  00:00:00.2500000 
//    10.20:30:40.50  10.20:30:40.5000000 
//  99.23:59:59.9999999  99.23:59:59.9999999 
//  0023:0059:0059.0099  23:59:59.0099000 
//      23:0:0  23:00:00 
//      24:0:0 Parse operation failed. 
//      0:59:0  00:59:00 
//      0:60:0 Parse operation failed. 
//      0:0:59  00:00:59 
//      0:0:60 Parse operation failed. 
//      10: Parse operation failed. 
//      10:0  10:00:00 
//      :10 Parse operation failed. 
//      0:10  00:10:00 
//      10:20: Parse operation failed. 
//     10:20:0  10:20:00 
//      .123 Parse operation failed. 
//     0.12:00  12:00:00 
//      10. Parse operation failed. 
//      10.12 Parse operation failed. 
//     10.12:00  10.12:00:00 

मैं एक बग मिला या मैंने कुछ गलत कर रहा हूँ?

संपादित करें: मैंने लिंककैड में इसका परीक्षण किया है और विंडोज 7 64 बिट पर .NET4 में एक कंसोल ऐप का उपयोग किया है।

  var result = TimeSpan.Parse("24:00:00"); 
      Console.WriteLine(result); 
      result = TimeSpan.Parse("24:00:00", CultureInfo.InvariantCulture); 
      Console.WriteLine(result); 

इस में जो परिणाम:

24.00:00:00 
24.00:00:00 
+0

आप TryParse और Parse के परिणाम की तुलना कर रहे हैं। TimeSpan.Parse (स्ट्रिंग) विधि वर्तमान संस्कृति के लिए प्रत्येक संस्कृति-विशिष्ट स्वरूपों का उपयोग करके स्ट्रिंग (पैरामीटर) को पार्स करने का प्रयास करती है। तो आपको दिन मिल रहे हैं। –

+0

यह मेरे लिए अपवाद फेंकता है। शायद यह एक संस्कृति की बात है? @ रोमिइल: 'पार्स' दृश्यों के पीछे 'TryParse'' को कॉल करता है ताकि उनके पास एक ही परिणाम हो। – Rawling

+2

यह विश्वसनीय रूप से ओवरफ्लो एक्सेप्शन उत्पन्न करता है जब मैं इसे आज़माता हूं। .NET संस्करण, अपनी संस्कृति और किसी भी ओवरराइड को दस्तावेज़ित करके अपने प्रश्न को बेहतर बनाएं जो आपने Windows क्षेत्रीय सेटिंग्स में लागू किया हो। –

उत्तर

9

क्या हो रहा है कि TimeSpan.Parse प्रयास के क्रम में निम्न स्वरूपों में से प्रत्येक का उपयोग कर ##:##:## पार्स करने के लिए, को रोकने के रूप में जल्द ही एक सफल होता है:

  1. hh:mm:ss (invariant संस्कृति)
  2. d.hh:mm (invariant संस्कृति)
  3. hh:mm:ss (स्थानीयकृत)
  4. d.hh:mm (स्थानीयकृत; "।" के बारे में अधिक जानकारी नीचे)

तो:

  • 23:08:09 सफलतापूर्वक 0 दिन 23h 8 9 नंबर के पत्तों के रूप में चरण में पार्स किया गया है 1.
  • 24:08:09 सफलतापूर्वक चरण में 24d 8h 9 एम 0 के रूप में पार्स किया गया है 4.

यदि यह व्यवहार आपको अनुकूल नहीं करता है, तो आप TimeSpan.ParseExact का उपयोग कर सकते हैं:

TimeSpan.ParseExact("23:00:00", "hh':'mm':'ss", null) // OK 
TimeSpan.ParseExact("24:00:00", "hh':'mm':'ss", null) // OverflowException 

अद्यतन:TimeSpan.Parse के लिए प्रलेखन के अनुसार, "।" "डी" और "एचएच" के बीच

एक संस्कृति-संवेदनशील प्रतीक जो दिन से घंटों को अलग करता है। Invariant प्रारूप एक अवधि ("।") वर्ण का उपयोग करता है।

हालांकि, मैंने परावर्तक के साथ ढांचे के स्रोत में खोला, और यह पता चला कि, स्थानीय प्रारूप में, यह कथित "संस्कृति-संवेदनशील" प्रतीक हमेशा एक कोलन है! यहां आंतरिक DateTimeFormatInfo.FullTimeSpanPositivePattern संपत्ति का एक अंश दिया गया है:

string separator = new NumberFormatInfo(cultureData).NumberDecimalSeparator; 
this.m_fullTimeSpanPositivePattern = "d':'h':'mm':'ss'" + separator + "'FFFFFFF"; 
+0

"एक्सएक्स: 00: 00" मैच "डीएचएच: एमएम" कैसे करता है? स्ट्रिंग में कोई अवधि नहीं है! यह अभी भी एक अप्रत्याशित परिणाम की तरह लगता है। –

+0

ठीक है, अब यह सबसे अच्छा स्पष्टीकरण है। मैं देख सकता हूं कि कोड ऐसा क्यों व्यवहार करता है, लेकिन मुझे लगता है कि यह दस्तावेज (अपेक्षित/इरादा?) व्यवहार नहीं है। –

+0

मैं सहमत हूं; वास्तविक व्यवहार बल्कि दुर्भाग्यपूर्ण और आश्चर्यजनक है। –

संबंधित मुद्दे