Пользователь
0,0
рейтинг
22 декабря 2014 в 17:55

О переводе времени 2 / Не забываем пропатчить XP и 2003, иначе будет сюрприз в ночь с 6 на 7 января

Извините за подъем несколько некрофильской темы, когда все обсуждают Windows 10. Если вы по каким-то причинам ещё используете системы десятилетней давности и до сих пор не обновили Windows 2003/XP, возможно, это пост позволит вам сэкономить время и нервы в новогодние каникулы.

Итак, вышло декабрьское обновление таймзон kb3013410. Если его (или эквивалентные изменения реестра) не установить на 2003/XP с установленным kb2998527, они и дальше продолжат переводить время. Причина — неполная поддержка Dynamic DST, значения в реестре есть, но для действий по переводу времени времени они не используются. Грубо говоря, переводить стрелки в каждый год по-разному научилась только Vista и выше (ядро 6.0). Конкретно в 2015 году, если ничего не предпринимать, 2003/XP с установленным kb2998527 переведут стрелки на летнее время (+1 час) в ночь с 6 на 7 января, и на зимнее (-1 час) 25 октября.

Чтобы этого не произошло, есть простой способ — заранее снять галку перевода времени (она опять появилась после установки kb2998527), и правильный способ — установить kb3013410 (или эквивалентные ему изменения реестра). На домашнем компьютере никаких дополнительных действий не надо, сервера я бы советовал перезапустить, т.к., как выяснилось 26 октября, некоторые приложения, а так-же службы (например, IIS в Exchange) не понимают изменения таймзон до рестарта службы.

На Windows Vista/Server 2008 и выше устанавливать kb3013410 прямо сейчас или до конца года не обязательно, они и так никуда не перейдут.

Файлы реестра для XP тут, если кому надо.

Теоретическое обоснование:

Windows 2003/XP и более ранние версии операционных систем Windows не поддерживают технологию Dynamic DST для собственно процедуры смены времени, хотя соответствующие значения реестра там есть (см. msdn.microsoft.com/ru-ru/library… 85).aspx Minimum supported — Windows Vista / Windows Server 2008). Это означает, что они технически не способны переводить стрелки часов по–разному в разные года. Патчем kb2998527 для России установлены следующие времена соответственно начала и конца летнего времени:
начало — 00 часов первой среды января
конец — 02 часа последнего воскресенья октября

Именно так было сделано, поскольку имеющиеся механизмы DST не позволяют сделать однократный автоматический переход по-другому (я пробовал). Таким образом, в 2015 году и далее, если не предпринять мер, Windows 2003/XP переведет стрелки часов на час вперед в первую среду января (в 2015 это ночь с 6 на 7 января) и в последнее воскресенье октября (в 2015 это 25 октября).

Чтобы перевод стрелок в Windows 2003/XP не произошел, необходимо установить обновление kb3013410 (или эквивалентную правку реестра для XP), или, в крайнем случае, снять галку «( ) Автоматический переход на летнее время и обратно». Однако, для предотвращения проблем в случае ещё одного изменения в законодательстве, я бы не рекомендовал снимать эту галку.

Ещё раз повторюсь, ОС с ядром от 6.0, т.е. 2008/Vista, полноценно поддерживают Dynamic DST и не будут никуда переходить в 2015 и последующих годах. Однако в записи о времени перехода в старом формате, хранящиеся в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\, такие как на скриншоте ниже, будут внесены изменения. В связи с этим возможны проблемы в ПО, которое читает и использует эти значения напрямую для исчисления времени. В подразделы \Dynamic DST, определяющие перевод времени в новом формате, для России никаких изменений не вносится.

Ссылки на Майкрософт:
1) support.microsoft.com/kb/2998527/ru обновление, которое мы устанавливали в октябре 2014, секция «Список известных проблем»
(…)
Неверные параметры летнего времени для будущих лет на Windows Server 2003 и Windows XP Embedded

Если пользователи устанавливать это обновление на Windows Server 2003 или Windows XP Embedded, их системы будет продолжать использовать параметры летнего времени для 2014 даже после изменения календарного года. Это может привести к неправильному отображению времени системы.

Для решения этой проблемы пользователям следует установить накопительное Update(scheduled to be released in December, 2014) декабря до изменений календарного года. При установке обновления русский часовой пояс и декабря накопительных обновлений, их системы применить правильные параметры летнего времени и продолжает отображать правильное время в конце 2014 г.

