Настройте параметр «Летнее время» (DST) в .NET, как в Windows

Question

Я пытаюсь реплицировать настройки даты и времени Windows в приложении UWP, и у меня не получается работать с настройками летнего времени (DST).

Мне удалось заставить все работатьЯ могу просто изменить системное время и часовой пояс из своего приложения, но опция Автоматическая настройка перехода на летнее время сбивает меня с толку.

Сначала я подумал, что этого достаточно, чтобы проверить TimeZoneInfo.SupportsDaylightSavingTime, затем я обнаружил, что мне, вероятно, также нужно проверить, находится ли текущая выбранная дата / время в диапазоне летнего времени, выполнив TimeZoneInfo.IsDaylightSavingTime.

Ну, я подумал, что все правильно, но после тестирования,моя собственная опция «Настроить DST» не совпадает с настройкой Windows, и, поскольку я не вижу исходный код Windows, я понятия не имею, какие другие условия они проверяют, чтобы отключить / включить его.

Мое приложение UWP:

Настройки Windows:

AmЯ все еще что-то здесь упускаю?Мой другой вопрос по этому поводу может быть найден здесь для тех, кто заинтересован.

Может быть, некоторые разработчики MS с инсайдерской информацией могут подсказать мне логику этого тумблера: -)

Заранее спасибо!

ОБНОВЛЕНИЕ:

Результаты из tzutil показывают, что когда дата 16 мая 2011 года и часовой пояс - Москва (UTC + 3), отключение DST с помощью команды tzutil /s "Russian Standard Time_dstoff" просто возвращает «Русское стандартное время» без _dstoff, потому что DST неприменимо, и это соответствует тому, что сообщает Windows.

Но тогда почемуКласс TimeZoneInfo .NET говорит это? Пробовал также с:

var currentDateTime = new DateTime(2011, 5, 16, 0, 0, 0, DateTimeKind.Local);
var isDst = TimeZoneInfo.Local.IsDaylightSavingTime(currentDateTime); //True

Итак, .NET говорит, что текущая дата находится в диапазоне DST, но DST нельзя отключить ни с помощью TZUTIL, ни из настроек Windows?

Может быть, я упускаю что-то очень очевидное здесь, но я не вижу этого ...

ОБНОВЛЕНИЕ:

Изменение месяца на февраль, поворотыОтрегулировать включение DST в Windows, из-за правил настройки?Но в Хельсинки у нас тоже есть эти переходы, и тумблер не отключен?Чем отличается?

ОБНОВЛЕНИЕ:

Решили не делать ничего из этого, а просто отметьте TimeZoneInfo.SupportsDaylightSavingTime.Это не стоит никому ни времени, ни энергии, чтобы делать это точно так же, как Windows.

Answer 1

Несколько вещей для ответа на ваши вопросы:

• Не используйте класс System.TimeZone вообще - никогда.У него много проблем, и есть лучшие альтернативы.Для большей части кода .NET используйте System.TimeZoneInfo.Поскольку вы сказали, что пишете приложение UWP, вы также можете воспользоваться классами Windows.Globalization.Calendar и Windows.Globalization.DateTimeFormatting.DateTimeFormatter.Открытые исходные библиотеки, такие как Noda Time также могут быть хорошим выбором.

  В первом показанном вами блоке кода вы используете System.TimeZone.IsDaylightSavingTime.Примечания в документации объясняют результаты, которые вы видите:

  "Поскольку класс TimeZone поддерживает одно правило корректировки на летнее время, метод IsDaylightSavingTime(DateTime) применяет текущее правило корректировки к любой датенезависимо от того, действовало ли правило корректировки на эту дату. При условии, что сама операционная система имеет точные исторические данные о летнем времени, более точный результат доступен с помощью метода TimeZoneInfo.IsDaylightSavingTime. По возможности, используйте TimeZoneInfo.IsDaylightSavingTimemethod. "

