On one of the machines we tested, all calls to DateTime.Parse() throw an IndexOutOfRangeException, generated somewhere in mscorlib.dll. DateTime.Parse() is not documented as throwing an IndexOutOfRangeException, and the initial input was an ISO-style date/time from SQL Server 2005: "2006-10-05T12:24:00".
All machines were set to the "English (United Kingdom)" culture. The failing machine mysteriously has no AM and PM designators, but otherwise identical DateTimeFormatInfo. Reinstalling .NET (v2.0) had no effect.
One-line tests were run with the following input strings:
"2006-10-05 12:24:00Z""2006-10-05T12:24:00Z"
"2006-10-05T12:24:00" (SQL Server 2005)"10 May 2006 12:24:00" (to match FullDateTimePattern, 'dd MMMM yyyy HH:mm:ss')
This seems to be the same issue described in this post:
http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=156661&SiteID=1
Hopefully this one can be solved without reinstalling Windows on the failing machine
DateTime.Parse() failing on one machine
Ajey
Did you try to use the invariant culture
DateTime res = DateTime.Parse ("2006-10-05T12:24:00", CultureInfo.InvariantCulture);
--mc
Joe Cotugno
Jack,
You can report bugs in Microsoft's developer software on the Microsoft Product Feedback Center.
Regards
David
mihai.manole77
Thanks for the suggestion! We had an opportunity to go back to the client site today, and all calls to DateTime.Parse() failed - until we filled in the missing AM and PM designators in Regional and Language Options.
This workaround, however, is completely unacceptable - users cannot be expected to fiddle with obscure settings or reinstall Windows just to achieve such basic, mundane .NET functionality. For business reasons, we were forced to write our own date parsing code.
This is a bug that has been ignored previously. As the post I linked to suggested, this issue does not seem to affect versions of .NET prior to 2.0 and the 2.0 beta.
I'd appreciate it if someone from Microsoft would admit the existence of this bug and incorporate a fix into the next version of the .NET framework. At the very least, the DateTime.Parse() documentation should be updated to warn that an IndexOutOfRangeException may be thrown on incorrectly-configured machines.