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