7

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?

Marco Staffoli
  • 2,475
  • 2
  • 27
  • 29
  • Option A sounds simple enough although you will have to make sure that it works with daylight saving time or you will find everthing is an hour out during the summer. When I had the same issue I opted to go with option B because then I wouldn't have any problems with people using the app abroad. – David Steele Jun 28 '11 at 15:29
  • Can you tell us a bit more about your architecture. Is it web based or windows client, does it go through web services etc. Then we should be able to help you more. – David Steele Jun 28 '11 at 15:32
  • All Windows Azure VMs are under UTC, and IMHO this is a very good design property of the cloud. Go for for B, you won't regret it. – Joannes Vermorel Jun 29 '11 at 11:40

3 Answers3

13

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

Marco Staffoli
  • 2,475
  • 2
  • 27
  • 29
4

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.

Oliver Weichhold
  • 10,259
  • 5
  • 45
  • 87
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.

Boris Lipschitz
  • 9,236
  • 5
  • 53
  • 63
  • @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. – Boris Lipschitz Jun 30 '11 at 00:30