.net – Azure现在返回TimeZoneInfo.Local.Id而不是“UTC”的“Coordinated Universal Time”的无效值....

从3月7日开始,东南亚地区的Azure服务器已经应用了修补程序,改变了.NET中TimeZoneInfo的行为.

将本地机器设置为“(UTC)协调世界时间”,然后运行以下代码得到“UTC”：

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(TimeZoneInfo.Local.Id);
            Console.ReadLine();
        }
    }
}

远程进入我们的一个Azure实例并运行相同的应用程序产生以下结果：

“世界时间协调”

根据 .NET documentation ,这是StandardName属性应该返回的值,而不是Id属性.我们将此值传递给TimeZoneInfo.FindSystemTimeZoneById(),并且它失败,因为“协调通用时间”不是有效的Id(“UTC”).此时区是StandardName属性与Id属性不匹配的3之一.

在3月7日之前,Azure实例总是返回正确的“UTC”值.我们暂时硬编码为“UTC”作为一个停顿的解决方案.

有人有什么想法为什么会这样改变,处理这种情况的适当长期解决办法是什么？

目前,Windows Azure中的时区是太平洋标准时间(PST).他们已经迁移到协调世界时(UTC).这可能是依赖当地时间的应用程序的突破性变化.

我们为什么要这样做呢？

Windows Azure是一项全球性服务.为了确保应用程序的行为方式相同,无论其物理位置如何,重要的是Windows Azure在所有地理位置都具有一致的时区. UTC是全球客户群的自然选择,UTC不受夏令时(以及相关风险的错误).

对您有什么潜在影响？

如果您在Windows Azure中运行的应用程序依赖于本地时间,则会受到向UTC迁移的影响.以下是潜在问题的几个例子：

如果使用本地时间戳,事件日志中可能会发生间隙.

依赖本地时间戳的用户界面可能会显示不同的结果.

您的应用程序存储的本地时间戳可能会在切换后被不同的解释.

许多应用程序已经被设计为仅依赖于UTC时间.这些应用程序应该不受影响.

如果您希望他们将其更改,或者您有任何其他问题,可以在以下博客链接中与他们联系：

Windows Azure blog