[Mono-dev] DateTime.Parse difference with .NET

[Atsushi Eno]

Hi,

Now that it turned out that the bug is not reproducible with the
latest svn HEAD (i.e. the bug report is invalid)...

Alfredo Jose Muela Romero wrote:
> 	Hello,
> 
> El Tue, 09 Aug 2005 13:30:19 +0900
> Atsushi Eno <atsushi at ximian.com> escribió:
> 
> 
>>Hello,
> 
> 
> 	[...] 
>  
> 
>>In fact using DateTime.Parse() is somewhat stupid ;-) Read
>>here:
>>
>>http://msdn.microsoft.com/msdnmag/issues/05/03/CultureInfo/default
>>.aspx?side=true#a
>>
>>	The DateTime.Parse method in the Microsoft .NET Framework
>>	has goals much like its predecessors, but unfortunately
>>	it suffers from some of the same problems. The code is
>>	slower since the extra checking takes time, and there
>>	will always be some new format that is not properly
>>	detected. In those older products, you may remember, the
>>	behavior was sometimes disparagingly referred to as "evil
>>	date parsing."
>>
>>At least DateTime.Parse() is COM dependent where the behavior
>>is totally unpredictable and not countable from
>>DateTimeFormatInfo.
> 
> 
> 
> 	But in [1] we find that format string we need to specify as a
> valid format (see Globalization.DateTimeFormatInfo) it is
> unfinished :-S

If we have corresponding format string, it is likely to work like
this case.

> 	May be I lost something... what do you suggest to use instead of
> DateTime.Parse() or DateTime.ParseExact()?

I don't understand why we need to find something "instead of
DateTime.ParseExact()". Just use it.

Atsushi Eno