dates behaving differently on different dbs?

I have an asp.net webpage, with a jQuery datepicker on it.

I am in the UK, so when I enter 28/02/2010, I expect it to resolve to 28th Feb 2010.

This is working as expected on my local dev env - but not on our QA or prod-like envs - or one of the other dev machines. In these cases it seems to attempt to resolve it to American date format - and fails validation as it is out of range.

The jQuery seems to generate the correct date each time - which leads me to think it may be a database issue.

I am using SQL Server 2005, my collation is Latin1_General_CI_AS, my colleagues are using collation SQL_Latin1_General_CP1_CI_AS, and a Chinese one.

Given that we don't have control over the prod SQL Server installation (just our db), what is the best way to make this work in a standard way? Change the db settings, or the code that uses it?

Thanks in advance! - L

[EDIT to add code info]

This is my view code to call the datepicker:

 <%=Html.TextBox("DateOfBirth", Model.DateOfBirth.ToShortDateString(), new { @class = "datepicker" })%>

Here is the js for the datepicker:

DatePickerSettings = {
    setup: function () {
        $(".datepicker").datepicker({
            dateFormat: 'dd/mm/yy',
            changeMonth: true,
            change开发者_JAVA百科Year: true
        });
    }
};

And this is how I specify the date in the model:

[Required]
[DisplayName("Date of Birth")]
public virtual DateTime DateOfBirth { get; set; }

The date appears correct inthe controller and repository... until it hits the db.

Thanks :)

---

I was hoping to wait until you'd updated the question with some more information, but as I've seen some answers suggesting that you change the string format you use to talk to the database...

Don't send dates as raw text in SQL queries.

Use a parameterized query, which means you don't need to worry about formatting the value at all. Then you've just got to make sure that you can get the date format correct between the browser and ASP.NET.

Aside from anything else, if you're including user data in SQL queries directly, you'll generally be opening yourself up to SQL injection attacks. Always use parameterized queries (unless your web app is really a "run this SQL" test tool...)

If you're already using parameterized queries, then the problem is likely to be between the browser and ASP.NET, and the database part is irrelevant. Divide and conquer the problem: chase the data as it passes through different layers (browser, jQuery, ASP.NET etc) until you find out where it's gone wrong. Don't even think about a fix until you know where it's gone wrong.

---

Is your page Culture aware? You can determine UI Cutlure information for different browsers(locales) and have your ASP.NET Culture constant.

The Culture value determines the results of culture-dependent functions, such as the date, number, and currency formatting, and so on. The UICulture value determines which resources are loaded for the page

Check out this MSDN link: How to: Set the Culture and UI Culture for ASP.NET Web Page Globalization

http://msdn.microsoft.com/en-us/library/bz9tc508(v=VS.85).aspx

---

Use CONVERT to change the date format to a standard that is accepted across all environments.

CAST and CONVERT

---

I'd have to see the code that interprets the dates to know for sure, but a likely suspect is the Region and Language settings on the machines where the code is running. Make sure it is set appropriately for your region.

However, if you can't change settings on the servers, you should probably explicitly use CAST or CONVERT in SQL Server to force it to parse it in the region specific way you expect the data will be entered.

---

You also need to check your ASP.Net layer, and see what it is running in.

Check the machine configuration and check they are set to run in the same date/time/region.

---

Change your code to use yyyymmdd format. As far as i know it works in all the DBs

---

Just to add another opinion here, I find dd/mmm/yyyy the best date format to send to databases as it's completely unambiguous across cultures.