• Во втором блоке кода, который вы показали, вы правильно используете System.TimeZoneInfo.IsDaylightSavingTime и получаете True, когда ожидаете False.Хотя это сбивает с толку и, возможно, неправильно, это объяснимо:

  • В 2011 году Москва начала календарный год с UTC + 3.Затем он изменил свое смещение на UTC + 4 27 марта в 2:00 утра ( ссылка здесь ).Это было изменение стандартного времени , а не изменение, связанное с DST.
  • Структуры данных в Windows (TIME_ZONE_INFORMATION, DYNAMIC_TIME_ZONE_INFORMATION и, более конкретно, REG_TZI_FORMAT) делаютне поддерживает изменение стандартного смещения в середине календарного года.Они были спроектированы без такого рода изменений - очень давно.
  • Чтобы учесть изменения по местному времени, в Windows это моделируется как изменение летнего времени, гдеПериод летнего времени начинается 27 марта в 2 часа ночи и продолжается до самого конца года.Это обеспечивает точное местное время в течение перехода за счет возврата неточной информации от API, которые утверждают или делают вывод, что их результаты явно связаны с DST (например, System.TimeZoneInfo.IsDaylightSavingTime).
  • Таким образом, подумайте о такихметоды, указывающие на то, что местное время периода находится в большем смещении от UTC, чем в какой-либо другой точке года.Это может быть связано с DST, или это может быть связано с изменением стандартного времени.

• Насколько я могу судить, Windows действительно смотрит на эти данные, чтобы определить, показывать опцию или нет.Если в текущем календарном году есть переход (который определяется системными часами), будет представлена ​​опция - независимо от того, был ли этот переход связан с летним временем или по какой-либо другой причине.

Кроме того, некоторые общие советы:

• Большинство приложений должны не пытаться изменить системное время, часовой поясили настройки DST.Хотя на самом деле есть способы сделать это, это может иметь серьезные последствия.Это общесистемные глобальные настройки, которые будут влиять на все на компьютере - не только на ваше приложение.

  В частности, слишком резкое изменение time может повлиять наумение правильно аутентифицироваться с другими системами.Например, проверка подлинности Windows (Active Directory, SSPI и т. Д.) Использует Kerberos, который имеет 5-минутное отклонение от UTC.Кроме того, доступ к веб-сайтам, использующим сертификаты безопасности (HTTPS, SSL, TLS и т. Д.), Может завершиться ошибкой, если срок действия сертификата истек или еще не был выдан, в соответствии с системными часами.Таким образом, самый безопасный путь к успеху - это установить время автоматически и не позволять пользователю отклоняться.

  Хотя изменение часового пояса и / или настроек летнего времени не влияет на аутентификацию, это все еще глобальная настройка.В любом месте на машине, работающей по местному времени, будет использоваться этот параметр, а не только ваше приложение.

• Если вы действительно собираетесь менять часовой пояс, имейте в виду, что вам может потребоваться очистить кэш локального часового пояса, чтобы использовать новые настройки в вашем приложении. См. Этот вопрос и ответ для получения более подробной информации .

• Если вы намеревались просто изменить часовой пояс для своего приложения, то просто следите за TimeZoneInfo.Idвыбранного часового пояса и примените его с помощью TimeZoneInfo.ConvertTime и связанных с ним методов, где это необходимо.

• Вы, вероятно, не должны иметь настройку для отключения автоматической настройки летнего времени,Существование этого параметра, существующего в Windows вообще, является устаревшим артефактом от первоначальной реализации настроек часового пояса с ранних времен WinNT и Win9x.Большинству пользователей следует оставлять его включенным.

  В настоящее время его отключение имеет только один законный вариант использования, когда правительство объявляет об изменении часового пояса с часового пояса на летнее время без такового.или имеет «постоянный DST») и нет другой существующей записи часового пояса, которая имеет такое же базовое смещение без DST и , когдаУказанное правительство не предоставляет Microsoft достаточно времени для создания и распространения новой записи о часовом поясе для затронутого региона до того, как изменения вступят в силу.Такие вещи случаются, но встречаются редко.ИМХО, было бы разумно, чтобы этот параметр исчез в какой-то момент в будущем.(Только мое личное мнение, не говоря об этом Microsoft).