2) support.microsoft.com/kb/3013410/ru то самое декабрьское обновление, о котором сегодня идет речь. Оно заменяет kb2981580 и все выпущенные до него, в т.ч. kb2998527. Такие обновления выходят регулярно (особенно в конце года, подготавливают систему к изменениям в законодательстве различных стран, изменяющим способ перевода стрелок в следующем году), и, как правило, являются кумулятивными, т.е. заменяют предыдущие обоновления.

Про Windows XP в MSKB ничего не сказано, т.к. она снята с поддержки с 8 апреля 2014 года.

UPD Коллеги, не забывайте, что после внесения изменений в реестр на XP для их применения надо перевыбрать таймзону руками или командой control.exe timedate.cpl,,/Z Russian Standard Time (с указанием вашего часового пояса), при этом информация о текущей таймзоне из HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones переписывается в HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation.
Vladimir Bazanov @bazanovv
карма
14,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (27)

  • +5
    Я наверное отстал от жизни и пропустил чего-то важное, но откуда это вообще взялось? На мой обывательский взгляд никогда в России не переводили стрелки в начале января… почему такие странные даты у Майкрософта?
    • +2
      Это особенность реализации предыдущего перехода, 26 октября, в Windows. Механизм DST там рассчитан на два перевода стрелок в год — на летнее время и обратно. А в 2014 году мы переходили только один раз! Для этого пришлось при создании kb2981580 пойти на некий финт ушами — в нем задним числом включили летнее время 1 января, а выключили 26 октября (из-за этого были глюки с отображением данных за 1 января в некоторых SCADA-системах). Причем механизм DST заточен не на конкретные числа, а на день и номер недели — именно поэтому переход в 2015 году на системах xp/2003 с kb2998527 произойдет в такое странное время (первая среда января 2015 это как раз 7 число). Звучит как бред, согласен, но посмотрите на скриншоты из Tzedit — возможно будет понятнее.

      После kb2981580, начинаем летнее время 1 января (точнее в первую среду года), заканчиваем 26 октября (в последнее воскресенье октября).
      image

      После kb3013410, ничего не трогаем
      image
      • 0
        Вот тут есть более подробное теоретическое описание поведения .NET и просто Windows xp/2003 с Dynamic DST.
      • 0
        Простите, а мы разве переходили на летнее/зимнее время в 2014 году? ИМХО мы просто часовые пояса сменили. И именно такой патч логично было выпустить Майкрософту.
        • 0
          Windows не имеет штатного автоматического механизма смены часовых поясов, совсем. Альтернатива — или используем то, что есть — механизм летнего времени, слегка его подпилив (что и было сделано), или как-то автоматизируем смену часового пояса на всех компьютерах, что означает ручной перевод времени, задание в планировщике и прочие подобные способы восхода солнца вручную. Второй способ возможно более правилен идеологически (хотя и при нем могли бы остаться например старые и новые таймзоны — а зачем это надо?), но первый в Майкрософт, видимо, посчитали более удобным для пользователей и администраторов. Ну не зря же они Dynamic DST выдумывали?
          • 0
            Так часовые пояса хранятся же где-то? Или в реестре или в какой-то DLL. Что мешало просто заменить старую информацию на новую? А системное время все равно останется неизменным — все эти часовые пояса, локальное время и переход на летнее время должны использоваться по идее только для отображения.
            • 0
              Хранятся, отдельно база часовых поясов в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
              отдельно текущая активная конфигурация в HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. В .dll хранятся названия в Unicode, и то только начиная с Vista/2008.

              Если мы просто меняем информацию в хранилище таймзон — не происходит ничего. Если меняем информацию в текущей конфигурации — происходит перевод стрелок в соответствии с этой информацией. А нам надо, чтобы он произошел не в момент установки обновления, а в ночь 26 октября (ну или позже, если компьютер был выключен). И для этого есть готовый механизм — зачем же разрабатывать ещё один?

              Я не спорю, что по идее оно должно бы быть в UTC всё, но есть ровно то, что есть.
  • 0
    У вас ссылка не живая на готовый файл реестра. Он тот же самый что и тут? Или отличается чем-то?
    • 0
      Перевыложил, ссылку поправил, извините. Файлы другие, в этом и есть суть поста.
      В прошлый раз MS потребовал удаления файла самособранных руками таймзон, выложенного на Яндекс-диск, через DMCA — в этот раз хотел положить на что-то более абьюзоустойчивое, но, видимо, выбрал неправильно.
      • 0
        Я не видел, что за обменник был изначально, но mega.co.nz весьма подходит на звание абузоустойчивого. Ну или magnet, точно не удалят.
        • 0
          Вот сюда выкладывал, оно молча пропало. Но может в спешке что не так сделал. Спасибо, вот на mega.co.nz.

          На самом деле поддержка Яндекса повела себя более чем достойно в этом вопросе, и всячески помогала в борьбе со злобными роботами MS, просто не хочу их больше подставлять.
  • +2
    Для XP обновление берётся тут и ставится через хак с ключем HKLM\SYSTEM\WPA\PosReady.
  • 0
    Если я верно понял. Данный пост актуален для тех кто при помощи бубна поставил kb2998527 от xp embeded на xp? Т.е. участь ставить kb3013410 обходит стороной, тех кто просто выгрузил нужные ветки реестров, как расписано здесь.
    • +1
      Увы, нет — всё, что делает обновление kb2998527, это прописывает именно эти и именно такие ветки реестра, как по ссылке (на Vista/2008+ ещё правит названия таймзон внутри .dll). Можете сами скачать tzedit и посмотреть, или отключить сеть и перевести часы на 23:59:50 6 января 2015 г. и посмотреть на результат. Так что или ещё раз править реестр, или снимать галку перехода на летнее время. Сам сначала думал, что всё нормально будет — но проверка показала обратное.
      • 0
        Благодарю! Пойду тестировать на XP, а после радовать товарищей кто не читает GT.
      • 0
        На не обновляемой XP SP3 всё нормально. Нигде час не переводился
        • 0
          Да, так и должно быть — до kb2998527 даты перевода времени стандартные, а если вы используете необновленную систему — наверняка у вас или галка «Автоматический переход на летнее время и обратно» снята, или часовой пояс не-российский, или и то и то сразу.
  • +1
    В связи с этим возможны проблемы в ПО, которое читает и использует эти значения напрямую для исчисления времени.

    Ага. для MS Exchange 2010 например. Постановка встречи из 2014го года на время после 7го января 2015го приводит к тому, что в помощнике по планированию встреча сдвигается на час вперёд.
    • 0
      Опа, про такие проблемы в Exchange даже не знал, спасибо! Пробовали рестартануть IIS на CAS после kb3013410 и проверять ещё раз?
      • +1
        В январе всё чудесным образом исправится само.
        • 0
          Ещё один глюк на Exchange 2010 выловили — на наших CASах, которые опубликованы в интернет, стоял патч kb3013410 (с перезагрузкой после установки). На некоторых CASах в Филиалах, использующих наш CAS в качестве шлюза/прокси — нет. Ровно в 1 час ночи 7 января для всех пользователей этих CASов Филиалов перестал работать ActiveSync, OWA при этом работал как обычно. Помогла установка kb3013410 и рестарт IIS на CASах Филиалов. Что именно там сломалось и где использовалось поясное время — без понятия, до этого, в т.ч. 26 октября, подобных проблем не было.

          Ещё был глюк с технологическим ПО — на SQL 2008R2 некорректно отрабатывали stored procedures, завязанные на время. Деталей не знаю, помогла опять-же установка патча и перезагрузка.
  • +1
    Видел такое решение для Windows XP — просто убирается галочка перехода на летнее время, сам еще не пробовал
    reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v DisableAutoDaylightTimeSet /t REG_DWORD /d 1
    
    • +1
      Да, это сработает.
  • +1
    После установки этого фикса на Win2k3 x64 и при попытке открытии окна «Дата и время» в журнале «Система появляются ошибки c кодом 32:
    Зависимая сборка Microsoft.Windows.Common-Controls не может быть найдена, последняя ошибка Указанная сборка не установлена в системе.

    и две с кодом 59
    Resolve Partial Assembly завершилась не удачно для Microsoft.Windows.Common-Controls. Соответствующее сообщение об ошибке: Указанная сборка не установлена в системе.

    Generate Activation Context завершилась не удачно для C:\WINDOWS\system32\timedate.cpl. Соответствующее сообщение об ошибке: Указанная сборка не установлена в системе.

    На сайте МС есть информация по этой проблеме, но решения для русской версии я не нашел. support.microsoft.com/kb/841082/en-us
  • +1
    Есть еще два варианта решения проблемы.
    Первый — снимаем галочку о переходе на зимнее(летнее) время.
    Второй — запускаем tzchange /w 2015 чем насильно переходим на использование DST на 2015 год.
    • 0
      Про первый в посте уже и написано, как простой, но неправильный; на второй есть ссылка на блог Олега Ржевского в комментариях, там-же подробнее описан механизм работы .NET и просто Windows xp/2003 с Dynamic DST, но т.к. я сам не проверял и не в курсе особенностей — писать не стал.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.