Re: Checking for a valid date
- From: Jason Pettys <pettys@xxxxxxxxxxxxx>
- Date: Mon, 27 Jun 2005 15:32:06 -0500
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" <pettys@xxxxxxxxxxxxx> 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/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
>
.
- Follow-Ups:
- Re: Checking for a valid date
- From: Armin Zingler
- Re: Checking for a valid date
- References:
- Checking for a valid date
- From: romy
- Re: Checking for a valid date
- From: Armin Zingler
- Re: Checking for a valid date
- From: Jason Pettys
- Re: Checking for a valid date
- From: Kerry Moorman
- Re: Checking for a valid date
- From: Jason Pettys
- Re: Checking for a valid date
- From: Armin Zingler
- Checking for a valid date
- Prev by Date: Re: How to compare objects using their typecode
- Next by Date: SortedList question
- Previous by thread: Re: Checking for a valid date
- Next by thread: Re: Checking for a valid date
- Index(es):
Relevant Pages
|