CODEWITHSUNDEEP
c#.netdatetimecom
William Edmondson
William Edmondson

Reputation: 3637

Is DateTime.Parse COM dependent

I ran across a blog entry that stated DateTime.Parse is COM dependent. I have not been able to find confirming evidence for this statement.

If this is the case I would like to find documentation on this preferably sourced from Microsoft.

Source: http://blog.aasheim.org/2008/04/dont-use-datetimeparse-use.html

Upvotes: 2

Views: 223

Answers (2)

Ani
Ani

Reputation: 113402

I believe you are referring to this blog, which says:

It seems that very few people know that DateTime.Parse() is COM dependent, evil one. Moreover, even in Microsoft.NET, there is no assurance that such string that DateTime.Parse() accepts on your machine is acceptable under other machines. Basically DateTime.Parse() is for newbies who don't mind unpredictable behavior.

It appears that the author's choice of words isn't great; what they appear to be trying to warn the reader about is that DateTime.Parse is culture-dependent - the success/failure/result of a parse-operation will depend on the current culture. This is important for developers to note when they are trying to work with text representing date-times in a culture-sensitive/independent manner.

That said, it's of little relevance whether or not Parse has an actual COM-dependency or not. Since it's not directly documented, the implementation could be changed without notice by adding/removing COM dependencies.

Upvotes: 4

Kashif Khan
Kashif Khan

Reputation: 2645

Yes it is COM dependent. From this MSDN page:

There are two parsing methods you can use to parse your strings: Parse and ParseExact. The Parse method's functionality is rooted in COM (which was itself rooted to older versions of Visual Basic) and conversions from string to date happened no matter what the cost. The risks of improper parsing are an unfortunate side effect, one that is visible to people who have to work with both dd/mm/yy and mm/dd/yy dates. 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."

Upvotes: 1

Related Questions