Pull to refresh

Comments 33

Как же в этих ваших windows'ах всё сложно…
Более того, вы узнали о том, как можно оградить пользователей от изменения часовых поясов и самостоятельно автоматически изменить часовые пояса на всех компьютерах компании, невзирая на версию операционной системы.

Семейства Windows наверное…
Да, само собой, забыл об этом упомянуть. Спасибо, добавил :)
А как это реализуется в других OS?
Во FreeBSD (к примеру) можно собрать-поставить порт misc/zoneinfo — именно так многие обновляют таймзоны на старых, неподдерживаемых более системах типа 4.x (патчить порты приходится вручную, но в данном случае это несложно).
<sarcasm>Ну-да, ну-да.</sarcasm>

Сами-то пробовали на woody, sarge, или, хотя бы, на etch'е?

А ведь все три системы поновее Windows XP будут.
wget -O - http://www.iana.org/time-zones/repository/releases/tzdata2014h.tar.gz | tar xzvf - && zic europe && ln -svf /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Использовать с осторожностью, поскольку на реальной системе не проверял. src
Наша бюрократия хорошо ложится на «бюрократию» Windows, судя по статье получается дикий коктейль, а в обычные дни админам просто скучно.
В принципе, могу выложить куда-то сам reg-файлик и добавить к посту ссылку, если это нужно…
Для Windows XP было бы здОрово. Спасибо.
Добавил ссылку на reg-файл в качестве небольшого обновления к посту.
++
для Win XP было бы очень кстати
UFO landed and left these words here
В Кемеровской области забавно получилось с этим изменением времени. Общий перевод стрелок на час совпадает с перемещением в другой часовой пояс и эти изменения компенсируют друг-друга. Единственная проблема в том, что 26-го числа нужно будет принудительно перевести пользовательские системы в другой пояс, иначе появится разница в час.
С виндой более-менее разобрались, а как быть с приложениями? Может быть кто-то составил список известных проблем?
Коллеги мучаются с Java и производными от неё, Microsoft заявил, что Exchange 2007 пару недель будет показывать неправильно время, так как патч выйдет только в ноябре, наверняка есть что-то ещё.
На XP можно заменить таймзону в лоб:
1. Качаем обновления для POSReady и сохраняем в обущую папку.
2. Устанавливием их через батник такого содержания:
reg add HKLM\SYSTEM\WPA\PosReady /v Installed /t REG_DWORD /d 1 /f
KB2998527.exe /quiet
reg delete HKLM\SYSTEM\WPA\PosReady /f
tzchange /c "Russian Standard Time"

Можно измегнить конечную таймзону и добавить проверок при необходимости, но ошибок при повторном запуске не возникает. Разворачивается любым удобным способом.
UFO landed and left these words here
btw, ;),
закон об истечении времени был последним, принятым Госдумой из запретных законов, после чего время у всех истекло и наступила вечность.
Так они как раз и успели внести изменения :)
Про Windows это уже 2 или 3 статья за несколько дней. А что делать владельцу андроидных аппаратов? Ну и что с iOS, особенно 6-й версии?
Переключиться на подходящую таймзону, перевод отменили, так что достаточно сделать это один раз.
У меня iOS 6 показывает автоматически определённый пояс «Самара».
Возможно, ничего переводить не будет. Через 50 минут увижу )
Спасибо! Очень круто и своевременно!

Меня только мучает один вопрос.

Если не менять описания TZ и не импортировать приведенные ключики реестра, а просто валюнтаристически поменять TZ. Ну, например, в Москве поменять TZ на Калининград. После перехода «на зимнее» время вы получим верное время на машине. Т.к. «дозимнепереходный Калиниград» это как раз «послепереходная» Москва — GMT+3.

Но.

Если теперь создать запись в календаре Microsoft Outlook и посмотреть на нее «через» любую пропатченную ОС, например через Windows8, то мы увидим, что запись в календаре смещена на час.

