Migration from local server to Azure: TIMEZONE UTC. How to solve?

Question

I designed my application considering the fact that, according to the specifications, should run on a server located in Italy and clients will be italian people only.

<

Answer 1

A couple years ago I have begun designing all of my apps to consequently handle dates using UTC on both client and server and haven't looked back since.

Answer 2

There are two issues with DateTime.Now and DateTime.Today on a client side and server side. When you pass DateTime object from client to Azure its Kind equals to Local and it contains time zone information. (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 on a client side.

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.

var timeNow = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
serviceClient.SaveTime(timeNow);
var dateTime = serviceClient.GetTime();

Be careful to call DateTime.Now on a server side. You better use DateTime.UtcNow. This time shouldn't be used for business data. Ideally, you would need to refactor your code and pass DateTime or DateTimeOffset from the client.

Answer 3

I have asked to MS support.

This is the response:

Changing the server time on the Azure Virtual Machines using a startup task is not recommended, you should rather use methods like TimeZoneInfo.ConvertTimeFromUTCTime in your code.

So I will not change the server timezone. Waiting for a response from the support I discover that SqlServer 2008 have a DateTimeOffset data type that is perfect!

http://blogs.msdn.com/b/davidrickard/archive/2012/04/07/system-datetime-good-practices-and-common-pitfalls.aspx