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

[NeoCode]

Я наверное отстал от жизни и пропустил чего-то важное, но откуда это вообще взялось? На мой обывательский взгляд никогда в России не переводили стрелки в начале января… почему такие странные даты у Майкрософта?

[bazanovv]

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

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


После kb3013410, ничего не трогаем

[bazanovv]

Вот тут есть более подробное теоретическое описание поведения .NET и просто Windows xp/2003 с Dynamic DST.

[NeoCode]

Простите, а мы разве переходили на летнее/зимнее время в 2014 году? ИМХО мы просто часовые пояса сменили. И именно такой патч логично было выпустить Майкрософту.

[bazanovv]

Windows не имеет штатного автоматического механизма смены часовых поясов, совсем. Альтернатива — или используем то, что есть — механизм летнего времени, слегка его подпилив (что и было сделано), или как-то автоматизируем смену часового пояса на всех компьютерах, что означает ручной перевод времени, задание в планировщике и прочие подобные способы восхода солнца вручную. Второй способ возможно более правилен идеологически (хотя и при нем могли бы остаться например старые и новые таймзоны — а зачем это надо?), но первый в Майкрософт, видимо, посчитали более удобным для пользователей и администраторов. Ну не зря же они Dynamic DST выдумывали?

[NeoCode]

Так часовые пояса хранятся же где-то? Или в реестре или в какой-то DLL. Что мешало просто заменить старую информацию на новую? А системное время все равно останется неизменным — все эти часовые пояса, локальное время и переход на летнее время должны использоваться по идее только для отображения.

[bazanovv]

Хранятся, отдельно база часовых поясов в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
отдельно текущая активная конфигурация в HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. В .dll хранятся названия в Unicode, и то только начиная с Vista/2008.

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

Я не спорю, что по идее оно должно бы быть в UTC всё, но есть ровно то, что есть.

[bazanovv]

Забыл сразу приложить известный ролик, без него пост будет неполон.

[UksusoFF]

У вас ссылка не живая на готовый файл реестра. Он тот же самый что и тут? Или отличается чем-то?

[bazanovv]

Перевыложил, ссылку поправил, извините. Файлы другие, в этом и есть суть поста.
_{В прошлый раз MS потребовал удаления файла самособранных руками таймзон, выложенного на Яндекс-диск, через DMCA — в этот раз хотел положить на что-то более абьюзоустойчивое, но, видимо, выбрал неправильно.}

[Vilgelm]

Я не видел, что за обменник был изначально, но mega.co.nz весьма подходит на звание абузоустойчивого. Ну или magnet, точно не удалят.

[bazanovv]

Вот сюда выкладывал, оно молча пропало. Но может в спешке что не так сделал. Спасибо, вот на mega.co.nz.

_{На самом деле поддержка Яндекса повела себя более чем достойно в этом вопросе, и всячески помогала в борьбе со злобными роботами MS, просто не хочу их больше подставлять.}

[navion]

Для XP обновление берётся тут и ставится через хак с ключем HKLM\SYSTEM\WPA\PosReady.

[neskey]

Если я верно понял. Данный пост актуален для тех кто при помощи бубна поставил kb2998527 от xp embeded на xp? Т.е. участь ставить kb3013410 обходит стороной, тех кто просто выгрузил нужные ветки реестров, как расписано здесь.

[bazanovv]

Увы, нет — всё, что делает обновление kb2998527, это прописывает именно эти и именно такие ветки реестра, как по ссылке (на Vista/2008+ ещё правит названия таймзон внутри .dll). Можете сами скачать tzedit и посмотреть, или отключить сеть и перевести часы на 23:59:50 6 января 2015 г. и посмотреть на результат. Так что или ещё раз править реестр, или снимать галку перехода на летнее время. _{Сам сначала думал, что всё нормально будет — но проверка показала обратное.}

[neskey]

Благодарю! Пойду тестировать на XP, а после радовать товарищей кто не читает GT.

[dok2d]

На не обновляемой XP SP3 всё нормально. Нигде час не переводился

[bazanovv]

Да, так и должно быть — до kb2998527 даты перевода времени стандартные, а если вы используете необновленную систему — наверняка у вас или галка «Автоматический переход на летнее время и обратно» снята, или часовой пояс не-российский, или и то и то сразу.

[Anastasia_K]

В связи с этим возможны проблемы в ПО, которое читает и использует эти значения напрямую для исчисления времени.

Ага. для MS Exchange 2010 например. Постановка встречи из 2014го года на время после 7го января 2015го приводит к тому, что в помощнике по планированию встреча сдвигается на час вперёд.

[bazanovv]

Опа, про такие проблемы в Exchange даже не знал, спасибо! Пробовали рестартануть IIS на CAS после kb3013410 и проверять ещё раз?

[The_Kf]

В январе всё чудесным образом исправится само.

[bazanovv]

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

Ещё был глюк с технологическим ПО — на SQL 2008R2 некорректно отрабатывали stored procedures, завязанные на время. Деталей не знаю, помогла опять-же установка патча и перезагрузка.

[eloki]

Видел такое решение для Windows XP — просто убирается галочка перехода на летнее время, сам еще не пробовал

reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v DisableAutoDaylightTimeSet /t REG_DWORD /d 1

[bazanovv]

Да, это сработает.

[yosemity]

После установки этого фикса на 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

[AbnormalHead]

Есть еще два варианта решения проблемы.
Первый — снимаем галочку о переходе на зимнее(летнее) время.
Второй — запускаем tzchange /w 2015 чем насильно переходим на использование DST на 2015 год.

[bazanovv]

Про первый в посте уже и написано, как простой, но неправильный; на второй есть ссылка на блог Олега Ржевского в комментариях, там-же подробнее описан механизм работы .NET и просто Windows xp/2003 с Dynamic DST, но т.к. я сам не проверял и не в курсе особенностей — писать не стал.