Checking for a valid date

[Armin Zingler]

What's the easiest way to verify the user had entered a valid date ?

Call Date.Parse in a Try/Catch block. If there's no excecption the date was
valid.


Armin

 

[Larry Lard]

What's the easiest way to verify the user had entered a valid date ?

The IsDate() function.

 

[Herfried K. Wagner [MVP]]

What's the easiest way to verify the user had entered a valid date ?

'Microsoft.VisualBasic.Information.IsDate'.

 

[Jason Pettys]

I recommend against this method in most cases; exceptions are
resource-intensive and shouldn't really be used for raw user-data
validation. It probably wouldn't matter much on a Win Forms app, but I
would really back away from this on ASP.NET if you're expecting any
volume of traffic.

The IsDate would be a better way to go.

Jason

www.pettysconsulting.com

 

[romy]

What's the easiest way to verify the user had entered a valid date ?

 

[Guest]

Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

 

[Jason Pettys]

I'm not sure whether IsDate uses Exceptions as the primary mechanism.
Does anyone know for sure whether IsDate uses an exception for invalid
dates (1) always, (2) sometimes, or (3) never?

If I found out that it did I wouldn't use it; here's an msdn blog that
talks about it, the best quote being, "...pretend that the throw
statement makes the computer beep 3 times, and sleep for 2 seconds. If
you still want to throw under those circumstances, go for it."

http://blogs.msdn.com/ricom/archive/2003/12/19/44697.aspx

The feedback from Jeremy Wilson on this next page seems to indicate that
IsDate does not (or at least doesn't use it alone):

http://blogs.crsw.com/mark/archive/2005/04/06/829.aspx

If I found out that IsDate DID rely primarily on an exception for
invalid values I would use something similar to that referenced in this
next article, the idea being to catch most invalid dates without
throwing an exception:

http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci960388_tax293037,00.html

Jason

www.pettysconsulting.com

 

[Cor Ligthert]

Armin,

Call Date.Parse in a Try/Catch block. If there's no excecption the date
was valid.

This is what internally iw done in IsDate

(You can check it by setting the stop on all throwed events in the debugger)



Cor

 

[Armin Zingler]

I'm not sure whether IsDate uses Exceptions as the primary
mechanism. Does anyone know for sure whether IsDate uses an
exception for invalid dates (1) always, (2) sometimes, or (3) never?

If I found out that it did I wouldn't use it; here's an msdn blog
that talks about it, the best quote being, "...pretend that the
throw statement makes the computer beep 3 times, and sleep for 2
seconds. If you still want to throw under those circumstances, go
for it."

http://blogs.msdn.com/ricom/archive/2003/12/19/44697.aspx

The feedback from Jeremy Wilson on this next page seems to indicate
that IsDate does not (or at least doesn't use it alone):

http://blogs.crsw.com/mark/archive/2005/04/06/829.aspx

If I found out that IsDate DID rely primarily on an exception for
invalid values I would use something similar to that referenced in
this next article, the idea being to catch most invalid dates
without throwing an exception:

http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci960388_tax293037,00.html

I see three ways to convert:

- Date.Parse: Depends on regional settings and is very flexible - sometimes
too flexible as some people think.
- Date.ParseExact: If a given format is expected.
- Your own function. Maybe using the function from the last link. If you're
using regex or your own parser is up to the author.

Costs of exceptions are completely out of interest as you internally always
should work with the Date data type. As a string input is usually taken from
the user - you know, the slowest part of the chain - there is absolutely no
need to optimize this process. Much more important is that the user can be
sure that the same formats are accepted throughout the entire application.

If you have to optimize it, e.g. to process a large text file containing
dates, you still can use your own function. But in this case, Date.Parse
isn't used in most cases anyway because the date format in a file is usually
limited to an exact format or at least limited to something less than
Date.Parse can recognize.

Therefore, the first question has to be which format is to be accepted.
Depending on this, the right function must be used. If you go for
Date.Parse, there is no other way than catching the exception. Validating
the string before, to prevent Date.Parse throwing an exception is bad design
because it would have to be an exact immitation of Date.Parse's behaviour.
You would have to rely on an absolute exact documentation of Date.Parse's
behavior, and you would have to correct the parsing behavior when the
Framework's implementation changes - as it does sligthly in version 2.0,
AFAIK.

Armin

 

[Armin Zingler]

Armin,

This is what internally iw done in IsDate

(You can check it by setting the stop on all throwed events in the
debugger)

Ok ok, I've read it now. (sometimes we forget the simple things
(searched for TryParse first)) But, what do C# people do? That's probably
why I didn't think of IsDate. Furthermore, *if* you use IsDate you should
also use CDate instead of Date.Parse.

Armin

 

[Herfried K. Wagner [MVP]]

I'm not sure whether IsDate uses Exceptions as the primary mechanism. Does
anyone know for sure whether IsDate uses an exception for invalid dates
(1) always, (2) sometimes, or (3) never?

According to Lutz Roeder's Reflector, the method's implementation looks like
this:

\\\
Public Shared Function IsDate(ByVal Expression As Object) As Boolean
If (Not Expression Is Nothing) Then
If TypeOf Expression Is DateTime Then
Return True
End If
If TypeOf Expression Is String Then
Try
Dim time1 As DateTime =
DateType.FromString(CType(Expression, String))
Return True
Catch exception1 As Exception
End Try
End If
End If
Return False
End Function
///

 

[Guest]

Jason,

You can catch the exception that IsDate throws internally like this:

From the Debug menu choose Exceptions. Select Common Language Runtime
Exceptions. Select Break into the debugger when the exception is thrown.

Now run some code that calls IsDate with an invalid date. You should get
this message:

"A first chance exception of type 'System.FormatException' occurred in
mscorlib.dll

Additional information: The string was not recognized as a valid DateTime.
There is a unknown word starting at index 0."

So I am assuming that IsDate throws an exception internally when it is sent
an invalid date. Then IsDate catches the exception and returns False.

I guess the real proof would be to look at the IL code.

Kerry Moorman

 

[Cor Ligthert]

Armin

Ok ok, I've read it now. (sometimes we forget the simple things
(searched for TryParse first)) But, what do C# people do? That's probably
why I didn't think of IsDate. Furthermore, *if* you use IsDate you should
also use CDate instead of Date.Parse.

