Re: [Mono-dev] DateTime.Parse difference with .NET
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/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 May be I lost something... what do you suggest to use instead of DateTime.Parse() or DateTime.ParseExact()? Alfredo. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
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 [EMAIL PROTECTED] 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
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. 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? 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/ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime.Parse difference with .NET
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/ 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
[Mono-dev] DateTime.Parse difference with .NET
using System;
namespace DateFail
{
class MainClass
{
public static void Main(string[] args)
{
DateTime.Parse(17/07/2005 00:00:00);
}
}
}
.NET Framework 1.1 result: Success
Mono 1.1.8 result:
Unhandled Exception: System.FormatException: String was not recognized as
a vali
d DateTime.
in 0x000e5 System.DateTime:Parse (System.String s, IFormatProvider fp,
DateTim
eStyles styles)
in 0x00016 System.DateTime:Parse (System.String s, IFormatProvider fp)
in 0x00013 System.DateTime:Parse (System.String s)
in 0x00013 DateFail.MainClass:Main (System.String[] args)
I submitted it to BugZilla - just wanted to make sure I'm not doing
anything stupid and also wondered if someone had a workaround?
Martin Hinks
http://www.m-s-d.net
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
