 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / March 2008validating dates and times
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 > (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.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk 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. >> (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 [quoted text clipped - 10 lines] > > Ditto. > 1) > DateTime test; [quoted text clipped - 9 lines] > 2) > The same but then the other format. Why raise an exception when TryParseExact does exactly what you need to do, but without throwing? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk Where do you see the throwing?? If the date isnt valid a FormatException will occure. >> 1) >> DateTime test; [quoted text clipped - 12 lines] > Why raise an exception when TryParseExact does exactly what you need to > do, but without throwing? Oops, check you are right!! >> 1) >> DateTime test; [quoted text clipped - 12 lines] > Why raise an exception when TryParseExact does exactly what you need to > do, but without throwing? 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 > > 1) > > DateTime test; [quoted text clipped - 12 lines] > Why raise an exception when TryParseExact does exactly what you need to > do, but without throwing? Then it will return False. > thank you both for the tip. > [quoted text clipped - 22 lines] >> Why raise an exception when TryParseExact does exactly what you need to >> do, but without throwing? > 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 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. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >> 1) >> DateTime test; [quoted text clipped - 12 lines] > 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 > > 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. 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. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk >>> 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. > > 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. [quoted text clipped - 6 lines] > 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 > > 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. :-) Nope, just answering the OP's question. Both mine and Pipo's code do that, but mine is cleaner IMO. > > 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... 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 :) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.