bazanovv Dec 22 2014 at 14:55

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

4 min

39K

Development for Windows*

+19

Comments 27

NeoCode Dec 22 2014 at 16:01

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

bazanovv Dec 22 2014 at 19:44

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

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

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

bazanovv Dec 23 2014 at 06:38

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

NeoCode Dec 23 2014 at 16:16

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

bazanovv Dec 23 2014 at 16:31

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

NeoCode Dec 24 2014 at 06:30

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

bazanovv Dec 24 2014 at 07:45

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

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

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

bazanovv Dec 24 2014 at 07:51

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

UksusoFF Dec 22 2014 at 18:53

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

bazanovv Dec 22 2014 at 19:24

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

Vilgelm Dec 22 2014 at 20:01

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

bazanovv Dec 22 2014 at 20:16

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

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

navion Dec 23 2014 at 01:15

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

neskey Dec 23 2014 at 06:18

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

bazanovv Dec 23 2014 at 06:33

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

neskey Dec 23 2014 at 09:34

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

dok2d Dec 23 2014 at 12:01

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

bazanovv Dec 23 2014 at 12:18

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

Anastasia_K Dec 23 2014 at 06:25

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

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

bazanovv Dec 23 2014 at 06:35

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

The_Kf Dec 23 2014 at 12:20

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

bazanovv Jan 12 2015 at 06:53

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

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

eloki Dec 23 2014 at 07:40

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

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

bazanovv Dec 23 2014 at 07:42

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

yosemity Dec 23 2014 at 08:33

После установки этого фикса на 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 Dec 24 2014 at 20:49

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

bazanovv Dec 25 2014 at 08:25

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