validating dates and times

[raulavi]

Hi:
(I know there are lots of different ways to do it) no regex, please
if we have string date yyMMdd "080230" whats the best way to test for valid
date ?
Feb will never have 30 days,

2)
if we have string HHmm "3490" whats the best way to test for valid time?
(worng hours wrong minutes)


Thanks for your ideas

 

[Jon Skeet [C# MVP]]

(I know there are lots of different ways to do it) no regex, please
if we have string date yyMMdd "080230" whats the best way to test for valid
date ?
Feb will never have 30 days,

I'd use DateTime.TryParseExact, specifying the appropriate format.

2)
if we have string HHmm "3490" whats the best way to test for valid time?
(worng hours wrong minutes)

Ditto.

 

[pipo]

1)
DateTime test;
try
{
test = DateTime.ParseExact("080230", "yyMMdd",
CultureInfo.InvariantCulture);
}
catch (System.FormatException form)
{
//Not a valid date.
}
2)
The same but then the other format.

 

[Jon Skeet [C# MVP]]

1)
DateTime test;
try
{
test = DateTime.ParseExact("080230", "yyMMdd",
CultureInfo.InvariantCulture);
}
catch (System.FormatException form)
{
//Not a valid date.
}
2)
The same but then the other format.

Why raise an exception when TryParseExact does exactly what you need to
do, but without throwing?

 

[Pipo]

Where do you see the throwing??

If the date isnt valid a FormatException will occure.

 

[Pipo]

Oops, check you are right!!

Why raise an exception when TryParseExact does exactly what you need to
do, but without throwing?

 

[raulavi]

thank you both for the tip.

Jon:
you lost me,

Why raise an exception when TryParseExact does exactly what you need to
do, but without throwing?<

Could you detail what it will happen when date is wrong and TryPaseExact
thanks

 

[Pipo]

Then it will return False.

thank you both for the tip.

Jon:
you lost me,

Could you detail what it will happen when date is wrong and TryPaseExact
thanks

 

[Jon Skeet [C# MVP]]

you lost me,

Could you detail what it will happen when date is wrong and TryPaseExact

Have you read the documentation for TryParseExact?

Basically it's like ParseExact, but it returns true/false to say
whether or not the parse succeeded, and takes an out parameter to store
the actual result in.

 

[Alun Harford]

Why raise an exception when TryParseExact does exactly what you need to
do, but without throwing?

I would say it depends on what you're doing.

If you expect your input to be a date, throwing an exception seems to be
perfectly reasonable - it clearly says, "Something went wrong. I'm now
doing error handling".

Alun Harford

 

[Jon Skeet [C# MVP]]

I would say it depends on what you're doing.

Well, look at the context of the previous post - Pipo's code was
swallowing the exception and returning false. TryParseExact has the
same behaviour but with less hassle and better performance.

If you expect your input to be a date, throwing an exception seems to be
perfectly reasonable - it clearly says, "Something went wrong. I'm now
doing error handling".

Look at the OP - the whole point of the thread is to *test* whether the
input is a valid date or not. When you're expecting potentially invalid
input, an exception isn't appropriate IMO.

 

[Alun Harford]

Well, look at the context of the previous post - Pipo's code was
swallowing the exception and returning false.

I assumed that it was just a snippet and in real code some error
handling would go in the catch block.

TryParseExact has the
same behaviour but with less hassle and better performance.


Look at the OP - the whole point of the thread is to *test* whether the
input is a valid date or not. When you're expecting potentially invalid
input, an exception isn't appropriate IMO.

I suspect I disagree with you there...

If I have some networking protocol and the spec says that I should get a
string that looks like a date, throwing an exception seems entirely
reasonable.
If I receive user input that I expect to be a date, I think throwing an
exception is probably reasonable - it clearly states that something went
wrong, we can't proceed, and all we can do is error handling (probably
informing the user in this case).
If I have a random bunch of strings and I want to find out which are
valid dates, it's time to use TryParseExact.

Alun Harford

 

[Jon Skeet [C# MVP]]

I assumed that it was just a snippet and in real code some error
handling would go in the catch block.

Nope, just answering the OP's question. Both mine and Pipo's code do
that, but mine is cleaner IMO.

I suspect I disagree with you there...
Possibly.

If I have some networking protocol and the spec says that I should get a
string that looks like a date, throwing an exception seems entirely
reasonable.

In that case I'd agree.

If I receive user input that I expect to be a date, I think throwing an
exception is probably reasonable - it clearly states that something went
wrong, we can't proceed, and all we can do is error handling (probably
informing the user in this case).

I don't think an exception is called for in that case. Chances are:
a) you're going to be explicitly testing for that case
b) you're not going to use anything about the exception itself,
other than the fact it was thrown. The details are irrelevant.

I think in that case using TryParseExact would be the right way to go.

If I have a random bunch of strings and I want to find out which are
valid dates, it's time to use TryParseExact.

I don't think that happens often, but validating user input does - and
I don't think it merits an exception.

I don't *expect* users to get things right