date.parse problem
-
Hello I have been trying to debug a problem with a web app that I am responsible for and have traced it down to a very specific problem. To demonstrate that problem, I have written a little web app, and I'm sure someone here can direct me quickly to the source of the problem.
Try Me.Label1.Text = "" Me.Label1.Text = Date.Parse(Me.TextBox1.Text).ToShortDateString Catch ex As Exception Me.Label1.Text = ex.Message End TryWhen I run this on serverA it with the input of '7/30/2007' it fails with the exception message being: 'String was not recognized as a valid DateTime' When I run it on any other server, it works fine. On serverA, if I input '30/1/2007' it works. If I input that value on any of my other servers it fails with 'String was not recognized as a valid DateTime' The question is, what server configuration value do I need to change on the server to make that server behave the same as the other servers. These are all windows server 2003 servers, and I checked the regional settings in Control panel and the failing and passing servers have the same regional settings values (english US) and the same long/short date format in the regional settings. Apparently that does not affect this date.parse behavior. This kind of problem scares me because it introduces a significant likelihood of wierd flaky problems and behavior. If the date value had been '2/5/2007' it would've worked on both servers and it would have been hard to identify why all the data was messed up. Any help or guidance would be appreciated.
-
Hello I have been trying to debug a problem with a web app that I am responsible for and have traced it down to a very specific problem. To demonstrate that problem, I have written a little web app, and I'm sure someone here can direct me quickly to the source of the problem.
Try Me.Label1.Text = "" Me.Label1.Text = Date.Parse(Me.TextBox1.Text).ToShortDateString Catch ex As Exception Me.Label1.Text = ex.Message End TryWhen I run this on serverA it with the input of '7/30/2007' it fails with the exception message being: 'String was not recognized as a valid DateTime' When I run it on any other server, it works fine. On serverA, if I input '30/1/2007' it works. If I input that value on any of my other servers it fails with 'String was not recognized as a valid DateTime' The question is, what server configuration value do I need to change on the server to make that server behave the same as the other servers. These are all windows server 2003 servers, and I checked the regional settings in Control panel and the failing and passing servers have the same regional settings values (english US) and the same long/short date format in the regional settings. Apparently that does not affect this date.parse behavior. This kind of problem scares me because it introduces a significant likelihood of wierd flaky problems and behavior. If the date value had been '2/5/2007' it would've worked on both servers and it would have been hard to identify why all the data was messed up. Any help or guidance would be appreciated.
This is asked so often. The regional settings are obviously different, no matter what you think, and either way, apart from the terrible naming conventions, no production code should ever use Date.Parse, that's what Date.TryParse is for. I wouldn't actually sack someone for writing this code, but there's quite a number of htings I'd be having a talk to them about. You will always face this issue - if you're moving dates from strings, you risk getting the wrong dates unless you can be sure of the setup on the server. Either way, it's best avoided. I'm all for using a 17 Feb 1969 format, as it's unambiguous.
Christian Graus Driven to the arms of OSX by Vista.
-
This is asked so often. The regional settings are obviously different, no matter what you think, and either way, apart from the terrible naming conventions, no production code should ever use Date.Parse, that's what Date.TryParse is for. I wouldn't actually sack someone for writing this code, but there's quite a number of htings I'd be having a talk to them about. You will always face this issue - if you're moving dates from strings, you risk getting the wrong dates unless you can be sure of the setup on the server. Either way, it's best avoided. I'm all for using a 17 Feb 1969 format, as it's unambiguous.
Christian Graus Driven to the arms of OSX by Vista.
I love pompous know-it-all responses that don't answer the question. Christian, it seemed pretty obvious that the code was written for purposes of demonstrating the problem and was not supposed to be "production code". Feel free to spend as much time as you'd like refactoring it and bringing it up to your standard. I did some additional reading, and found this very helpful knowledge base article about stabilizing culture specific behavior in asp.net apps - if anyone else has a similar question in the future.. http://support.microsoft.com/kb/326943[^]