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

[Atsushi Eno]

Hi,

Alfredo Jose Muela Romero wrote:
> El Tue, 09 Aug 2005 19:01:32 +0900
> Atsushi Eno <atsushi at ximian.com> escribió:
> 
> 
>>Hi,
>>
>>Now that it turned out that the bug is not reproducible with
>>the latest svn HEAD (i.e. the bug report is invalid)...
> 
> 
> 	Which bug? Did I talk to any bug? :-S If I did so I didn't mean
> it, I just wanted to ask a doubt...

I am talking along with the original topic i.e. bug #75749.

Since you "replied" to this thread, it should be no wonder that
I guess you are talking about it.

>>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/d
>>>
>>>efault >.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.
> 
> 
> 	I guess I didn't understand the "unfinished concept" or your
> answer... In other words... even if there are unfinished members
> on a class, and consecuently the class is marked as unfinished,
> is still the class usable? (I thought I couldn't...)

Originally there is no one who mentioned "unfinished concept" so
I just ignored it (and "[1]" as well). What are they?
What are you talking about? What are you asking about?

>>>	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.
> 
> 
> 	So, should I use a string specify for myself (such as
> "dd/MM/yyyy H:mm*:ss*") for the format?

Yes, or alternatively use
CultureInfo.DateTimeFormat.GetAllDateTimePatterns() or whatever.

The fact that there is no decent alternative of DateTime.Parse()
(that would consider only explicitly-defined date time format
strings) is a problem in Microsoft.NET, not ours. (oh, yes we
could provide alternative decent library if there is need though ;-)

Atsushi Eno