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

[Alfredo Jose Muela Romero]

El Tue, 09 Aug 2005 20:13:09 +0900
Atsushi Eno <atsushi at ximian.com> escribió:

> 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.

	Ok, correct. It was just that I hesitated about being
understood.
 
> >>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?

	Sorry, I forgot to paste the link (Ooops 0_o), actually [1]
meant to be:

[1]http://www.go-mono.com/docs/index.aspx?link=T%3aSystem.Global
ization.DateTimeFormatInfo

 	I hope it would answer that questions...
	

> >>>	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.

	Ok, got it.

> 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 ;-)

	I see ^_^



		Alfredo.