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.

About a month ago, my bos decided to bring it all on Azure.

Everything went smoothly. The only thing that give me some problem is the fact that the time server is UTC.

The solutions are:

A) simple

modify a startup script to the server time ( http://netindonesia.net/blogs/wely/archive/2011/06/26/setting-timezone-in-windows-azure.aspx )

B) more laborious

Change to make any application to use UTC and show the time properly converted to local time.

If i go for the solution A my doubt is that the fact that the server is set up with a different timezone can somehow create conflicts with Azure.

This is true?

Solution 1

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

Solution 2

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.

Solution 3

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.

Comments

[Boris Lipschitz]

@Bugeo when DateTime object is deserialized and Kind is Local it sets the new DateTime adjusted to a new timezone, while keeping the record of difference between 2 timezones.

[Marco Staffoli]

What you think about DateTime vs DateTimeOffset