问题
I have a TextBox server control on a Web Form, say, txtDueDate. I don't want to use DateTimePicker but want to use TextBox itself. The user enters date in dd/mm/yyyy format.
While passing this value to SQL Server 2005 (Express) stored procedure, I use something like:
cmdParameters.AddWithValue("@DueDate", Convert.ToDateTime(txtDueDate.Text));
The stored procedure has input parameter to handle this value and is declared as:
@DueDate SmallDateTime
I want to know the default format SQL Server 2005 uses internally to store this date. On my PC, the Windows XP Regional Settings are set to dd/mm/yyyy format. While viewing records through Management Studio, it is stored correctly. But I am worried about users who will be using this web application. The Windows Regional Settings may differ on their PC.
I want to be sure whoever queries the database, the date is displayed in dd/mm/yyyy format. If someone inserts, 02/01/2004, then it should not become a valid reverse date like: 01/02/2004.
回答1:
A DateTime is a DateTime is a DateTime - it doesn't "have" any (string-oriented) format when stored in SQL Server (it's stored as a 64-bit long). If you pass in a parameter to a stored procedure as a DateTime already, you should be just fine! The value will be stored by SQL Server without changing any formatting - since it doesn't have any formatting associated with it...
The only point the date is represented in a given string format is when you look at it in SQL Server Management Studio, or when you convert it to a string format in e.g. your .NET app.
When you need to somehow pass in a string-representation into SQL Server (e.g. for searching etc.), the one that's the most robust and will work with any regional/language setting is the ISO-8601 date format: YYYYMMDD or alternatively (if you need the time portion) YYYY-MM-DDTHH:MM:SS (where the T in the middle is a literal, separating the date and time portions)
回答2:
DateTime values shouldn't be stored as a text-based format in the database anyway - and it sounds like they're not. You should just treat them as DateTime values. How those values are formatted on the way out is up to whatever's querying the database, and you can't control that without basically just storing text, which you should not do. Treat the value in its "native" format for as much of the time as possible. Avoid conversions to and from string formats as far as you can.
I would also avoid just using Convert.ToDateTime(text) here - how certain are you that the system default format is the correct one to use here? Can you use a set of controls which give you the actual value instead of relying on what the user happens to type?
回答3:
You choices...
1) IF you're worried about users entering a wrong format (wrong as in DateTime.Parse throws an exception), then you need to validate the input
2) IF you're worried about users entering a wrong format (wrong as in DateTime.Parse throws an exception), then use a date picker.
回答4:
The conversion to date is done client side, by:
Convert.ToDateTime(txtDueDate.Text)
By default, this uses the current UI culture, but you can specify a culture with the second parameter:
Convert.ToDateTime(txtDueDate.Text, new CultureInfo("en-GB"))
来源：https://stackoverflow.com/questions/7957616/preserving-format-while-passing-datetime-values-to-stored-procedure