Откуда берется это смещение? Ведь и непропатченный допереходный Калининград — это GMT+3 и пропатченная послепереходная Москва — GMT+3?

Впрочем, отвечать на вопрос не обязательно. Главное, что предложенный автором патч для реестра WinXP решает эту проблему.
Потому что время в записях хранится в UTC, а при отображении форматируется в соответствии с текущей временной зоной. Соответственно, если отображаемое время на непропатченной машине отображается верным, значит UTC время на ней стоит неверное.
Ну если вы уж, спустя столько времени, начали отвечать то сказав «А» скажите уж и «Б». Если «валюнтаристически поменять TZ» не на Калининград (в котором зона также поменялась), а на Минск (в котором ничего не происходило), то всё будет работать отлично и на патченной и на непатченной системе. Как, собственно все и делают на всяких китайских андроидах.
Вы, вот, примеров накидали, а анализа не провели. Если проанализировать ветки "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones" и "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" в WinXP+SP2 (летнее/зимнее время), WinXP+SP3 (летнее время; GMT+3), а также первую (второй у меня нет) от патча КВ2998527 (зимнее время; GMT+4), то картина становится яснее. Изложу на примере пояса Москвы.

В SP2:
"TZI"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,\
00,00,0a,00,00,00,05,00,03,00,00,00,00,00,00,00,\
00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00
"Bias"=dword:ffffff4c
"StandardName"="Московское время (зима)"
"StandardBias"=dword:00000000
"StandardStart"=hex:00,00,0a,00,05,00,03,00,00,00,00,00,00,00,00,00
"DaylightName"="Московское время (лето)"
"DaylightBias"=dword:ffffffc4
"DaylightStart"=hex:00,00,03,00,05,00,02,00,00,00,00,00,00,00,00,00
"ActiveTimeBias"=dword:ffffff4c


В SP3:
"TZI"=hex:10,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"Bias"=dword:ffffff10
"StandardName"="Московское время (зима)"
"StandardBias"=dword:00000000
"StandardStart"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"DaylightName"="Московское время (зима)"
"DaylightBias"=dword:00000000
"DaylightStart"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"ActiveTimeBias"=dword:ffffff10


В КВ2998527
"TZI"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,\
00,00,0a,00,00,00,05,00,02,00,00,00,00,00,00,00,\
00,00,01,00,03,00,01,00,00,00,00,00,00,00,00,00


Становится понятно, что последние 16+16 байт TZI повторяют StandardStart и DaylightStart. Также видна закономерная связь первого байта TZI с последним в Bias и ActiveTimeBias.
Прошу прощения, промахнулся в кнопочках отправки и просмотра сообщения :(
Ещё наблюдение: Если в TZI занулить все байты, после 12-ого, что в настройках времени пропадет галочка автоматической смены летнего/зимнего времени.
Вывод. Так как у нас теперь только зимнее время, то надо: 1) в TZI от КВ2998527 занулить последние 32 байта; 2) положить нулями StandardBias, StandardStart, DaylightBias, DaylightStart (очевидно, описывают даты перевода часов) как в SP3; 3) Bias и ActiveTimeBias приравнять к ffffff4c. То есть, будет так:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Russian Standard Time]
"TZI"=hex:4c,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"Bias"=dword:ffffff4c
"StandardName"="Московское время (зима)"
"StandardBias"=dword:00000000
"StandardStart"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"DaylightName"="Московское время (зима)"
"DaylightBias"=dword:00000000
"DaylightStart"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"ActiveTimeBias"=dword:ffffff4c
"DisableAutoDaylightTimeSet"=dword:00000001
«Ещё наблюдение:»


В действительности алочка автоматической смены летнего/зимнего времени пропадает, когда в реестре задано
«DisableAutoDaylightTimeSet»=dword:00000001

(у Вас задано)
Only those users with full accounts are able to leave comments. Log in, please.