El Tue, 09 Aug 2005 20:13:09 +0900
Atsushi Eno <[EMAIL PROTECTED]> escribió:
> Hi,
>
> Alfredo Jose Muela Romero wrote:
> > El Tue, 09 Aug 2005 19:01:32 +0900
> > Atsushi Eno <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
