By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,584 Members | 1,750 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,584 IT Pros & Developers. It's quick & easy.

Checking for a valid date

P: n/a
What's the easiest way to verify the user had entered a valid date ?
Nov 21 '05 #1
Share this Question
Share on Google+
28 Replies


P: n/a
"romy" <ro******@Powerup1.com> schrieb
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

Nov 21 '05 #2

P: n/a


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


The IsDate() function.

--
Larry Lard
Replies to group please

Nov 21 '05 #3

P: n/a
"romy" <ro******@Powerup1.com> schrieb:
What's the easiest way to verify the user had entered a valid date ?


'Microsoft.VisualBasic.Information.IsDate'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #4

P: n/a
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
Armin Zingler wrote:
"romy" <ro******@Powerup1.com> schrieb
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

Nov 21 '05 #5

P: n/a
Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

"Jason Pettys" wrote:
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
Armin Zingler wrote:
"romy" <ro******@Powerup1.com> schrieb
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

Nov 21 '05 #6

P: n/a
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/.../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/vsnet...293037,00.html

Jason

www.pettysconsulting.com
Kerry Moorman wrote:
Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

"Jason Pettys" wrote:

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
Armin Zingler wrote:
"romy" <ro******@Powerup1.com> schrieb
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

Nov 21 '05 #7

P: n/a
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
Nov 21 '05 #8

P: n/a
"Jason Pettys" <pe****@nospam.nospam> schrieb:
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
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #9

P: n/a
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
"Jason Pettys" wrote:
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/.../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/vsnet...293037,00.html

Jason

www.pettysconsulting.com
Kerry Moorman wrote:
Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

"Jason Pettys" wrote:

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
Armin Zingler wrote:

"romy" <ro******@Powerup1.com> schrieb
>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

Nov 21 '05 #10

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb
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)

:-)


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

Nov 21 '05 #11

P: n/a
"Jason Pettys" <pe****@nospam.nospam> schrieb
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/.../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/vsnet...293037,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

Nov 21 '05 #12

P: n/a
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

Nov 21 '05 #13

P: n/a

"Armin Zingler">
I see three ways to convert:

System.Parse
System.Convert (ToDateTime)
CDate

:-)

Cor
Nov 21 '05 #14

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb

"Armin Zingler">
I see three ways to convert:
System.Parse


?
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

Nov 21 '05 #15

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb
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?


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
Nov 21 '05 #16

P: n/a
Armin,

Oh, if that means the same in German as Dutch

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

:-)

Cor
Nov 21 '05 #17

P: n/a
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 wrote: "Jason Pettys" <pe****@nospam.nospam> schrieb
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/.../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/vsnet...293037,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

Nov 21 '05 #18

P: n/a
"Jason Pettys" <pe****@nospam.nospam> schrieb
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"?


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

Nov 21 '05 #19

P: n/a
Armin Zingler wrote:
"Jason Pettys" <pe****@nospam.nospam> schrieb
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"?

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
Nov 21 '05 #20

P: n/a
"Jason Pettys" <pe****@nospam.nospam> schrieb
Armin Zingler wrote:
"Jason Pettys" <pe****@nospam.nospam> schrieb
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"?

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


I don't understand your question.


Just like I didn't understand yours.
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."
I didn't know the client machine is not able to check this. Such a lot of
resources wasted!
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?


I do agree. What I explained in my previous post: If you want to use
date.parse, you must use try/catch for the reasons given. By saying "use
date.parse" I mean "permit the format(s) that date.parse permits". If you
don't use date.parse, it's up to you, of course.

Armin

Nov 21 '05 #21

P: n/a
Jason,

I find it a much larger problem that I cannot find how to get the
language/culture setting the client is using on the serverside.

Therefore I have probably only seen on a webpage three textboxes with day,
month, year while that is than checked using javascript. That gives as extra
(not that important) few traffic.

However if you have a very good method to get the language/culture setting
from the client on server side, than I will be much obliged.

Just my thought,

Cor
Nov 21 '05 #22

P: n/a
Cor,

an OT question: do you see my reply to Jason from today, 02:03 AM? When I
posted the message (and two other messages), it appeared in my OE as a new
message, but when I clicked on it, it was thriked through as if it has been
deleted from the server (and I did not delete it). As written above, this
happens to another message, but I did get a reply to it, so I think it must
have been on the server. It was a message in the thread "How to compare
objects using their typecode". I can see only one answer from me from 22:29
yesterday, but not the one from today, 02:46. Do you see still it?

Thx a lot, Cor, if you could have a look, and sorry ppl for asking here!

Armin

P.S: I also have the problem that I am told about 6 new messages in this
group (since Sunday) but when I try to download them they don't seem to
exist - then they are back again...and gone...there...gone... :( Maybe I
should reset my news reader.

Nov 21 '05 #23

P: n/a
Cor,

Stooop! I reset the group in the news reader and eveything seems to be fine
now. Sorry for wasting your time (if you already did ;-) )! (I should have
done this before...)

Armin

Nov 21 '05 #24

P: n/a
Armin,

I was starting to hanlde it, glad you messaged this (what I would expect
from you)

I don't know how fast at the moment your connection is. However some months
they had not set the retention time. The newsgroups where growing and
growing.

You understand probably what this means for dial up users.

Now it is luckily 2 months again.

Cor
Nov 21 '05 #25

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb
I was starting to hanlde it, glad you messaged this (what I would
expect from you)

I don't know how fast at the moment your connection is. However some
months they had not set the retention time. The newsgroups where
growing and growing.

You understand probably what this means for dial up users.

Now it is luckily 2 months again.

As I still have the problem that there are 7 new posts that disappear as
quickly as they appeared, I activated NNTP logging. From the log file I see
that there seems to be something going on on the server. Very short example
(lines received from the news server):

13:39:30 [rx] 211 9083 276748 285823 microsoft.public.dotnet.languages.vb
13:42:15 [rx] 211 29394 1 285825 microsoft.public.dotnet.languages.vb

The 3 numbers after 211 are:
9083 = approximate number of posts in the group
276748 = number of first article
285823 = number of last article

As you see in the second line (only 3 mins later) the numbers changed
totally. This happens almost each time the group is accessed. Well, let's
wait till this stops.
I write this here because others might also have problems with this group
(not with the ppl but the download ;)

Armin

Nov 21 '05 #26

P: n/a
Armin,

Your message as reply to Jason I see in my newsreader.
I replied it as well with a complete different text, because I find it a
long time a problem that I cannot get the used culture/language on the
client computer when he is using IE, and maybe Jason has an answer for that.

This is a part of your message
I don't understand your question.

Just like I didn't understand yours.
You know that Google is great now with these newsgroup.
This is this thread
http://groups-beta.google.com/group/...8e2533ae754cae

This is the address to it
http://groups-beta.google.com/group/...n&lr=&ie=UTF-8

Cor
Nov 21 '05 #27

P: n/a
"Armin Zingler" <az*******@freenet.de> schrieb:
P.S: I also have the problem that I am told about 6 new messages in this
group (since Sunday) but when I try to download them they don't seem to
exist - then they are back again...and gone...there...gone...


The same here...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #28

P: n/a
The easiest way is to use the DateTime Picker for user input to ensure he
inputs a valid date.
--
Dennis in Houston
"romy" wrote:
What's the easiest way to verify the user had entered a valid date ?

Nov 21 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.