Exactly. I am as well active in the dotNet general newsgroup. You understand
the discussions that has been?

One of few VisualBasic methods beside this that I like very much is the
CDate (because it converts as well very easy Database Items. The docs from
MSD say that this conversion methods are much improved comparissing with VB6
and that there is not any reason not to use them. In contrary it is advised.

By the way, there is somebody in this newsgroup active who does not agree
this with me.



Cor

 

[Cor Ligthert]

"Armin Zingler">

I see three ways to convert:

System.Parse
System.Convert (ToDateTime)
CDate



Cor

 

[Armin Zingler]

"Armin Zingler">

?

System.Convert (ToDateTime)

only calls date.parse.

CDate

That's only relevant to the programmer, not the user, above all for historic
reasons (VB6). CDate expects an object, date.parse expects a string. If you
pass as string, there's no difference to date.parse.

I wanted to show the three main levels of format limitation (strict,
flexible, user defined) rather than showing all available methods.

Armin

 

[Armin Zingler]

Armin
Exactly. I am as well active in the dotNet general newsgroup. You
understand the discussions that has been?

No, I don't read that group.
I don't ask further because it's probably been discussed already.

One of few VisualBasic methods beside this that I like very much is
the CDate (because it converts as well very easy Database Items. The
docs from MSD say that this conversion methods are much improved
comparissing with VB6 and that there is not any reason not to use
them. In contrary it is advised.

By the way, there is somebody in this newsgroup active who does not
agree this with me.

I think, I know him. ;-)

Armin

 

[Cor Ligthert]

Armin,

Oh, if that means the same in German as Dutch

(Glad that you declared it to me, I understood you wrong)



Cor

 

[Jason Pettys]

Extracted from full quote below:

As a string input is usually taken from
the user - you know, the slowest part of the chain - there is absolutely no
need to optimize this process.

If you had a high-traffic ASP.NET site with a lot user-entered date
validation required, is there still "absolutely no need to optimize this
process"?

Jason

 

[Armin Zingler]

Extracted from full quote below:


If you had a high-traffic ASP.NET site with a lot user-entered date
validation required, is there still "absolutely no need to optimize
this process"?

If you have one user sitting in front, is there any reason to forbid
Try/Catch?


Armin

 

[Jason Pettys]

If you have one user sitting in front, is there any reason to forbid
Try/Catch?

I don't understand your question. As I said in my first reply to the
OP: "It probably wouldn't matter much on a Win Forms app, but I would
really back away from this on ASP.NET if you're expecting any volume of
traffic."

In the latter case I would anticipate that a lot of unnecessary
exceptions would cause a noticeable performance penalty. In the former
case I think one could get by with a Try/Catch. I guess my point was
that there are cases where optimization should be a concern even when
the only validation is of user-entered data, and one should be aware of
both sides when picking how to validate dates.

Don't you agree that a developer should be aware that in some cases the
exception-based approach can be a performance problem?

Jason