Теперь Azure возвращает недопустимое значение "Скоординированное универсальное время" для TimeZoneInfo.Local.Id вместо "UTC"? Зачем?

С 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(), и он терпит неудачу, поскольку "Скоординированное универсальное время" не является допустимым идентификатором ( "UTC" is). Этот часовой пояс является одним из 3, свойство StandardName которого не соответствует свойству Id.

До 7 марта экземпляры Azure всегда возвращали правильное значение "UTC" . У нас есть жестко запрограммированный "UTC" в настоящее время как временное решение.

Есть ли у кого-нибудь идеи, почему это изменилось таким образом, и каково надлежащее долгосрочное решение для решения этой ситуации?

Ответы

Ответ 1

В настоящее время часовой пояс в Windows Azure - это стандартное тихоокеанское время (PST). Они мигрировали в Скоординированное всеобщее время (UTC). Это потенциально может быть нарушением изменений для приложений, которые полагаются на местное время.

Зачем мы это делаем?

Windows Azure - глобальная услуга. Чтобы гарантировать, что приложения ведут себя одинаково независимо от их физического местоположения, важно, чтобы Windows Azure располагала согласованным часовым поясом во всех географических регионах. UTC является естественным выбором, учитывая глобальную клиентскую базу, а UTC не подлежит летнему времени (и связанным с этим рискам ошибок).

Что может повлиять на вас?

Если ваше приложение, работающее в Windows Azure, зависит от локального времени, на него повлияет переход на UTC. Вот несколько примеров потенциальных проблем:

В журналах событий могут возникать пробелы, если используются локальные временные метки. Пользовательские интерфейсы, зависящие от локальных временных меток, могут показывать разные результаты. Локальные метки времени, хранящиеся в вашем приложении, могут быть интерпретированы по-разному после перехода. Многие приложения уже разработаны, чтобы полагаться только на время UTC. Эти приложения не должны быть затронуты.

Если вы хотите, чтобы они изменили его или у вас возникли какие-либо другие проблемы, вы можете обсудить их с помощью следующей ссылки в блоге:

Блог Windows Azure