15

从 3 月 7 日开始，东南亚地区的 Azure 服务器似乎应用了一个补丁，该补丁改变了 TimeZoneInfo 在 .NET 中的行为。

将我的本地机器设置为“（UTC）协调世界时”，然后运行以下代码会产生“UTC”：

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

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

“协调世界时”

根据.NET 文档，这是应该由 StandardName 属性返回的值，而不是 Id 属性。我们将此值传递给 TimeZoneInfo.FindSystemTimeZoneById()，但它失败了，因为“协调世界时”不是有效的 Id（“UTC”是）。这个时区是仅有的 3 个 StandardName 属性与 Id 属性不匹配的时区之一。

在 3 月 7 日之前，Azure 实例始终返回正确的“UTC”值。我们暂时将“UTC”硬编码为权宜之计。

有谁知道为什么会变成这种方式，以及处理这种情况的正确长期解决方案是什么？

4

1 回答 1

1

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

我们为什么这样做呢？

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

对您有什么潜在影响？

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

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

如果您希望他们将其改回或者如果您有任何其他问题，您可以在以下博客链接上与他们讨论::

Windows Azure 博客

于 2013-04-04T13:34:19.360 回答