validating dates from string input

  • Thread starter Thread starter John Livermore
  • Start date Start date
J

John Livermore

In C# what is the best way to validate that a particular string
entered by a user will actually convert to a date w/o using a try
catch block or writing code to explicitly parse the string?

Here is what I know I can use, but there are potentially thousands of
dates to validate, and I know this code is inefficient if there are
lots of dates that won't convert...

private DateTime ValidateDate(string date)
{
DateTime convertedDate = DateTime.MinValue;
try
{
convertedDate = DateTime.Parse(date);
}
catch
{
// throw exception for invalid date
}
return convertedDate;
}

Thanks,
John
 
John,

You can use the code you have, or, if you have access to the .NET 2.0
beta, you can use the static TryParse or TryParseExact method on the
DateTime structure.

Another option would be to call the static IsDate method on the
Interaction class in the Microsoft.VisualBasic namespace. It is a little
more lenient than the TryParse and the TryParseExact methods.

Hope this helps.
 
John said:
In C# what is the best way to validate that a particular string
entered by a user will actually convert to a date w/o using a try
catch block or writing code to explicitly parse the string?

Is there a particular reason that you can't use try/catch?
Here is what I know I can use, but there are potentially thousands of
dates to validate, and
I know this code is inefficient if there are
lots of dates that won't convert...

How do you know it is inefficient?

Do you have specific performance requirements that aren't being met? If not,
don't worry about the performance.

The first rule of optimization is: don't do it.
 
I have read in many places that try...catch is a means of detecting
errors but it shouldn't be used if you know the error might occur.
Rather you should use other means to detect the condition.
Try...catch is for errors you don't know are going to occur (bugs) to
keep your application behaving nicely.

Your point of don't fix it unless it is broken is well taken, but I
feel this will be an issue for us and should be addressed through some
other means.

We are exploring the use of regular expressions to validate the input
before we attempt to cast it as a date.
 
John said:
I have read in many places that try...catch is a means of detecting
errors but it shouldn't be used if you know the error might occur.
Rather you should use other means to detect the condition.
Try...catch is for errors you don't know are going to occur (bugs) to
keep your application behaving nicely.

You are right, try/catch is for exceptional circumstances -- in theory. If the
framework provided the necessary methods (such as IsDate()), then try/catch
wouldn't be necessary in this case. Since it doesn't, using try/catch is
perfectly acceptable.
Your point of don't fix it unless it is broken is well taken, but I
feel this will be an issue for us and should be addressed through some
other means.

We are exploring the use of regular expressions to validate the input
before we attempt to cast it as a date.

I was going to suggest regex as well, but didn't. You will probably end up w/
a horrendous piece of code that is difficult to maintain, hard to understand,
and susceptible to a multitude of errors. As I'm sure you are well aware,
date/time formats are locale-dependent.

Further, I wouldn't be surprised in the least if the regex version of what you
come up with is quite a bit slower than the try/catch version. I'd be
interested to hear what you find after you write the regex version and compare
it to the try/catch version...

Good luck.
 
Back
Top