I have a predictions-based app that’s up on Windows Azure ( http://ipredikt.com ). From what I can tell Azure’s clock is synchronized to the GMT time zone. Here is a problem that I am encountering:
Let’s say I have a DB field called CreateDate of type DateTime and I set its value to June 10, 2011, 12:30am. when a new prediction is created. If I peek inside the db table the date is correctly set. I don’t touch or change this value in any way. However, when I read the value with our API, serialize it and send it to the client I get a date with the value of June 09, 2011, 5:30 pm. (The API dll also lives on the cloud and probably is collocated with the DB.)
My client browser is running in the PST (pacific time zone) and it seems that the 7 hour difference is due to the difference between PST and GMT. The API code used to serialize the value is similar to this:
System.Web.Script.Serialization.JavaScriptSerializer serializer = new JavaScriptSerializer();
return serializer.Serialize(dataObject);
Is this a bug in JavaScriptSerializer object or is there a trick to fix this delta? Basically, I don’t want the .NET framework to interfere with this value in any way, I just want the DB field to just get returned as is.
When you pass DateTime object to Azure its Kind equals to Local.
(June 10, 2011, 12:30am -7)
However, when you save it to the database the region information is lost. Subsequently, when reading this field from the database it creates DateTime with a Utc region
(June 10, 2011, 12:30am 0)
Eventually, your client reads the datetime incorrectly.
There are several options to resolve this issue.
1) Convert DateTime to DateTimeOffset in Method parameters as well as in database. This will guarantee that your Local region (ie PST) will be saved in db
2) Use DateTime.SpecifyKind(dateTime, DateTimeKind.Unspecified) – this way the kind of DateTime is unspecified and subsequently saved as is in the db.