Ещё один глюк на Exchange 2010 выловили — на наших CASах, которые опубликованы в интернет, стоял патч kb3013410 (с перезагрузкой после установки). На некоторых CASах в Филиалах, использующих наш CAS в качестве шлюза/прокси — нет. Ровно в 1 час ночи 7 января для всех пользователей этих CASов Филиалов перестал работать ActiveSync, OWA при этом работал как обычно. Помогла установка kb3013410 и рестарт IIS на CASах Филиалов. Что именно там сломалось и где использовалось поясное время — без понятия, до этого, в т.ч. 26 октября, подобных проблем не было.
Ещё был глюк с технологическим ПО — на SQL 2008R2 некорректно отрабатывали stored procedures, завязанные на время. Деталей не знаю, помогла опять-же установка патча и перезагрузка.
Про первый в посте уже и написано, как простой, но неправильный; на второй есть ссылка на блог Олега Ржевского в комментариях, там-же подробнее описан механизм работы .NET и просто Windows xp/2003 с Dynamic DST, но т.к. я сам не проверял и не в курсе особенностей — писать не стал.
Хранятся, отдельно база часовых поясов в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
отдельно текущая активная конфигурация в HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. В .dll хранятся названия в Unicode, и то только начиная с Vista/2008.
Если мы просто меняем информацию в хранилище таймзон — не происходит ничего. Если меняем информацию в текущей конфигурации — происходит перевод стрелок в соответствии с этой информацией. А нам надо, чтобы он произошел не в момент установки обновления, а в ночь 26 октября (ну или позже, если компьютер был выключен). И для этого есть готовый механизм — зачем же разрабатывать ещё один?
Я не спорю, что по идее оно должно бы быть в UTC всё, но есть ровно то, что есть.
Windows не имеет штатного автоматического механизма смены часовых поясов, совсем. Альтернатива — или используем то, что есть — механизм летнего времени, слегка его подпилив (что и было сделано), или как-то автоматизируем смену часового пояса на всех компьютерах, что означает ручной перевод времени, задание в планировщике и прочие подобные способы восхода солнца вручную. Второй способ возможно более правилен идеологически (хотя и при нем могли бы остаться например старые и новые таймзоны — а зачем это надо?), но первый в Майкрософт, видимо, посчитали более удобным для пользователей и администраторов. Ну не зря же они Dynamic DST выдумывали?
Да, так и должно быть — до kb2998527 даты перевода времени стандартные, а если вы используете необновленную систему — наверняка у вас или галка «Автоматический переход на летнее время и обратно» снята, или часовой пояс не-российский, или и то и то сразу.
Увы, нет — всё, что делает обновление kb2998527, это прописывает именно эти и именно такие ветки реестра, как по ссылке (на Vista/2008+ ещё правит названия таймзон внутри .dll). Можете сами скачать tzedit и посмотреть, или отключить сеть и перевести часы на 23:59:50 6 января 2015 г. и посмотреть на результат. Так что или ещё раз править реестр, или снимать галку перехода на летнее время. Сам сначала думал, что всё нормально будет — но проверка показала обратное.
Вот сюда выкладывал, оно молча пропало. Но может в спешке что не так сделал. Спасибо, вот на mega.co.nz.
На самом деле поддержка Яндекса повела себя более чем достойно в этом вопросе, и всячески помогала в борьбе со злобными роботами MS, просто не хочу их больше подставлять.
Это особенность реализации предыдущего перехода, 26 октября, в Windows. Механизм DST там рассчитан на два перевода стрелок в год — на летнее время и обратно. А в 2014 году мы переходили только один раз! Для этого пришлось при создании kb2981580 пойти на некий финт ушами — в нем задним числом включили летнее время 1 января, а выключили 26 октября (из-за этого были глюки с отображением данных за 1 января в некоторых SCADA-системах). Причем механизм DST заточен не на конкретные числа, а на день и номер недели — именно поэтому переход в 2015 году на системах xp/2003 с kb2998527 произойдет в такое странное время (первая среда января 2015 это как раз 7 число). Звучит как бред, согласен, но посмотрите на скриншоты из Tzedit — возможно будет понятнее.
После kb2981580, начинаем летнее время 1 января (точнее в первую среду года), заканчиваем 26 октября (в последнее воскресенье октября).
Перевыложил, ссылку поправил, извините. Файлы другие, в этом и есть суть поста. В прошлый раз MS потребовал удаления файла самособранных руками таймзон, выложенного на Яндекс-диск, через DMCA — в этот раз хотел положить на что-то более абьюзоустойчивое, но, видимо, выбрал неправильно.
Если кому ещё актуально — вышло декабрьское обновление таймзон kb3013410. Если его (или эквивалентные изменения реестра) не установить на 2003/XP, они и дальше продолжат переводить время. Причина — неполная поддержка Dynamic DST, значения в реестре есть, но для действий по переводу времени времени они не используются. Грубо говоря, переводить стрелки в каждый год по–разному научилась только Vista и выше (ядро 6.0). Конкретно в 2015 году, если ничего не предпринимать, 2003/XP с установленным kb2998527 переведут стрелки на летнее время (+1 час) в ночь с 5 на 6 января, и на зимнее (–1 час) 25 октября.
Чтобы этого не произошло, есть простой способ — до 31 декабря с.г. снять галку перевода времени (она опять появилась после установки kb2998527), и правильный способ — установить kb3013410 (или эквивалентные ему изменения реестра). На домашнем компьютере никаких дополнительных действий не надо, сервера я бы советовал перезапустить, т.к., как выяснилось 26 октября, некоторые приложения, а так–же службы (например, IIS в Exchange) не понимают изменения таймзон до рестарта службы.
На Windows Vista/Server 2008 и выше устанавливать kb3013410 прямо сейчас или до конца года не обязательно, они и так никуда не перейдут.
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 это ночь с 5 на 6 января) и в последнее воскресенье октября (в 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 тут ничего не сказано, т.к. она снята с поддержки с 8 апреля 2014 года.
1) ДО 26 числа ставим патч (и перевыбираем ту-же таймзону руками для xp/2003);
2) 26 числа, а также 31 декабря и далее всё нормально, никто ничего не трогает, до следующих решений партии и правительства. Исключение — те регионы, где меняется и таймзона (+0 или -2), там по решению МС меняем её руками в ночь на 26, либо ставим сделанные вручную таймзоны, которые поменяют автоматом, а потом переходим на стандартные МС.
Не надо никакого декабрьского патча с отменой, ну посмотрите же наконец на Dynamic DST (в редакторе правой на таймзону — Dynamic DST). Оно именно для того и придумано, чтобы включать и выключать перевод стрелок в нужный год.
2014
2015
Файлик с таймзонами на Яндекс-диске засаспендили по DMCA требованию Майкрософт, сейчас переписываемся. Если вдруг кому ещё надо, гуглится по Russian_tz_2014.zip.
Ещё был глюк с технологическим ПО — на SQL 2008R2 некорректно отрабатывали stored procedures, завязанные на время. Деталей не знаю, помогла опять-же установка патча и перезагрузка.
отдельно текущая активная конфигурация в HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation. В .dll хранятся названия в Unicode, и то только начиная с Vista/2008.
Если мы просто меняем информацию в хранилище таймзон — не происходит ничего. Если меняем информацию в текущей конфигурации — происходит перевод стрелок в соответствии с этой информацией. А нам надо, чтобы он произошел не в момент установки обновления, а в ночь 26 октября (ну или позже, если компьютер был выключен). И для этого есть готовый механизм — зачем же разрабатывать ещё один?
Я не спорю, что по идее оно должно бы быть в UTC всё, но есть ровно то, что есть.
На самом деле поддержка Яндекса повела себя более чем достойно в этом вопросе, и всячески помогала в борьбе со злобными роботами MS, просто не хочу их больше подставлять.
После kb2981580, начинаем летнее время 1 января (точнее в первую среду года), заканчиваем 26 октября (в последнее воскресенье октября).
После kb3013410, ничего не трогаем
В прошлый раз MS потребовал удаления файла самособранных руками таймзон, выложенного на Яндекс-диск, через DMCA — в этот раз хотел положить на что-то более абьюзоустойчивое, но, видимо, выбрал неправильно.
Чтобы этого не произошло, есть простой способ — до 31 декабря с.г. снять галку перевода времени (она опять появилась после установки kb2998527), и правильный способ — установить kb3013410 (или эквивалентные ему изменения реестра). На домашнем компьютере никаких дополнительных действий не надо, сервера я бы советовал перезапустить, т.к., как выяснилось 26 октября, некоторые приложения, а так–же службы (например, IIS в Exchange) не понимают изменения таймзон до рестарта службы.
На Windows Vista/Server 2008 и выше устанавливать kb3013410 прямо сейчас или до конца года не обязательно, они и так никуда не перейдут.
Файлы реестра для XP тут filetea.me/t1saFWx8b3bTr6EzxCVuJ1eWg, если кому надо.
Теоретическое обоснование:
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 это ночь с 5 на 6 января) и в последнее воскресенье октября (в 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 тут ничего не сказано, т.к. она снята с поддержки с 8 апреля 2014 года.
2) 26 числа, а также 31 декабря и далее всё нормально, никто ничего не трогает, до следующих решений партии и правительства. Исключение — те регионы, где меняется и таймзона (+0 или -2), там по решению МС меняем её руками в ночь на 26, либо ставим сделанные вручную таймзоны, которые поменяют автоматом, а потом переходим на стандартные МС.
2014
2015