我考虑到根据规格， 应该在位于意大利的服务器上运行，客户只能是意大利人。
大约一个月前，我的老板决定将其全部用于Azure。
一切顺利。唯一能给我带来一些问题的是时间服务器是UTC。
解决方案是：
A）简单
将启动脚本修改为服务器时间（ http://netindonesia.net/blogs/wely/archive/2011/06/26/setting-timezone-in-windows-azure.aspx ）
B）更加费力
更改以使任何应用程序使用UTC并显示正确转换为当地时间的时间。
如果我选择解决方案A，我怀疑服务器设置了不同时区的事实可能会以某种方式与Azure产生冲突。
这是真的吗？
答案 0 :(得分：12)
我已经要求MS支持。
这是回复：
建议不要使用启动任务更改Azure虚拟机上的服务器时间，您应该在代码中使用TimeZoneInfo.ConvertTimeFromUTCTime等方法。
所以我不会改变服务器时区。 等待来自支持的响应我发现SqlServer 2008具有完美的DateTimeOffset数据类型！
答案 1 :(得分：4)
几年前，我已经开始设计我的所有应用程序，从而在客户端和服务器上使用UTC处理日期，并且从那以后就没有回头了。
答案 2 :(得分：2)
在客户端和服务器端，DateTime.Now和DateTime.Today存在两个问题。 将DateTime对象从客户端传递到Azure时，其Kind等于Local，它包含时区信息。 （2011年6月10日，上午12:30 - 7）
但是，将数据保存到数据库时，区域信息将丢失。随后，当从数据库中读取此字段时，它会创建具有Utc区域的DateTime（2011年6月10日，上午12:30 0）
最终，您的客户端错误地读取了日期时间。
在客户端有几种方法可以解决此问题。
1）在方法参数和数据库中将DateTime转换为DateTimeOffset。这将保证您的本地区域（即PST）将保存在db
中2）使用DateTime.SpecifyKind（dateTime，DateTimeKind.Unspecified） - 这样就没有指定DateTime的类型，并随后保存在db中。
var timeNow = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
serviceClient.SaveTime(timeNow);
var dateTime = serviceClient.GetTime();
小心在服务器端调用DateTime.Now。您最好使用DateTime.UtcNow。此时间不应用于业务数据。理想情况下，您需要重构代码并从客户端传递DateTime或DateTimeOffset。