views:

90

answers:

3

I have an asp.net mvc calendar application (using jquery ui datepicker) and i am running into a weird situation where when i test on a US webserver i see a certain date and when i test on a London web server i see a different date (the date before)

Here are the details:

I am storing a date in sql server as:

 2010-09-16 00:00:00.000

I am then loading that into C# DateTime object.

I need to pass that down as part of a json object to my clientside javascript so i was suggested this solution:

jsonobject.Date = UnixTicks(a.Date),

where UnixTicks is:

private static double UnixTicks(DateTime dt)
    {
        DateTime d1 = new DateTime(1970, 1, 1);
        DateTime d2 = dt.ToUniversalTime();
        TimeSpan ts = new TimeSpan(d2.Ticks - d1.Ticks);
        return ts.TotalMilliseconds;
    }

I am then converting it to a javascript date by using this code below on the client side:

var d = new Date(jsonobject.Date);

does anyone know why given a US server or a London server i would get back a different date. At first, i thought it was the

 DateTime d2 = dt.ToUniversalTime();

but i changed that to:

 DateTime d2 = dt;

and still saw the same issue. (on London web server date would show up 1 day prior to the US web server)

any suggestions?

+2  A: 

If you're storing local time in the database instead of UTC, then you could get different dates back when converting back to local time. Make sure your dates are converted to UTC before you commit them to the database. If you want everyone to always see the same date no matter where they are, always return the UTC date- do not convert back to local time.

Dave Swersky
@Dave Swersky - are you saying do this on the javascript side or on the C# side ??
ooo
It depends on what you want. If you want everyone to see the same date no matter what, make sure you are *both* storing the date as UTC, and presenting it as UTC with no conversion when you send it in your json. This may mean you have to convert *to* UTC on the way to the database, depending on how those dates are entered.
Dave Swersky
@Dave Swersky - im confused. I have a date which is November 19th, 2010. i dont have any interest in dealing with time at all and thus UTC or timezone. Is there not a reason why i can't just keep it as the same date front to back. maybe just pass as a string ??
ooo
@ooo: You may be able to get around the problem by dealing with short date time formats, but I haven't tried this specifically so I can't be sure. I wouldn't store dates as strings, or you'll eventually come back to this problem again when you have to convert them back into dates.
Dave Swersky
@Dave Swersky - i formatted at "March 14, 2010" as a string and problem went away
ooo
A: 

It's definitely a localization issue. You need to store your DateTime in the same Time Zone and account for different Date formatting. For instance, September 1st, 2010 in the US is formatted "9/1/2010" and in the UK it's formatted "1/9/2010". If you're looking at that as a US date, you're going to be looking at January 9th, 2010.

o6tech
@o6tech - its not that i am getting 1/9 versions 9/1. i am just getting 1 day off
ooo
I was listing that date format just as something to look out for. Other possibilities would be time zones, incorrect time on one of the machines, or Daylight Savings. I know Daylight Savings was a pain a few years back when the US changed the date and the UK did not.
o6tech
@o6tech - i basically want to eliminate any use of time at all. I just want to deal with the date front to back. is there anyway to just do this? should i just convert to string.
ooo
I see what you're saying and honestly don't know why the date is coming back different without the ability to test and debug myself. If you used a string, as you suggested, the problem would certainly disappear (but you still need to watch for the date formatting difference -- I would use a format like "Jan 1 2010")
o6tech
@o6tech - i formatted at "March 14, 2010" as a string and problem went away
ooo
A: 

if you just want to completely ignore the time zone and localization issue, just present the dates as strings to your application:

SELECT
    CONVERT(varchar(10),YourDatetimeColumn,111) AS StringDate1  --YYYY/MM/DD
   ,CONVERT(varchar(10),YourDatetimeColumn,121) AS StringDate2  --YYYY-MM-DD
    FROM ...

and then just use them within the application like regular string data and they will not change or be adjusted for you.

KM
KM - i did do this but in my code (not in my SQL)
ooo