|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Checking for a valid date"romy" <royal***@Powerup1.com> schrieb Call Date.Parse in a Try/Catch block. If there's no excecption the date was > What's the easiest way to verify the user had entered a valid date ? > > valid. Armin 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: Show quoteHide quote > "romy" <royal***@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 Jason,
Doesn't IsDate use this same technique internally? Kerry Moorman Show quoteHide quote "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" <royal***@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 > 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 Kerry Moorman wrote: Show quoteHide quote > 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" <royal***@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 >>
Show quote
Hide quote
"Jason Pettys" <pettys@nospam.nospam> schrieb I see three ways to convert:> 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 - 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">
> I see three ways to convert: System.Convert (ToDateTime)> System.Parse CDate :-) Cor"Cor Ligthert" <notmyfirstn***@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 Armin,
Oh, if that means the same in German as Dutch (Glad that you declared it to me, I understood you wrong) :-) CorExtracted from full quote below:
> As a string input is usually taken from If you had a high-traffic ASP.NET site with a lot user-entered date > the user - you know, the slowest part of the chain - there is absolutely no > need to optimize this process. validation required, is there still "absolutely no need to optimize this process"? Jason Armin Zingler wrote: Show quoteHide quote > "Jason Pettys" <pettys@nospam.nospam> schrieb http://searchvb.techtarget.com/vsnetTip/1,293823,sid8_gci960388_tax293037,00.html > >> 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: >> >> Show quoteHide quote >> > > > > 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 > "Jason Pettys" <pettys@nospam.nospam> schrieb If you have one user sitting in front, is there any reason to forbid > 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"? Try/Catch? Armin Armin Zingler wrote:
Show quoteHide quote > "Jason Pettys" <pettys@nospam.nospam> schrieb I don't understand your question. As I said in my first reply to the > >> 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? > > 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
Show quote
Hide quote
"Jason Pettys" <pettys@nospam.nospam> schrieb Just like I didn't understand yours.> Armin Zingler wrote: > > "Jason Pettys" <pettys@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 I didn't know the client machine is not able to check this. Such a lot of > 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." resources wasted! > In the latter case I would anticipate that a lot of unnecessary I do agree. What I explained in my previous post: If you want to use > 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? 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 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 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. 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 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 "Cor Ligthert" <notmyfirstn***@planet.nl> schrieb As I still have the problem that there are 7 new posts that disappear as> 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. 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 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/microsoft.public.dotnet.languages.vb/browse_frm/thread/f848e17efaa3403f/d88e2533ae754cae#d88e2533ae754cae This is the address to it http://groups-beta.google.com/group/microsoft.public.dotnet.languages.vb?hl=en&lr=&ie=UTF-8 Cor "Armin Zingler" <az.nospam@freenet.de> schrieb: The same here...> 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... -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> "Jason Pettys" <pettys@nospam.nospam> schrieb: According to Lutz Roeder's Reflector, the method's implementation looks like > 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? 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/> 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 Show quoteHide quote "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/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 > > > 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" <royal***@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 > >> > Armin,
> This is what internally iw done in IsDate> Call Date.Parse in a Try/Catch block. If there's no excecption the date > was valid. > (You can check it by setting the stop on all throwed events in the debugger) :-) Cor"Cor Ligthert" <notmyfirstn***@planet.nl> schrieb Ok ok, I've read it now. :-) (sometimes we forget the simple things> 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) > > :-) (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 Armin
> > Exactly. I am as well active in the dotNet general newsgroup. You understand > 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. > 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" <notmyfirstn***@planet.nl> schrieb No, I don't read that group.> 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? 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 I think, I know him. ;-)> 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. > > :-) Armin 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 "romy" <royal***@Powerup1.com> schrieb: 'Microsoft.VisualBasic.Information.IsDate'.> What's the easiest way to verify the user had entered a valid date ? -- M S Herfried K. Wagner M V P <URL:http://dotnet.mvps.org/> V B <URL:http://classicvb.org/petition/> The easiest way is to use the DateTime Picker for user input to ensure he
inputs a valid date. -- Show quoteHide quoteDennis in Houston "romy" wrote: > What's the easiest way to verify the user had entered a valid date ? > > > |
|||||||||||||||||||||||
Other interesting topics