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

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文档,这是StandardName属性应返回的值,而不是Id属性.我们将此值传递给TimeZoneInfo.FindSystemTimeZoneById(),并且由于"Coordinated Universal Time"不是有效的Id("UTC"),它会失败.此时区是其中StandardName属性与Id属性不匹配的3个时区之一.

在3月7日之前,Azure实例始终返回正确的值"UTC".我们暂时硬编码"UTC"作为权宜之计解决方案.

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

Answer 1

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

\n\n

我们为什么要这样做呢？

\n\n

Windows Azure 是一项全球服务。为了确保应用程序无论其物理位置如何都以相同的方式运行，Windows Azure 在所有地理位置上拥有一致的时区非常重要。考虑到全球客户群，UTC 是一个自然的选择，并且 UTC 不受夏令时（以及相关的错误风险）的影响。

\n\n

对您有什么潜在影响？

\n\n

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

\n\n

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

\n\n

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

\n\n

Windows Azure 博客

\n