Question

从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”作为权宜之计解决方案。

有没有人知道为什么会改变这种方式，以及处理这种情况的适当长期解决方案是什么？

Answer 1

目前，Windows Azure中的时区是太平洋标准时间（PST）。他们已迁移到协调世界时（UTC）。对于依赖当地时间的应用程序而言，这可能是一个重大变化。

我们为什么这样做？

Windows Azure是一项全球服务。为确保应用程序的行为方式与其物理位置无关，因此Windows Azure在所有地理位置都具有一致的时区非常重要。鉴于全球客户群，UTC是一种自然选择，UTC不受夏令时（以及相关的漏洞风险）的影响。

对您有什么潜在影响？

如果在Windows Azure中运行的应用程序依赖于本地时间，则会受到迁移到UTC的影响。以下是一些潜在问题的例子：

如果使用本地时间戳，事件日志中可能会出现间隙。依赖于本地时间戳的用户界面可能会显示不同的结果。转换后，应用程序存储的本地时间戳可能会有不同的解释。许多应用程序已经设计为仅依赖于UTC时间。这些应用程序应该不受影响。

如果您希望他们更改回来或者您有任何其他问题，可以通过以下博客链接与他们联系::

Windows Azure blog

Azure现在为TimeZoneInfo.Local.Id而不是“UTC”返回“协调世界时”的无效值？为什么？

1 个答案: