Если вы ещё не в курсе, то сообщаю вам, что сокращение числа часовых поясов на территории России вот-вот начнётся. В пяти регионах присоединение к соседнему часовому поясу уже запланировано на ближайшее воскресенье, 28 марта. До этого события осталось меньше недели!
Телевизор я не смотрю, возможно, там этот вопрос подробно обсуждается уже давно, но лично для меня эта информация в начале этой недели стала новостью.
До недавнего времени я был уверен, что идея с сокращением числа часовых поясов в России до 5 штук — это просто чьё-то неудачное предложение или очередной бредовый законопроект, который обязательно будет отвергнут и далее обсуждений не пройдёт. Однако, оказывается, все решения на этот счёт «у них там наверху» уже приняты и соответствующие постановления Правительства уже подписаны (В.Путиным) и опубликованы.
Постановление по Кемеровской области было подписано ещё осенью 2009 года, а постановления по Самарской области, Удмуртии, Камчатке и Чукотке были подписаны буквально на днях.
![Time Zone changes](https://habrastorage.org/getpro/habr/post_images/65d/dcf/fc7/65ddcffc7a59b46a2c33a55792ed2984.gif)
Далее рассмотрим когда и как именно будет происходить этот переход, кого это коснётся, чего от этого ждать и как к этому готовиться с точки зрения администрирования IT-инфраструктуры.
Изменения часового пояса коснутся сразу пяти субъектов РФ:
1. Самарская область.
2. Удмуртская Республика.
3. Кемеровская область.
4. Камчатский край.
5. Чукотский автономный округ.
Чтобы эта смена часвого пояса прошла максимально мягко и беспроблемно, её решили совместить с моментом перехода на летнее время. Т.е. если во всех остальных регионах России 28 марта 2010 года (в воскресенье) в 02:00 по местному времени стрелки часов переведут на час вперёд (на 03:00 по метному времени), то в указанных пяти регионах в 2010 году часы переводиться на летнее время не будут, таким образом в 02:00 по метному времени эти регионы автоматически без перевода часов перейдут в летнее время соседнего часового пояса. Ну а дальнейшие переводы часов в этих регионах будут осуществляться в соответствии с тем часовым поясом, в который они перейдут.
После этого перехода 28 марта 2010 года в России перестанут существовать два часовых пояса: Самарское время и Камчатское время.
Теперь нам больше не услышать привычное многим с детства: «В Москве 15 часов, в Петропавловске-Камчатском полночь», полночь на камчатке теперь будет в 16:00 по Москве.
Но это всё лирика. В действительности я сейчас хотел обсудить здесь не саму эту новость и не целесообразность таких изменений в целом. Я хотел рассмотреть в первую очередь то, как это изменение часовых поясов коснётся IT-инфраструктуры, т.е. к чему готовиться айтишникам и в первую очередь системным администраторам предприятий в свете грядущих событий.
Например, у нашей организации есть филиалы в четырёх из этих пяти регионов (кроме Чукотки), соответственно IT-инфраструктура присутствует во всех наших филиалах. Если у вашей компании тоже есть IT-инфраструктура в этих регионах, которую вы администрируете, то вам тоже стоит заранее озаботиться этим вопросом.
Для начала нужно чётко осознать, что при этой смене часовых поясов, так же как и при переходе на летнее/зимнее время, меняется только представление локального времени, а именно сдвиг локального времени относительно универсального UTC. Само же абсолютное универсальное время (UTC) для данных регионов и их IT-инфраструктуры не меняется и не прыгает, оно продолжает идти всё так же равномерно и непрерывно, без разрывов и скачков.
Поэтому паниковать тут точно не стоит, глобальных проблем и временных скачков этот переход никому не создаст.
На многих unix-серверах, которые живут по UTC и локальное время вообще ни для чего не используют, эта смена часовых поясов вообще пройдёт незамеченной.
Однако, если в каких-то приложениях, сервисах и интерфейсах есть привязка к часовому поясу и используется локальное время, то здесь для корректировки потребуются системные изменения. Например, нужно сделать, чтобы системные часы на десктопах всех пользователей показывали им правильное локальное время. Если какое-то приложение пишет логи в локальном времени, то здесь опять же нужно корректное отображение локального времени. Ну и все прочие интерфейсы, использующие локальное время должны его правильно отобразить.
Свои заморочки из-за этой смены часовых поясов могут быть и у разработчиков. Например, в правилах обработчика на каком-то форуме/блоге может быть прописано: «если в профиле пользователя указано расположение [Самарская область] или [Удмуртская республика], то отображать все сообщения для него в его локальном времени UTC+4 (летом UTC+5)» и так для каждого региона. В этом случае шаблон правил обработчика локального времени с 28 марта придётся корректировать.
Можно придумать и другие случаи, когда в приложениях и иных проектах может быть привязка к локальному времени.
Ещё раз советую всем внимательно взглянуть на свою IT-инфраструктуру и свои проекты, нет ли там завязки на часовые пояса или локальное время упомянутых пяти регионов. И если есть, то стоит уже принимать какие-то решения и тестировать изменения, если они потребуются.
Все приложения/сервисы, которые работают с локальным временем в рамках локальной ОС, обычно завязаны именно на системное локальное время. Поэтому для десктопного/серверного парка (в частности Windows-машин) нужно будет скорректировать их локальное время.
Само значение времени, разумеется, трогать на машинах не нужно (время же не меняется в глобальном смысле). Нужно на всех машинах соответствующего региона изменить только часовой пояс (TimeZone), и тут есть два варианта:
Вариант 1.
Оставить на всех машинах прежний установленный часовой пояс, но в параметрах самого выбранного часового пояса изменить его относительный сдвиг относительно UTC. Т.е., например, для Камчатского времени вместо UTC+12 (летом: UTC+13) указать сдвиг UTC+11 (летом: UTC+12), как у Магаданского времени.
Отредактировать параметры системных тайм-зон в Windows можно с помощью утилиты TZedit.exe или напрямую внесением изменений в системный реестр, в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\…
Вариант 2.
Не изменять системные параметры часовых поясов, а просто выбрать в качестве текущего часового пояса часовой пояс соседнего региона (того, к чьему часовому поясу присоединились).
Оба варианта рабочие, но идеологически верно будет не создавать дублирующийся часовой пояс с такими же параметрами, как у соседнего, а просто выбрать уже существующий соседний часовой пояс (т.е. Вариант 2). Тем более и в формулировке постановлений Правительства указано, что регион переходит в соседний часовой пояс, а не изменяет параметры своего часового пояса.
Выбирать текущую тайм-зону в Windows можно, конечно, и вручную через окно редактирования системных Даты/Времени, по двойному клику на системных часиках в трее. Но нам нужно это дело автоматизировать, т.к. эти изменения придётся сделать на десятках Windows-серверов и сотнях рабочих станций. Как вариант для смены таймзоны можно будет воспользоваться такими командами:
Установка московского часового пояса (для Самары и Ижевска):
Установка омского/новосибирского часового пояса (для Кемерово):
Установка магаданского часового пояса (для Камчатки и Чукотки):
P.S. Для большей точности можно в этой командной конструкции перед control.exe и перед timedate.cpl дописать путь %SystemRoot%\system32\, но не обязательно, т.к. этот путь по умолчанию входит в системную переменную среды %PATH%.
UPD:
Важная особенность: для того, чтобы в Windows можно было переключать часовой пояс, нужно быть администратором системы (ну или запускать от Local System). Если пользователь не администратор, но ему в политиках безопасности системы (secpol.msc \ Local Policies \ User Rights Assignment) дано право Change the system time («Изменение системного времени»), то даже в этом случае он не может выбирать часовой пояс. Т.е. дату и время он с этими правами изменить может, а вот всего лишь выбрать другой часовой пояс уже не может. Никак не может, ни через команды, ни через GUI, причём система в этом случае даже не ругается на отсутствие доступа, а просто молча игнорирет попытки смены часового пояса и всё. Вот такая она Винда нелогичная.
Также не забываем, что по умолчанию в Windows для Магаданского часового пояса не включен переход на летнее время. Поэтому в Чукотке и Камчатке кроме переключения часового пояса на Магаданский ещё придётся вносить изменения в сам системный магаданский пояс, чтобы добавить в него переход на летнее время и обратно. Поэтому в скрипт для Камчатки/Чукотки кроме указанной выше конструкции добавляем правку в реестре Магаданской таймзоны.
Наш скрипт Kamch-TZ-change.cmd:
И рядом с файлом Kamch-TZ-change.cmd кладём файл Magadan_daylight.reg:
(не забываем про обязательную пустую строку в конце reg-файла)
Поскольку у нас развёрнута инфраструктура AD, то для рабочих станций эту команду можно поместить в cmd/bat-скрипт, а потом установить этот скрипт в качестве startup/shutdown-скриптов в групповой политике. Групповую политику активировать ближе к концу рабочего дня 26 марта (пятница).
Для серверов startup/shutdown-скрипты не подойдут, т.к. серверы на выходные не выключаются, поэтому на серверах эту команду придётся запускать удалённо, например, через psexec по заранее составленному текстовому списку Windows-серверов.
Думаю, в оставшиеся пару дней потестируем на нескольких рабочих станциях и серверах, а в ближайшую пятницу назначим групповую политику с этой командой в скрипте на все рабочие станции. По крайней мере у меня на этот счёт планы именно такие.
А что по этому поводу думаете вы, коллеги?
Телевизор я не смотрю, возможно, там этот вопрос подробно обсуждается уже давно, но лично для меня эта информация в начале этой недели стала новостью.
До недавнего времени я был уверен, что идея с сокращением числа часовых поясов в России до 5 штук — это просто чьё-то неудачное предложение или очередной бредовый законопроект, который обязательно будет отвергнут и далее обсуждений не пройдёт. Однако, оказывается, все решения на этот счёт «у них там наверху» уже приняты и соответствующие постановления Правительства уже подписаны (В.Путиным) и опубликованы.
Постановление по Кемеровской области было подписано ещё осенью 2009 года, а постановления по Самарской области, Удмуртии, Камчатке и Чукотке были подписаны буквально на днях.
![Time Zone changes](https://habrastorage.org/getpro/habr/post_images/65d/dcf/fc7/65ddcffc7a59b46a2c33a55792ed2984.gif)
Далее рассмотрим когда и как именно будет происходить этот переход, кого это коснётся, чего от этого ждать и как к этому готовиться с точки зрения администрирования IT-инфраструктуры.
* Ссылки на текст постановлений:
- Постановление Правительства Российской Федерации от 14 сентября 2009 г. N 740 г. Москва «О применении на территории Кемеровской области времени пятого часового пояса»
- Постановление Правительства Российской Федерации от 17 марта 2010 г. N 166 г. Москва «О применении на территории Удмуртской Республики времени второго часового пояса»
- Постановление Правительства Российской Федерации от 19 марта 2010 г. N 170 г. Москва «О применении на территории Самарской области времени второго часового пояса»
- Постановление Правительства Российской Федерации от 19 марта 2010 г. N 171 г. Москва «О применении на территории Камчатского края и Чукотского автономного округа времени десятого часового пояса»
* Где и когда?
Изменения часового пояса коснутся сразу пяти субъектов РФ:
1. Самарская область.
2. Удмуртская Республика.
3. Кемеровская область.
4. Камчатский край.
5. Чукотский автономный округ.
Чтобы эта смена часвого пояса прошла максимально мягко и беспроблемно, её решили совместить с моментом перехода на летнее время. Т.е. если во всех остальных регионах России 28 марта 2010 года (в воскресенье) в 02:00 по местному времени стрелки часов переведут на час вперёд (на 03:00 по метному времени), то в указанных пяти регионах в 2010 году часы переводиться на летнее время не будут, таким образом в 02:00 по метному времени эти регионы автоматически без перевода часов перейдут в летнее время соседнего часового пояса. Ну а дальнейшие переводы часов в этих регионах будут осуществляться в соответствии с тем часовым поясом, в который они перейдут.
После этого перехода 28 марта 2010 года в России перестанут существовать два часовых пояса: Самарское время и Камчатское время.
Теперь нам больше не услышать привычное многим с детства: «В Москве 15 часов, в Петропавловске-Камчатском полночь», полночь на камчатке теперь будет в 16:00 по Москве.
Но это всё лирика. В действительности я сейчас хотел обсудить здесь не саму эту новость и не целесообразность таких изменений в целом. Я хотел рассмотреть в первую очередь то, как это изменение часовых поясов коснётся IT-инфраструктуры, т.е. к чему готовиться айтишникам и в первую очередь системным администраторам предприятий в свете грядущих событий.
Например, у нашей организации есть филиалы в четырёх из этих пяти регионов (кроме Чукотки), соответственно IT-инфраструктура присутствует во всех наших филиалах. Если у вашей компании тоже есть IT-инфраструктура в этих регионах, которую вы администрируете, то вам тоже стоит заранее озаботиться этим вопросом.
* Что произойдёт со временем?
Для начала нужно чётко осознать, что при этой смене часовых поясов, так же как и при переходе на летнее/зимнее время, меняется только представление локального времени, а именно сдвиг локального времени относительно универсального UTC. Само же абсолютное универсальное время (UTC) для данных регионов и их IT-инфраструктуры не меняется и не прыгает, оно продолжает идти всё так же равномерно и непрерывно, без разрывов и скачков.
Поэтому паниковать тут точно не стоит, глобальных проблем и временных скачков этот переход никому не создаст.
На многих unix-серверах, которые живут по UTC и локальное время вообще ни для чего не используют, эта смена часовых поясов вообще пройдёт незамеченной.
Однако, если в каких-то приложениях, сервисах и интерфейсах есть привязка к часовому поясу и используется локальное время, то здесь для корректировки потребуются системные изменения. Например, нужно сделать, чтобы системные часы на десктопах всех пользователей показывали им правильное локальное время. Если какое-то приложение пишет логи в локальном времени, то здесь опять же нужно корректное отображение локального времени. Ну и все прочие интерфейсы, использующие локальное время должны его правильно отобразить.
Свои заморочки из-за этой смены часовых поясов могут быть и у разработчиков. Например, в правилах обработчика на каком-то форуме/блоге может быть прописано: «если в профиле пользователя указано расположение [Самарская область] или [Удмуртская республика], то отображать все сообщения для него в его локальном времени UTC+4 (летом UTC+5)» и так для каждого региона. В этом случае шаблон правил обработчика локального времени с 28 марта придётся корректировать.
Можно придумать и другие случаи, когда в приложениях и иных проектах может быть привязка к локальному времени.
Ещё раз советую всем внимательно взглянуть на свою IT-инфраструктуру и свои проекты, нет ли там завязки на часовые пояса или локальное время упомянутых пяти регионов. И если есть, то стоит уже принимать какие-то решения и тестировать изменения, если они потребуются.
* Какие изменения в системе потребуются?
Все приложения/сервисы, которые работают с локальным временем в рамках локальной ОС, обычно завязаны именно на системное локальное время. Поэтому для десктопного/серверного парка (в частности Windows-машин) нужно будет скорректировать их локальное время.
Само значение времени, разумеется, трогать на машинах не нужно (время же не меняется в глобальном смысле). Нужно на всех машинах соответствующего региона изменить только часовой пояс (TimeZone), и тут есть два варианта:
Вариант 1.
Оставить на всех машинах прежний установленный часовой пояс, но в параметрах самого выбранного часового пояса изменить его относительный сдвиг относительно UTC. Т.е., например, для Камчатского времени вместо UTC+12 (летом: UTC+13) указать сдвиг UTC+11 (летом: UTC+12), как у Магаданского времени.
Отредактировать параметры системных тайм-зон в Windows можно с помощью утилиты TZedit.exe или напрямую внесением изменений в системный реестр, в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\…
Вариант 2.
Не изменять системные параметры часовых поясов, а просто выбрать в качестве текущего часового пояса часовой пояс соседнего региона (того, к чьему часовому поясу присоединились).
Оба варианта рабочие, но идеологически верно будет не создавать дублирующийся часовой пояс с такими же параметрами, как у соседнего, а просто выбрать уже существующий соседний часовой пояс (т.е. Вариант 2). Тем более и в формулировке постановлений Правительства указано, что регион переходит в соседний часовой пояс, а не изменяет параметры своего часового пояса.
* Как выбрать другой часовой пояс в Windows?
Выбирать текущую тайм-зону в Windows можно, конечно, и вручную через окно редактирования системных Даты/Времени, по двойному клику на системных часиках в трее. Но нам нужно это дело автоматизировать, т.к. эти изменения придётся сделать на десятках Windows-серверов и сотнях рабочих станций. Как вариант для смены таймзоны можно будет воспользоваться такими командами:
Установка московского часового пояса (для Самары и Ижевска):
control.exe timedate.cpl,,/z Russian Standard Time
Установка омского/новосибирского часового пояса (для Кемерово):
control.exe timedate.cpl,,/z N. Central Asia Standard Time
Установка магаданского часового пояса (для Камчатки и Чукотки):
control.exe timedate.cpl,,/z Central Pacific Standard Time
P.S. Для большей точности можно в этой командной конструкции перед control.exe и перед timedate.cpl дописать путь %SystemRoot%\system32\, но не обязательно, т.к. этот путь по умолчанию входит в системную переменную среды %PATH%.
UPD:
Важная особенность: для того, чтобы в Windows можно было переключать часовой пояс, нужно быть администратором системы (ну или запускать от Local System). Если пользователь не администратор, но ему в политиках безопасности системы (secpol.msc \ Local Policies \ User Rights Assignment) дано право Change the system time («Изменение системного времени»), то даже в этом случае он не может выбирать часовой пояс. Т.е. дату и время он с этими правами изменить может, а вот всего лишь выбрать другой часовой пояс уже не может. Никак не может, ни через команды, ни через GUI, причём система в этом случае даже не ругается на отсутствие доступа, а просто молча игнорирет попытки смены часового пояса и всё. Вот такая она Винда нелогичная.
Также не забываем, что по умолчанию в Windows для Магаданского часового пояса не включен переход на летнее время. Поэтому в Чукотке и Камчатке кроме переключения часового пояса на Магаданский ещё придётся вносить изменения в сам системный магаданский пояс, чтобы добавить в него переход на летнее время и обратно. Поэтому в скрипт для Камчатки/Чукотки кроме указанной выше конструкции добавляем правку в реестре Магаданской таймзоны.
Наш скрипт Kamch-TZ-change.cmd:
@echo off
echo Add Daylight time to Magadan Time Zone ...
regedit.exe /s %~dp0Magadan_daylight.reg
echo OK
echo.
echo Change current Time Zone to Magadan Time Zone (Moscow +8) ...
control.exe timedate.cpl,,/z Central Pacific Standard Time
echo OK
И рядом с файлом Kamch-TZ-change.cmd кладём файл Magadan_daylight.reg:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Pacific Standard Time]
"TZI"=hex:6c,fd,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
(не забываем про обязательную пустую строку в конце reg-файла)
Поскольку у нас развёрнута инфраструктура AD, то для рабочих станций эту команду можно поместить в cmd/bat-скрипт, а потом установить этот скрипт в качестве startup/shutdown-скриптов в групповой политике. Групповую политику активировать ближе к концу рабочего дня 26 марта (пятница).
Для серверов startup/shutdown-скрипты не подойдут, т.к. серверы на выходные не выключаются, поэтому на серверах эту команду придётся запускать удалённо, например, через psexec по заранее составленному текстовому списку Windows-серверов.
Думаю, в оставшиеся пару дней потестируем на нескольких рабочих станциях и серверах, а в ближайшую пятницу назначим групповую политику с этой командой в скрипте на все рабочие станции. По крайней мере у меня на этот счёт планы именно такие.
А что по этому поводу думаете вы, коллеги?