Как вы, наверняка, уже слышали, осенью 2011 сразу несколько государств приняли решение об изменении порядка исчисления времени на своей территории, а также об отмене сезонного перехода на летнее время.
В списке этих государств: Россия, Белоруссия, Украина, частично признанные государства: Абхазия и Южная Осетия, а также непризнанное государство Приднестровье. Т.е. во всех часовых поясах этих стран теперь круглый год будет фиксированный сдвиг относительно UTC, без дополнительных сезонных сдвигов.
(Примечание: Украина сначала приняла решение о переходе на время UTC+3 без летнего времени, но потом отменила принятое ранее решение и пока вернулась к прежнему порядку исчисления времени с сезонными переводами часов. Подробности ниже.)
В этой статье я опишу суть принятых изменений часовых поясов и опишу техническую сторону вопроса касательно IT-систем (корпоративной инфраструктуры, серверов, рабочих станций, сервисов, приложений и т.п.). Постараюсь ответить на ряд основных вопросов, возникающих в связи с этими изменениями:
— Какие IT-системы может затронуть изменение часовых поясов?
— Какие проблемы это может вызвать?
— Как подготовиться к этому, чтобы по возможности избежать проблем?
Полагаю, многим системным/прикладным администраторам, а также некоторым разработчикам приложений/сервисов, полезно будет ознакомиться с этим материалом. А потом предлагаю всем заинтересованным обсудить и дополнить эту информацию в комментариях.
Так «летнее» или «зимнее» время отменили?
Законодательные основы для изменения исчисления времени
Какое время будет в новых часовых поясах?
Список часовых зон России
Состав территорий РФ, образующих часовые зоны РФ
Часовые пояса Украины и Белоруссии
А что с летним временем в других странах?
Целесообразность использования летнего времени
Какие могут быть проблемы из-за изменения часовых зон?
Что делать?
А что, если у нас точное времени синхронизируется с NTP или GPS?
Обновление информации о часовых поясах (TZI, Time Zone Information) в различных ОС
Unix-системы и unix-подобные ОС
Сетевое оборудование Cisco
Мобильные ОС
MS Windows
Обновление устаревших Windows-систем
Особенности перенастройки часовых зон в Windows для разных регионов
Чукотка, Камчатка
Магадан
Сахалинская область и Якутия
Самара, Ижевск (Удмуртия)
Калининград
Белоруссия
Обновление часовых зон на контроллерах домена MS Active Diectory
Обновление часовых зон на MS Exchange-серверах
Обновление часовых зон на MS Sharepoint-серверах
Когда нужно обновить информацию о часовых зонах в ОС и ПО?
Некоторые журналисты в новостных заметках трактовали эти изменения часовых зон в России и Белоруссии как «отмену зимнего времени». С обывательской точки зрения всё именно так и выглядит, т.к. переход на летнее время весной в этих странах был, а обратного перехода не будет. Поэтому кажется, что время теперь всегда «летнее», а «зимнего» времени больше не будет.
Но формально никакого «зимнего времени» просто не существует. Существует стандартное время, плюс в некоторых странах принят сезонный переход на летнее время (DST, Daylight saving time), когда в летний период (обычно с конца марта по конец октября) к стандартному местному времени добавляется ещё один час.
Так вот теперь во всех часовых поясах России и Белоруссии происходят два события:
1) К стандартному времени на постоянной основе прибавляется ещё один час.
2) Отменяются сезонные переводы часов (т.е. отменяется переход на летнее время и обратно).
Таким образом, в ночь с 29 на 30 октября 2011, когда почти все европейские страны будут переводить часы на один час назад, чтобы вернуть своё локальное время с летнего на стандартное, в России и Белоруссии перевод часов уже осуществляться не будет, т.к. новое принятое время как раз совпадает с ранее действовавшим летним временем на этих территориях. Ну и в дальнейшем в этих странах часы на летнее время и обратно уже переводиться не будут (до тех пор, пока данные решения не будут законодательно отменены).
В России данные изменения введены* Постановлением Правительства РФ от 31 августа 2011 г. №725 «О составе территорий, образующих каждую часовую зону, и порядке исчисления времени в часовых зонах, а также о признании утратившими силу отдельных постановлений Правительства Российской Федерации» (опубликовано и вступило в силу 6 сентября 2011).
В Белоруссии данные изменения введены постановлением Совета министров Республики Беларусь от 15 сентября 2011 г. №1229 «Об исчислении времени на территории Республики Беларусь» (PDF).
На Украине:
20 сентября 2011 г. — Верховная Рада Украины приняла Постановление №3755-VI «Об изменении порядка исчисления времени на территории Украины» [DOC] (подписано Председателем Верховной Рады Украины 29 сентября 2011). Это постановление устанавливало на территории всей Украины время UTC+3 и отмену сезонных переводов часов, т.е. сохранение времени UTC+3 весь год.
18 октября 2011 г. — Верховная Рада Украины приняла новое Постановление №3914-VI «О признании утратившим силу Постановления Верховной Рады Украины 'Об изменении порядка исчисления времени на территории Украины'» [DOC] (подписано Председателем Верховной Рады Украины 19 октября 2011), которое признаёт предыдущее принятое 20.09.2011 и уже вступившее в силу Постановление Верховной Рады №3755-VI утратившим силу. Соответственно после вступления в силу этого Постановления ВР №3914-VI на Украине вернулся прежний порядок исчисления локального времени: стандартное время (зимой) UTC+2 и летнее время UTC+3.
После 30 октября 2011 г., когда Украина вернётся с летнего времени (UTC+3) на своё стандартное время (UTC+2), Кабинет Министров Украины должен направить на рассмотрение в Верховную Раду Украины законопроект, который отменит для Украины сезонные переводы часов на летнее время. Если это постановление будет принято, то Украина в конце марта 2012 уже не будет переходить на летнее время, и на всей территории Украины круглый год будет фиксированное время UTC+2 (без DST).
В Армении, судя по сообщениям в прессе, проект закона об отмене сезонных переходов на летнее время и обратно готовится, но ещё законодательно не принят парламентом (Национальным Собранием) Армении. Уже точно известно, что 30 октября 2011 года Армения преводит часы на час назад с летнего времени (UTC+5) на стандартное время (UTC+4). Но ожидается, что до марта 2012 г. закон, отменяющий сезонные переводы часов в Армении, будет окончательно утверждён и вступит в силу. Если это произойдёт, то Армения в конце марта 2012 уже не будет переходить на летнее время, и там круглый год будет фиксированное время UTC+4 (без DST).
Ссылок на официальные законодательные акты Абхазии и Южной Осетии, устанавливающие изменение часовых зон в 2011 году, у меня нет. Насколько мне известно, таких документов вообще не существует. Просто в этих странах во время провозглашения независимости установлено соответствие местного времени Московскому (из политических соображений). Соответственно из-за изменения в 2011 году Московского времени и отказа от перехода на летнее время в России, в Абхазии и Южной Осетии также меняется время по аналогии с Москвой. Таким образом, теперь в Абхазии и Южной Осетии местное время будет совпадать с местным временем во всей Грузии (UTC+4) не только летом, а вообще круглогодично.
В Приднестровской Молдавской Республике данные изменения введены Указом Президента ПМР от 10 октября 2011 г. №770 «Об отмене перехода на сезонное время на территории Приднестровской Молдавской Республики» (вступает в силу с 18 октября 2011 г.). Причём вся остальная Молдавия не изменяет порядок исчисления времени на своей территории, поэтому 30 октября 2011 Молдавия перейдёт обратно на своё стандартное (зимнее) время.
*Примечание: в некоторых статьях в интернете на тему изменения часовых зон в России в 2011 году ошибочно указывается, что новый порядок исчисления времени в часовых зонах России, а также отмену сезонных переводов часов на территории РФ, устанавливает Федеральный закон РФ «Об исчислении времени», подписанный Президентом РФ (Д.А.Медведевым) в июне 2011 года. Однако в действительности это не так.
Действительно, существует Федеральный закон РФ «Об исчислении времени» (107-ФЗ от 3 июня 2011 г.):
— принят Государственной Думой: 20 мая 2011 г.;
— одобрен Советом Федерации: 25 мая 2011 г.;
— подписан Президентом РФ: 3 июня 2011 г.;
— опубликован: 6 июня 2011 г.;
— вступил в силу 7 августа 2011 г.
Но только он не устанавливает границы часовых зон России, не определяет время в каждой из часовых зон и не устанавливает отмену сезонного перехода на летнее время.
В этом Федеральном законе описываются просто общие определения и принципы исчисления времени (сколько суток в году, как часто високосный год, что такое календарный день/неделя/месяц/год, когда начало и конец дня/года, что такое часовая зона и местное время, как распространяется информация о точном времени и т.д.).
В этом законе также указано, что конкретные решения о делении регионов РФ на часовые зоны, об установлении границ часовых зон и об исчислении времени в этих часовых зонах принимает Правительство РФ. И для этих целей как раз и было подготовлено постановление Правительства РФ «О составе территорий, образующих каждую часовую зону, и порядке исчисления времени в часовых зонах, а также о признании утратившими силу отдельных постановлений Правительства Российской Федерации», которое эти вопросы и регламентирует. И именно в постановлении правительства указана вся конкретики касательно часовых зон РФ:
а) Установлены границы часовых зон;
б) Устанавливается сдвиг местного (локального) времени в каждой из зон;
в) Отменяется сезонный перевод часов (DST) на всей территории РФ.
Но некоторые люди почему-то ошибочно решили, что новые часовые пояса и отмена перехода на летнее время в РФ были введены ещё в ФЗ «Об исчислении времени». И некоторые редакторы Википедии, не разобравшись в ситуации, ещё в июне 2011 бросились активно исправлять статьи в Википедии, где упоминались часовые зоны России, указывая там уже новое время и отсутствие перехода на летнее время. Но в действительности никаких законных оснований для таких правок на тот момент ещё не было. Юридические основания для таких изменений появились только 6 сентября 2011, когда вступило в силу постановление Правительства РФ №725 от 31 августа 2011 г.
Табл.1 Список часовых зон* России (сентябрь 2011 г.)
* теперь в России они официально называются не часовыми поясами, а именно часовыми зонами
1-я часовая зона — MSK-1 (UTC+03:00):
Калининградская область.
2-я часовая зона — MSK (UTC+04:00):
Москва и вся европейская часть России (полный список регионов см. в Постановлении Правительства №725).
3-я часовая зона — MSK+2 (UTC+06:00):
Республика Башкортостан, Пермский край, Курганская область, Оренбургская область, Свердловская область, Тюменская область, Челябинская область, Ханты-Мансийский автономный округ — Югра и Ямало-Ненецкий автономный округ.
4-я часовая зона — MSK+3 (UTC+07:00):
Республика Алтай, Алтайский край, Кемеровская область, Новосибирская область, Омская область и Томская область.
5-я часовая зона — MSK+4 (UTC+08:00):
Республика Тыва, Республика Хакасия и Красноярский край.
6-я часовая зона — MSK+5 (UTC+09:00):
Республика Бурятия и Иркутская область.
7-я часовая зона — MSK+6 (UTC+10:00):
Большая часть Республики Саха (Якутия), включая Якутск (полный список районов Якутии см. в Постановлении Правительства №725), Забайкальский край и Амурская область.
8-я часовая зона — MSK+7 (UTC+11:00):
Приморский край, Хабаровский край, Еврейская автономная область, часть Республики Саха (Якутия) (Верхоянский, Оймяконский и Усть-Янский улусы (районы)), часть Сахалинской области (все районы, кроме Северо-Курильского).
9-я часовая зона — MSK+8 (UTC+12:00):
Камчатский край, Магаданская область, Чукотский автономный округ, часть Республики Саха (Якутия) (Абыйский, Аллаиховский, Верхнеколымский, Момский, Нижнеколымский и Среднеколымский улусы (районы)), часть Сахалинской области (Северо-Курильский район).
Часовой пояс на территории всей Белоруссии один: Минское время (UTC+03:00) — Further-eastern European Time (FET).
Часовой пояс на территории всей Украины один:Киевское время (UTC+03:00) — Further-eastern European Time (FET). Украина пока вернулась к прежнему порядку исчисления времени: зимой — стандартное Киевское время (UTC+02:00), летом — Летнее Киевское время (UTC+03:00).
Часовой пояс на территории Абхазии и Южной Осетии: Московское (или Тбилисское) время (UTC+04:00).
Часовой пояс на территории Приднестровской Молдавской Республики: (UTC+03:00) — Further-eastern European Time (FET).
Как уже было сказано выше, все перечисленные часовые зоны (кроме Украины) без перехода на летнее время (без DST), т.е. указанный сдвиг относительно UTC будет в этих часовых зонах постоянным круглый год (зимой и летом одним цветом). Для Украины пока действует правила с сезонными переходами времени, но скорее всего Украина в ближайшие месяцы перейдёт на время UTC+2 без перехода на летнее время, а значит в конце октября 2011 они в последний раз переведут часы, а весной 2012 и далее этого уже делать не будут.
В России, Белоруссии, Северной Осетии и Абхазии эти изменения в часовые пояса уже вступили в силу и действуют уже сейчас.
Кроме территорий России и Белоруссии, где только в этом году установили новые часовые зоны без перехода на летнее время, также уже несколько лет отсутствует переход на летнее время в следующих постсоветских государствах: Грузия, Казахстан, Узбекистан, Туркмения, Таджикистан, Киргизия. Из постсоветских республик переход на летнее время пока остался только в семи государствах: Литва, Латвия, Эстония, Молдавия, Азербайджан, Украина, Армения. Причём ожидается, что Украина и Армения осенью 2011 года в последний раз переводят часы, а далее примут закон об отмене сезонных переводов часов на своей территории и закрепят постоянное действие текущего стандартного времени в течение всего года.
Абхазия и Южная Осетия (частично признанные государства) также вслед за Россией объявили об отмене в 2011 году перехода на летнее время, теперь там будет часовой пояс UTC+4 круглый год (без перехода на летнее время), т.е. как во всей Грузии и в Москве.
Кроме того, из ближайших соседей России перехода на летнее время нет также в Монголии, Китае и Японии.
В целом же в мире ситуация с использованием летнего времени показана на данной иллюстрации:
Как видите, в большинстве стран Мира перехода на летнее время сейчас нет. Но почти на всей территории Северной Америки и Европы переход на летнее время по-прежнему используется. А это значит, что у нас (Россия и Белоруссия) разница во времени с этими странами теперь будет непостоянной (летом разница на час меньше, чем зимой). Первое время это будет непривычно и может вызвать некоторые неудобства, но потом постепенно привыкнем (а может и Америка с Европой потом откажутся от летнего времени, как знать).
Споры о целесообразности перехода на летнее время ведутся давно. Изначально сдвиг времени на час в летний период вводился с целью более эффективного использования светового дня и экономии электроэнергии, затрачиваемой на освещение улиц и домов в вечерние часы. И это действительно давало ощутимый экономический выигрыш лет 50 назад, когда освещение занимало весомую долю в расходах всей электроэнергии. Но в современном мире доля электроэнергии, затрачиваемой на освещение, уже невелика по сравнению с другими энергозатратами (на промышленное производство, на обогрев, на вентиляцию, на кондиционирование). В итоге и экономия от перехода на летнее время получается копеечной в общей массе энергозатрат. (По данным РАО «ЕЭС России» за 2007 год, перевод стрелок в стране позволяет сэкономить 4,4 миллиарда киловатт-часов электроэнергии, что составляет около 0,5% от общего количества потребляемого в России электричества.)
Кроме того, в тропических широтах продолжительность дня и ночи в течение года меняется слабо, а в приполярных широтах наоборот существуют полярный день летом и полярная ночь зимой. Из-за этих особенностей экономически эффективно вводить переход на летнее время только на территориях в полосе широт примерно от 30° до 55°. Увы, большая часть России находится севернее этих широт.
Ну и минусов у перевода стрелок два раза в год тоже хватает:
— сбивка расписаний движения транспорта в дни перевода часов;
— простой и экономические потери грузоперевозчиков в дни перевода часов;
— проблемы со здоровьем у людей, вызванные сдвигом режима бодрствования и сна;
— проблемы у с/х животных, вызванные, изменением времени дойки/кормёжки.
Лично я вижу в переходах на летнее время и обратно больше минусов, чем плюсов. Поэтому считаю отмену переходов на летнее время вполне оправданной.
Но, как я уже подчеркнул во вступительной части, в этой статье я бы хотел затронуть вовсе не экономические и политические мотивы отмены сезонных переводов времени. Я не хочу сейчас углубляться в обсуждение экономической эффективности и оправданности такого решения. Сейчас я в первую очередь хочу осветить техническую сторону вопроса. Т.е. давайте просто примем эти изменение часовых поясов как неизбежную данность и рассмотрим ситуацию с точки зрения её влияния на IT-инфраструктуру. Довольно лирики, переходим к технической части.
На первый взгляд проблема очевидна...
Если где-то в ваших IT-системах (приложениях/сервисах) используется локальное время (например, для отображения времени каких-то событий каждому клиенту индивидуально в его местном времени), то в системе должна быть некая база с информацией о расчёте локального времени в каждой из мировых часовых зон. И если эту базу своевременно не обновить, то с 30 октября 2011 для России и Белоруссии эта база будет давать неверный расчёт локального времени.
Допустим, вы администрируете какой-то веб-форум. Все пользователи указывают в профиле свой часовой пояс (или он автоматически вычисляется по указанному в профиле населённому пункту). Время создания сообщений в базе этого веб-форума хранятся на серверной стороне в формате UTC. При отображении сообщений каждому из пользователей к UTC-времени сообщения делается поправка на местное время просматривающего пользователя. Причём размер этой поправки вычисляется на серверной стороне по некой базе часовых поясов, которую ведут разработчики веб-движка форума.
И если администратор веб-форума эту базу вовремя не обновит, то с 30 октября 2011 расчёт локального времени для российских пользователей на этом форуме будет работать уже неправильно. Например, для указанного у пользователя московского времени правильно будет делать сдвиг UTC+4, а форум будет считать по-старому и уже неправильно: UTC+3.
Эта очевидная проблема должна решиться при обновлении соответствующей информации о часовых поясах для каждой из IT-систем, которая хоть как-то в своей работе использует локальное время. В данном примере обновить базу часовых поясов, используемую веб-форумом.
Но в действительности проблема несколько глубже...
Если бы в регионах России просто менялась часовая зона с одной на другую, то особых бы проблем не было. Это всё выглядело как переезд компьютера в другую страну и выбор в настройках его часов соответствующего часового пояса этой другой страны (только это было бы не в масштабах одного компьютера, а в масштабах всех компьютеров региона, но общий принцип тот же). Это бы не вызвало никаких проблем, т.к. практически всё ПО приспособлено для работы с разными часовыми поясами (если, конечно, его писал не какой-то уж совсем быдлокодер, который всё завязал исключительно на локальное время без учёта разных часовых поясов).
Но в данном случае для большинства регионов России (кроме Калининграда) часовой пояс не меняется, он остаётся прежним (с тем же именем), а меняются правила расчёта локального времени внутри этого пояса относительно UTC. Т.е., например, раньше Московское время (MSK) соответствовало UTC+03:00, а теперь же тот же самый часовой пояс Московской время (MSK) уже соответствует UTC+04:00. Причём при расчёте времени новых событий (например, в декабре 2011) по Московскому времени правильно будет использовать новое смещение московского времени относительно UTC (+4), а при расчёте времени старых событий (например, в декабре 2010) по Московскому времени правильно будет использовать старое смещение московского времени относительно UTC (+3), которое на тот момент действовало для московского времени. Если не применять такой дифференцированный подход к расчётам локального времени в разные исторические периоды, то такой расчёт будет неточным.
Допустим, некая IT-система, работающая с локальным временем, использует внутри себя базу часовых поясов, которая хранит актуальную информацию о всех мировых часовых зонах в виде простого плоского списка. В этом списке каждому часовому поясу однозначно соответствует некое смещение относительно UTC, действующее на текущий момент. Т.е. например «Moscow Time (MSK) — UTC+03:00» и т.д. После обновления этой базы часовых поясов записи для России в этом списке поменялись, в частности стало «Moscow Time (MSK) — UTC+04:00».
Те IT-системы, которые не обновят эту базу часовых поясов, для старых событий (например, в декабре 2010) будут вычислять локальное время по этой базе правильно, а вот уже для новых событий (например, в декабре 2011) будут вычислять локальное время по этой базе уже неправильно.
А те IT-системы, которые всё же обновят эту базу часовых поясов, для новых событий (например, в декабре 2011) будут вычислять локальное время по этой базе правильно, а для старых событий (например, в декабре 2010) уже наоборот будут вычислять локальное время по этой базе неправильно.
Т.е. даже после обновления базы часовых поясов в данной ситуации можно получить проблемы при работе с датами (а именно с датами в прошлом). А всё из-за того, что принципиальная ошибка заложена в сам принцип хранения часовых зон в виде плоского списка, актуального только на текущий момент времени.
Наиболее гибкое решение в этой ситуации — это ведение базы часовых поясов таким образом, чтобы она не просто хранила текущие правила расчёта локального времени в каждом регионе мира, а ещё и хранила историю изменений этих правил расчёта локального времени. Т.е. база должна «помнить» для каждого региона, в какой абсолютный момент времени какие правила расчёта локального времени действовали на этой территории, и в какой именно абсолютный момент времени эти правила заменились на другие. Зная корректные правила расчёта локального времени для всех регионов не только на текущий момент, но и на любой период в прошлом, можно точно проводить расчёты с использованием локального времени в любой исторический период.
Именно так устроена база tzdata (читать о tzdata подробнее), которая используется во многих *nix-системах (включая Linux, BSD, Mac OS X). И именно в этом её ключевое приемущество над другими форматами хранения информации о часовых поясах.
Разработчики Microsoft уже тоже ощутили ущербность хранения информации о часовых поясах в виде простого списка, актуального только на текущий момент времени. Например, если вы в системном реестре Windows [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones] раскроете разделы, соответствующие различным часовым поясам, то в некоторых из них вы увидите подраздел с именем «Dynamic DST». В нём как раз хранятся динамически изменяемые правила перехода на летнее время и обратно в зависимости от года (если в каком-то часовом поясе эти правила в последние годы менялись). Эту меняющуюся информацию о часовых поясах для разных лет они стали сохранять в реестре относительно недавно.
Но у меня всё равно нет уверенности в том, что всё ПО, которое использует базу часовых поясов из реестра Windows, корректно обрабатывает и эти изменения для разных лет.
Более того, в различных конференциях разработчиков уже появились жалобы на то, что после установки патча KB2570791 функции вычисления локального времени для дат в прошлом стали давать неверный результат. Вот для примера: раз и два.
В хабра-блоге Microsoft есть рекомендации для разработчиков:
habrahabr.ru/company/microsoft/blog/130629
Системным и прикладным администраторам, а также разработчикам и иным IT-специалистам следует заранее подготовить свои IT-системы, чтобы по возможности избежать проблем, связанных с изменением часовых зон.
Грамотно написанные IT-системы (приложения/сервисы/СУБД) обычно используют следующий подход к работе со временем:
1) Время везде (все записи в БД, события, логи, даты создания/изменения объектов и прочее) хранится только в абсолютных значениях Unix Time (количество секунд с начала Unix-эпохи, с 00:00:00 01.01.1970) или же в UTC.
2) Время обрабатывается (сравнивается, складывается, вычитается, сдвигается) только Unix Time (или в UTC).
3) Информация о часовом поясе, в котором следует представлять локальное время, хранится отдельно. Например, для представления пользователям информации в формате их местного времени часовой пояс берётся из профиля пользователя.
4) Отдельно ведётся и постоянно актуализируется база, хранящая информацию о правилах расчёта локального времени в разных регионах мира в разные периоды времени (например, база tzdata).
5) Имея точное время Unix Time (или в UTC), название локального часового пояса и базу с правилами расчёта локального времени для данного часового пояса, можно всегда безошибочно проводить расчёты для локального времени в любом регионе за любой период времени.
Для произведения любых действий с локальным временем оно сначала переводится Unix Time (или в UTC), согласно правилам исчисления локального времени в данном часовом поясе в данный период времени, и только потом обрабатывается. Если результат обработки следует представить в формате локального времени, то результат пересчитывается в локальное время указанной часовой зоны, согласно правилам исчисления локального времени в данном часовом поясе в данный период времени.
Точное время всех событий должен записывать не клиент, а именно сервер (в Unix Time или в UTC). Причём сервер должен иметь точное время с NTP-сервера (или иных источников синхронизации времени), а также должен иметь актуальную базу часовых поясов, чтобы проводить перерасчёты с локальным временем.
В мире unix-систем, использующих tzdata, обычно логика работы с локальным временем именно так и организована. Поэтому там будет достаточно обновить tzdata и ничего при этом не разъедется.
Но, к сожалению, далеко не все приложения и системы могут похвастаться такой грамотно выстроенной логикой работы со временем. Где-то могут быть свои костыли и велосипеды. А это значит, что далеко не везде изменение часовых зон пройдёт гладко.
Итого план действий в общих чертах такой:
* Например, по сообщению seriyPS, в Python для работы с временными зонами используется библиотека pytz. Последняя версия 2011k. Скрипт для просмотра текущей установленной версии pytz:
Для обновления библиотеки pytz:
или
Дело в том, что источники точного времени (NTP-сервер, GPS-приёмник, атомные часы) предоставляют точное абсолютное время (Unix Time). Оно в данном случае вообще никак не меняется и продолжает идти всё также равномерно и непрерывно. Вы его как раньше получали, так и продолжите получать без каких-либо разрывов и скачков по шкале времени. Источники точного времени для всех сообщают единое абсолютное время, они понятия не имеют о том кто, где и какие именно правила использует для получения из предоставленного ими абсолютного времени своего локального. Это вообще не забота источников точного времени, этим занимаются те системы/приложения, которые уже обрабатывают это время.
А вот уже если вашей ОС или ПО нужно работать с каким-либо локальным временем, тогда это абсолютное время (полученное от источника точного времени или самостоятельно отсчитываемое таймером компьютера) на стороне ОС или приложений пересчитывается в нужное локальное время (или обратно из локального в абсолютное). И для осуществления безошибочных вычислений и корректного пересчёта локального времени в ОС и ПО должна использоваться актуальная база мировых часовых поясов.
Т.е. независимо от того, синхронизируется ли ваш сервер с источником точного времени или нет, для правильной работы с часовыми поясами и локальным временем необходимо иметь обновлённую глобальную базу мировых часовых поясов. Т.е. наличие синхронизации с NTP никак не избавляет вас от забот по обновлению информации о часовых поясах для ваших IT-систем.
Разные коммерческие Unix-системы и свободные unix-like системы (GNU/Linux-дистрибутивы, BSD-системы и др.) используют различный формат хранения информации о мировых часовых зонах. Некоторые вендоры в рамках своего дистрибутива всё ещё самостоятельно ведут и поддерживают в актуальном состоянии эту информацию в своём самобытном формате (например, tztab в HP-UX).
Но всё же большинство unix-подобных систем в качестве единого глобального источника информации обо всех мировых тайм-зонах используют базу tzdata. Информация, собранная в tzdata, распространяется свободно для всех желающих без каких-либо лицензионных ограничений (public domain). Любой может свободно взять (как в исходниках, так и в бинарном виде) и использовать её в своих приложениях/библиотеках/сервисах. И многие разработчики/вендоры дистрибутивов ОС (в частности Linux/BSD/MacOS) и различного ПО именно так и делают.
В мире opensource база tzdata де-факто является стандартным источником информации обо всех мировых часовых поясах и истории их изменений. Базу tzdata используют все GNU/Linux-дистрибутивы, BSD-системы (FreeBSD, NetBSD, OpenBSD, DragonFly BSD), Solaris, UnixWare, AIX (6.1 и выше), Cygwin а также Mac OS X и некоторые другие unix-like дистрибутивы. Кроме того, данные из tzdata используется в ряде СУБД: MySQL, Oracle DB, PostgreSQL и др., а также в различных языках, фреймворках, библиотеках, модулях: PHP5, Perl (модули DateTime::TimeZone и DateTime::LeapSecond), Python (модуль pytz), GNU C Library (glibc), .NET Framework (модуль zoneinfo), Java Runtime Environment и др.
Официальная страница проекта tzdata: http://cs.ucla.edu/~eggert/tz/
Исходники tzdata и утилит для работы с часовыми поясами можно скачать здесь: ftp://elsie.nci.nih.gov/pub/ (FTP-сервер временно закрыт на время судебного разбирательства).
Зеркало со всеми файлами проекта tzdata: http://tzmirror.appealingapps.de, ftp://tzmirror.appealingapps.de
Ещё одно зеркало: ftp://munnari.oz.au/pub
Чтобы не перегружать эту статью, более подробную информацию о tzdata я вынес в отдельную статью.
На момент написания этой статьи последняя версия tzdata — это 2011l (вышла 10 октября 2011).
Изменения для новых часовых зон России появились в tzdata с версии 2011h, изменения для часовых поясов Украины и Белоруссии появились в tzdata с версии 2011k.
Поскольку парламент Украины уже успел откатить своё прежнее постановление об отмене сезонных переводов часов, получается, что tzdata-2011k и tzdata-2011l содержат ошибочную информацию о часовом поясе Украины (Europe/Kiev). Поэтому для Украины корректно будет использовать версию или более старую (2011j и ниже) или более новую (2011m и выше). Выход версии tzdata 2011m объявлен на 24 октября 2011, в эту версию должны быть внесены изменения для Украины (Europe/Kiev) и для Приднестровья (Europe/Tiraspol).
Таким образом, в *nix-системах для обновления информации о часовых поясах России и Белоруссии, изменившихся в 2011 году, необходимо установить соответствующее обновление, поставляемое вендором. Для большинства дистрибутивов, которые используют tzdata, для этого достаточно будет просто установить более новую версию пакета tzdata из стандартных репозиториев, портов и иных встроенных источников дистрибуции и обновления ПО, используемых в данном дистрибутиве ОС.
Разработчики многих дистрибутивов уже выпустили обновлённые пакеты tzdata для своих дистрибутивов. Если вы используете какой-либо Linux-дистрибутив, который вы регулярно обновляете из репозиториев, то скорее всего последняя версия пакета tzdata уже установлена у вас в системе.
Даты выхода нескольких недавних релизов tzdata на примере Ubuntu:
12 сентября 2011 — исходники tzdata обновились до версии 2011j;
14 сентября 2011 — пакет tzdata обновился до версии 2011j в апстриме Ubuntu (Debian Unstable);
20 сентября 2011 — пакет tzdata 2011j поступил в основной репозиторий Ubuntu;
26 сентября 2011 — исходники tzdata обновились до версии 2011k;
26 сентября 2011 — пакет tzdata обновился до версии 2011k в апстриме Ubuntu (Debian Unstable);
04 октября 2011 — пакет tzdata 2011k поступил в основной репозиторий Ubuntu;
10 октября 2011 — исходники tzdata обновились до версии 2011l (на момент написания статьи пакетов под Ubuntu ещё не было).
Как опциональный вариант, здесь можно найти пакеты tzdata для различных Linux-дистрибутивов:
pkgs.org/download/tzdata
В Linux-дистрибутивах с пакетными менеджерами можете просто посмотреть версию текущего установленного пакета tzdata.
В Debian/Ubuntu это можно сделать командой:
или
В Archlinux:
В CentOS/RHEL:
Если в выводе этой команды присутствует 2011h (или выше), значит в установленной версии tzdata уже учтены изменения 2011 года для часовых зон России.
Если в выводе этой команды присутствует 2011k (или выше), значит в установленной версии tzdata уже учтены изменения 2011 года для часовых зон не только России, но и Белоруссии.
Проверить, обновлена ли база tzdata в системе, можно экспериментальным способом:
Для примера набросал скриптик, который это делает: pastebin.com/VEYt9BeN
(проверял под Linux, не знаю, работает ли под другими *nix-системами)
Он проверяет 5 тестовых дат:
1. 2010-10-01 15:00 UTC
2. 2010-11-01 15:00 UTC
3. 2011-10-01 15:00 UTC
4. 2011-11-01 15:00 UTC
5. 2012-07-01 15:00 UTC
Для локального времени Москвы должно получиться:
1. 2010-10-01 19:00 MSD (UTC+04)
2. 2010-11-01 18:00 MSK (UTC+03)
3. 2011-10-01 19:00 MSK (UTC+04)
4. 2011-11-01 19:00 MSK (UTC+04)
5. 2012-07-01 19:00 MSK (UTC+04)
Для локального времени Калининграда, Киева и Минска должно получиться:
1. 2010-10-01 18:00 EEST (UTC+03)
2. 2010-11-01 17:00 EET (UTC+02)
3. 2011-10-01 18:00 FET (UTC+03)
4. 2011-11-01 18:00 FET (UTC+03)
5. 2012-07-01 18:00 FET (UTC+03)
Если в вашей системе результат вычисления локального времени для этих городов получился другим, значит у вас в tzdata информация по этим регионам не обновлена.
aig сообщил: В FreeBSD можно обновить tzdata из портов:
И установить зону заноово.
В Mac OS X текущую установленную версию tzdata можно посмотреть в файле +VERSION:
В обновлении системы Mac OS X Lion 10.7.2 пакет tzdata обновился до версии 2011h.
Это значит, что информация о часовых зонах России там уже обновлена, а вот информация о часовой зоне Белоруссии ещё нет (для этого нужна минимум версия tzdata 2011k)
Если же вендор используемой вами Unix-системы не потрудился выпустить соответствующее обновление бинарных пакетов для TZI, то вам возможно придётся делать соответствующие изменения вручную. Например, самостоятельно компилировать tzdata с помощью zic (Zone Info Compiler) из последней версии исходников или копировать готовые скомпилированные zoneinfo-файлы с уже обновлённой системы.
Некоторые дополнительные сведения об обновлении tzdata в *nix-системах можно прочесть, например, здесь:
www.linux.org.ru/wiki/en/Неперевод_часов_2011
www.opennet.ru/tips/2630_linux_timezone_time.shtml
www.itpad.ru/?p=2257
Проверяем текущую конфигурацию тайм-зон на оборудовании Cisco:
В выводе команд видим, какая тайм-зона указана для локального времени (в данном случае MSK) и какой сдвиг относительно UTC для неё действует (в данном случае UTC+3).
Теперь настраиваем правильную часовую зону для своего региона и отменяем сезонные переводы часов.
Cisco IOS (7206, 7600, GSR, ITP7200, ITP7200, ITP7600, AS5xxx, RPM-XF), IOS XR (ASR9k), IOS XE (ASR1k)
Выполнить команды:
Первая команда отключает сезонные переводы часов (в частности для московского часового пояса удаляет из конфига строку «clock summer-time MSK recurring last Sun Mar 2:00 last Sun Oct 3:00»).
Вторая команда устанавливает текущую тайм-зону (в данном случае MSK) и текущий сдвиг времени относительно UTC (в данном случае UTC+4).
Для других регионов вместо MSK следует указать свой часовой пояс (например, NSK — для Новосибирска, VLAD — для Владивостока). Укажите здесь ту же зону, которая была при выводе текущей конфигурации таймзоны (см. выше).
Cisco CatOS (Catalyst 6500)
Выполнить команды:
Первая команда отключает сезонные переводы часов.
Вторая команда устанавливает текущую тайм-зону (в данном случае MSK) и текущий сдвиг времени относительно UTC (в данном случае UTC+4).
Для других регионов вместо MSK следует указать свой часовой пояс (например, NSK — для Новосибирска, VLAD — для Владивостока). Укажите здесь ту же зону, которая была при выводе текущей конфигурации таймзоны (см. выше).
Подробнее про настройку времени в Cisco IOS см. здесь:
galushka.com/nastroyka-vremeni-na-cisco-otmenyaem-perehod-na-zimnee-letnee-vremya
Android
В Android, как и во многих других linux-based системах, для хранения информации о мировых часовых поясах используется база tzdata. Файлы пакета tzdata на файловой системе Android OS расположены по пути:
Одновление tzdata в Android обычно происходит вместе с обновлением всей прошивки. На текущий момент ситуация с обновлением tzdata в Android-устройствах печальная. Даже в последней версии Android 2.3.6 (аппараты Nexus One, Nexus S) необходимых обновлений tzdata нет.
(Для сбора более полной статистики, пожалуйста, укажите в комментариях: а) модель вашего Android-устройства, б) версию Android, в) версию tzdata).
Про самостоятельное обновление tzdata (zoneinfo) на Android-устройствах (рутованных!) можно прочесть здесь:
androidforums.com/lg-optimus-one-p500/425466-time-zone-files-zoneinfo-tzdata.html
crazy-coder.livejournal.com/26142.html
habrahabr.ru/blogs/android/130808
forum.xda-developers.com/showpost.php?p=18370053&postcount=2
Приложение для обновления tzdata до версии 2011k есть в Android Market:
https://market.android.com/details?id=com.force.timezonefixer
Maemo/MeeGo
Здесь, как и в полноценных GNU/Linux-дистрибутивах используется tzdata.
wholeman сообщил:
Maemo5 (Fremantle), Nokia N900 — tzdata не обновлена.
Maemo6 (MeeGo 1.2 Harmattan), Nokia N9/N950 — tzdata обновлена
Для устройств с busybox'ом нужно использовать команду date -d 12221931.30 +%s и сравнивать результат с 1324567890
Apple iOS (iPhone/iPad)
Apple iOS тоже в качестве базы часовых поясов использует tzdata. Текущую установленную версию tzdata, как и в MacOS X, тут можно просмотреть в файле
Владельцы iPhone/iPad могут в комментариях отписаться о том, в какой версии iOS какая версия tzdata. Учитывая, что iOS 5 вышла совсем недавно, в октябре 2011, у меня есть надежда, что tzdata там достаточно актуальной версии.
Про самостоятельное обновление tzdata (zoneinfo) на iOS (нужен JailBreak) можно прочесть здесь:
habrahabr.ru/blogs/iphone/130432
BlackBerry OS
Компания RIM (Research In Motion) выпустила для BlackBerry обновление часовых поясов (KB28317 — September 2011 DST update).
Патч этот обновляет только 7 из 9 часовых зон России. А поддержки часовых зон Омское время (Asia/Omsk UTC+7) и Калининградское время (Europe/Kaliningrad UTC+3) в ПО BlackBerry в принципе нет, поэтому и обновления для этих зон у них тоже нет. Для часового пояса Белоруссии (Europe/Minsk UTC+3) там тоже нет обновлений. В этом смысле компания RIM довольно наплевательски относится к своим клиентам, живущим в разных часовых зонах по всему миру.
При наличии корпоративного BES (BlackBerry Enterprise Server) администраторам этого сервера необходимо установить обновление на этот сервер. Для этого:
1. Должно быть установлено обновление часовых поясов на ОС сервера, где стоит BES.
2. Должно быть установлено обновление часовых поясов на корпоративных почтовых серверах, с которыми интегрирован BES.
3. Нужно применить патч от RIM на сам BlackBerry Enterprise Server (обновление BES заключается по сути в применении SQL-скрипта, который вносит правки в SQL-базу данных BES).
Все корпоративные пользователи смартфонов BlackBerry, использующие подключение через BES, получат соответствующее обновление таймзон на свой BlackBerry-девайс уже с BES автоматически.
Частные пользователи смартфонов BlackBerry могут самостоятельно скачать обновление часовых поясов (KB28317). Для установки обновления нужно открывать эту ссылку с самого смартфона BlackBerry через встроенный браузер.
Symbian, WinMobile, WP7
Я не располагаю информацией о том, где и как хранят информацию о часовых поясах такие распространённые мобильные ОС, как Symbian, WinMobile 6.x и Windows Phone 7. Также я не знаю, как у них обстоят дела с обновлением этой информации. Буду рад услышать это от вас. Если кто-то в курсе, то прошу дополнить в комментариях.
awhiler сообщил, что на Windows Phone 7.5 информация о часовых поясах уже обновлена.
zlord сообщил, что Symbian 6.2 (Nokia 6120c) уже имеет обновлённую информацию о российских часовых зонах.
Про обновления устройств Nokia на базе Symbian можно узнать здесь:
www.nokia.ru/support/product-support/phone-software-update
В Windows информация о мировых часовых поясах хранится в системном реестре, в ветке
Для России (с учётом обновлений 2011 года):
Kaliningrad Standard Time — (UTC+03:00) Калининград
Russian Standard Time — (UTC+04:00) Волгоград, Москва, Санкт-Петербург
Ekaterinburg Standard Time — (UTC+06:00) Екатеринбург
N. Central Asia Standard Time — (UTC+07:00) Новосибирск
North Asia Standard Time — (UTC+08:00) Красноярск
North Asia East Standard Time — (UTC+09:00) Иркутск
Yakutsk Standard Time — (UTC+10:00) Якутск
Vladivostok Standard Time — (UTC+11:00) Владивосток
Magadan Standard Time — (UTC+12:00) Магадан
Для Белоруссии (без учёта обновлений 2011 года):
E. Europe Standard Time — (UTC+02:00) Минск
Эту базу часовых поясов Microsoft поддерживает самостоятельно, т.е. они сами следят за полнотой и актуальностью этой базы. Изменения в эту базу обычно вносятся в виде патчей (обновлений для Windows), распространяемых через Windows Update.
Кумулятивный патч тайм-зон (KB2570791), включающий в себя обновления 2011 года для часовых поясов России, был выпущен компанией Microsoft 11 августа 2011 года:
support.microsoft.com/kb/2570791/en
support.microsoft.com/kb/2570791/ru
Патч предоставлен для версий Windows:
— Windows XP SP3 [x86, x64];
— Windows Server 2003 SP2 [x86, x64, Itanium];
— Windows Vista SP2 [x86, x64];
— Windows Server 2008 SP2 [x86, x64, Itanium];
— Windows 7 [x86, x64];
— Windows Server 2008 R2 [x64, Itanium];
— Windows Embedded Standard 7 [x86, x64].
Для Windows 2000 Professional/Server патч не был выпущен (и не будет), т.к. Win2k снята с поддержки Microsoft.
С 23-го августа 2011 года этот патч (KB2570791) поступил в Windows Update.
Если ваши Windows-системы обновляются автономно через интернет-сервис Windows Update, то они уже должны были получить это обновление. Если ваши Windows-системы обновляются централизовано через WSUS-сервер в корпоративной сети, до администраторам WSUS следует заапрувить это обновление на WSUS, тогда оно тоже придёт на все серверы и рабочие станции вашей организации.
Если же автоматическое обновление Windows в вашей организации не используется (ну мало ли), то вы можете самостоятельно скачать этот патч с сайта Microsoft (см. ссылку на статью выше) и установить его по всем Windows-машинам (вручную поштучно, скриптом, через групповые политики или через SMS/SCCM).
Данный патч просто делает соответствующие изменения в ключе системного реестра [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones], более никаких изменений патч в систему не вносит. После применения патча (KB2570791) перезагрузка системы не требуется.
Чтобы визуально убедиться, что данный патч установлен, можно заглянуть в системные настройки часовых поясов. Сдвиг часового пояса относительно UTC должен стать на час больше, чем раньше (например, для Москвы: был UTC+3, а стал UTC+4), а также должен пропасть чекбокс, включающий переход на летнее время.
Вот скриншот из Win2008-R2 после установки патча KB2570791 (на примере Москвы):
Вот скриншот из Win2003 (анимация: до и после установки патча KB2570791 на примере Москвы):
По своему опыту работы в крупных организациях я знаю, что чем крупнее и бюрократичнее организация, тем медленнее там идут все переходные процессы, и тем медленнее обновляется парк операционных систем. Поэтому в крупных организациях на части старых десктопов Windows 2000 Professional всё ещё продолжает успешно работать. Плюс ещё Win2k Server может кое-где жить и на старых серверах, на которых администраторы не торопятся апгрейдить ОС из вполне практичных соображений: «Оно работает? Не трогай его!».
Если в вашей организации представлены в том числе и Win2k-машины, то вам следует задуматься и об обновлении часовых поясов на них (по крайней мере на десктопах).
Как уже было сказано выше, патч KB2570791 для Windows 2000 не вышел.
Но патч KB2570791 только редактирует информацию о часовых поясах в системном реестре Windows. А формат хранения этой информации в реестре Win2k ничем не отличается от формата хранения этой информации в реестре WinXP или Win2k3. Поэтому чисто технически ничто не мешало Microsoft выпустить этот патч в том числе и для Win2k, причём без лишних трудозатрат. Однако Microsoft уже отказалась от поддержки Win2k, поэтому уже из принципа не выпускает для неё обновления, даже если им это ничего не стоит. Это означает, что машины с Win2k вам придётся обновлять своими силами.
Для этого достаточно:
— применить патч KB2570791 на WinXP или Win2k3;
— экспортировать из реестра пропатченной системы ветку [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones];
— взять оттуда только изменения, касающиеся часовых поясов России (хотя можно обновить информацию и вообще о всех мировых таймзонах, не отбирая только российские таймзоны);
— сохранить эти изменения в виде *.reg-файла;
— импортировать подготовленный *.reg-файл в реестр на Win2k-машинах (вручную поштучно, скриптом, через групповые политики или через SMS/SCCM).
Можно подготовить несколько подобных *.reg-файлов для разных локалей Windows (Русская, Английская), а можно особо не париться и везде применять *.reg-файл, сделанный на основе англоязычной Windows. Ничего страшного, если даже на русскоязычной системе в настройках часовых поясов отображаемое имя некоторых поясов будет выглядеть на английском языке.
Готовые reg-файлы (под русскую и английскую локаль) с правками для российский часовых зон можно скачать здесь:
* Для англоязычных Windows: pastebin.com/FRXwDM0u
* Для русскоязычных Windows: pastebin.com/mKe3GMVU
После импорта в реестр информации о новых российских часовых зонах следует заново указать системе текущий часовой пояс, чтобы обновлённая информация о нём заново перечиталась из реестра. В зависимости от часовой зоны в данном регионе делается это под Win2k/XP/2003 одной из команд:
Для регионов с Калининградским временем (MSK-1):
или
Для регионов с Московским временем (MSK):
или
Для регионов с Екатеринбургским временем (MSK+2):
или
Для регионов с Омским временем (MSK+3):
или
Для регионов с Красноярским временем (MSK+4):
или
Для регионов с Иркутским временем (MSK+5):
или
Для регионов с Якутским временем (MSK+6):
или
Для регионов с Владивостокским временем (MSK+7):
или
Для регионов с Магаданским временем (MSK+8):
или
Соответственно пакетный командный файл для обновления часовых зон на Win2k-компьютере в европейской части России может выглядеть так:
или так:
где TZ-update-Russia2011.reg — это REG-файл с настройками часовых зон России (см. выше)
Причём при распространении этого скрипта через доменные групповые политики следует использовать именно второй вариант (черен RunDLL32.exe shell32.dll).
Имейте в виду, что Win2k обновляет информацию о текущем часовом поясе не сразу же, а в начале каждой минуты. Поэтому изменения от этой команды подействуют не мгновенно, а с некоторой задержкой (не более 1 минуты).
Что касается обновления WinXP (менее SP3) и Win2k3 (менее SP2), то на них выпущенный Microsoft патч, вероятно, тоже не встанет. Поэтому, если вы их не хотите по какой-то причине обновлять до последнего сервис-пака, то ставить на них обновления часовых зон России тоже придётся через импорт изменений в реестр (по аналогии с Win2k).
Чукотка, Камчатка
Разработчики Microsoft долгое время считали, что на Камчатке у нас нет летнего времени (хотя в действительности там, как и на территории всей России/СССР, переход на летнее время применялся с 1981 по 2009 год, а в конце марта 2010 года сам этот Камчатский часовой пояс прекратил своё существование). Из этих ошибочных соображений об отсутствии там DST Камчатку они поместили в один часовой пояс с Фиджи (где перехода на летнее время действительно не было):
Fiji Standard Time — (UTC+12:00) Петропавловск-Камчатский, Фиджи [no DST]
Соответственно у пользователей Windows из регионов, где у нас использовалось Камчатское время, (Чукотка, Камчатка) в настройках часовых зон галочка перехода на летнее время не просто была снята, а там вообще сам этот чекбокс для Камчатского пояса отсутствовал. И обычными штатными настройками часовых поясов влючить летнее время там было нельзя.
Исправление (KB970653) этого бага вышло только в августе 2009 года.
В этом исправлении Камчатку удалили из пояса «Fiji Standard Time» и сделали для неё отдельный пояс «Kamchatka Standard Time», т.е. после этого патча в Windows появились два отдельных пояса:
Fiji Standard Time — (UTC+12:00) Фиджи [no DST]
Kamchatka Standard Time — (UTC+12:00) Петропавловск-Камчатский [with DST]
Из-за того, что в Windows очень долгое время не было нормального часового пояса для Чукотки и Камчатки (с поддержкой летнего времени), пользователям и администраторам в этих регионах приходилось выкручиваться самостоятельно. До появления патча KB970653 наиболее удобным решением было редактирование в системном реестре информации о часовом поясе «Fiji Standard Time», чтобы добавить в этот пояс галку перехода на летнее время и включить её.
В конце марта 2010 года в России упразднили Камчатский часовой пояс, все регионы из него перешли в Магаданский часовой пояс. Но и там эта проблема не была решена (см. ниже).
Магадан
Также разработчики Microsoft долгое время считали, что и в Магадане у нас тоже нет летнего времени (хотя в действительности там, как и на территории всей России/СССР, переход на летнее время применялся с 1981 по 2011 год). Из этих ошибочных соображений об отсутствии там DST Магадан они поместили в один часовой пояс с Соломоновыми островами, и Новой Каледонией (где перехода на летнее время действительно не было):
Central Pacific Standard Time — (UTC+11:00) Магадан, Соломоновы о-ва, Новая Каледония [no DST]
Соответственно у пользователей Windows из регионов, где у нас использовалось магаданское время, (сначала это только Магаданская область и восточные районы Якутии, а с конца марта 2010 к ним присоединились ещё и Чукотка с Камчаткой) в настройках часовых зон галочка перехода на летнее время не просто была снята, а там вообще сам этот чекбокс для Магаданского пояса отсутствовал. И обычными штатными настройками часовых поясов влючить летнее время там было нельзя.
Исправление (KB2443685) этого бага вышло только в декабре 2010 года.
В этом исправлении Магадан удалили из пояса «Central Pacific Standard Time» и сделали для него отдельный пояс «Magadan Standard Time», т.е. после этого патча в Windows появились два отдельных пояса:
Central Pacific Standard Time — (UTC+11:00) Соломоновы о-ва, Новая Каледония [no DST]
Magadan Standard Time — (UTC+11:00) Магадан [with DST]
Из-за того, что в Windows очень долгое время не было нормального часового пояса для Магадана (с поддержкой летнего времени), пользователям и администраторам в регионах с Магаданским временем приходилось выкручиваться самостоятельно. До появления патча KB2443685 наиболее удобным решением было редактирование в системном реестре информации о часовом поясе «Central Pacific Standard Time», чтобы добавить в этот пояс галку перехода на летнее время и включить её.
Если новые инсталляции Windows ставились уже после выхода патча KB2443685, то там администраторы после применения этого патча обычно уже выбирали правильный и исправленный разработчиками часовой пояс: Magadan Standard Time — (UTC+11:00) Магадан [with DST].
Но вот на большинстве Windows-систем, которые были установлены до декабря 2010, хоть после применения патча KB2443685 в списке часовых поясов и появился скорректированный магаданский часовой пояс: Magadan Standard Time — (UTC+11:00) Магадан [with DST], но вот в качестве текущего до сих пор выбран исправленный самостоятельно «Central Pacific Standard Time» с добавленным туда DST.
Таким образом, теперь при очередном исправлении российских часовых зон (KB2570791) на всех Windows-компьютерах, находящихся в регионах с Магаданским временем (Чукотка, Камчатка, Магаданская область, Северные Курилы, восточные районы Якутии) нужно будет убедиться, что в качестве текущего часового пояса выбрано именно магаданское время. А иначе этим патчем часовая зона для Магадана будет исправлена, только это не даст никакого эффекта, т.к. в истеме в качестве текущей выбрана совсем другая часовая зона.
Сделать это можно как до применения патча KB2570791 (при условии, что патч KB2443685 уже был ранее установлен), так и после. Сделать это можно как вручную, так и автоматизировать это с помощью скриптов или через SMS/SCCM. Для автоматизации можно использовать следующие консольные команды:
В Win2k Магаданский часовой пояс можно выбрать консольной командой:
В WinXP/2003 Магаданский часовой пояс можно выбрать консольной командой:
Или точно так же, как в Win2k:
В Win7/2008-R2 Магаданский часовой пояс можно выбрать консольной командой:
В WinVista/2008 я не нашёл встроенных консольных утилит для изменения текущего часового пояса, но здесь работает утилита tzutil.exe, позаимствованная из Win7 или Win2008-R2.
Сахалинская область и Якутия
Обратите внимание, что эти два региона (субъекта РФ) расположены не полностью в рамках одной часовой зоны. Часть районов расположена в одной часовой зоне, а часть в другой.
Так в Сахалинской области две часовых зоны: в Северо-Курильском районе — Магаданское время (UTC+12, MSK+8); в остальных районах Сахалинской области — Владивостокское время (UTC+11, MSK+7).
А в Якутии вообще три часовых зоны: Якутское время (UTC+10, MSK+6), Владивостокское время (UTC+11, MSK+7), Магаданское время (UTC+12, MSK+8). Точное распределение районов Якутии по этим часовым зонам см. в Постановлении Правительства №725.
Граница между часовыми зонами внутри Сахалинской области таким образом была установлена уже ранее. А вот внутри Якутии граница между часовыми зонами была изменена этим Постановлением Правительства №725.
Если вдруг у вас в этих регионах есть IT-инфраструктура, то будьте внимательны при выборе часовой зоны.
Самара, Ижевск (Удмуртия)
Для этих регионов России в Windows долгое время вообще не было отдельного часового пояса. Поэтому Windows-пользователям/администраторам в этих регионах приходилось искать обходные пути и выбирать в настройках времени часовой пояс соседних государств (обычно Армению/Ереван или Азербайджан/Баку), в которых использовалось аналогичное исчисление времени. В конце марта 2010 часовой пояс с Самарским временем (MSK+1) вообще упразднили, присоединив Самарскую область и Удмуртию к московскому времени. И сейчас по-хорошему во всех Windows-системах в этих регионах должно быть выбрано московское время.
Но остатки старых извращений с выбором иностранных часовых зон могли ещё где-то сохраниться в настройках некоторых Windows-машин. Поэтому на всякий случай проверьте и при необходимости замените везде время на московское. Можно вручную, а можно опять же заскриптовать и автоматизировать, используя для выбора Московской часовой зоны консольные команды:
xp,2003:
2k,xp,2003:
WinVista/2008:
Win7/2008-R2:
Калининград
Отдельного часового пояса для Калининградской области в Windows раньше не было, поэтому в настройках часовых зон в Калининграде обычно выбирали какой-то европейский часовой пояс, соответствующий местному времени, например:
FLE Standard Time — (UTC+02:00) Вильнюс, Киев, Рига, София, Таллин, Хельсинки
E. Europe Standard Time — (UTC+02:00) Минск
GTB Standard Time — (UTC+02:00) Афины, Бухарест
Теперь же в обновлении KB2570791 в Windows для Калининграда добавили свой отдельный часовой пояс (без DST):
Kaliningrad Standard Time — (UTC+03:00) Калининград
Но после применения данного патча этот новый часовой пояс для Калининграда просто добавится в список часовых поясов, а выбран в качестве текущего он автоматически не будет. Поэтому после (обязательно после!) применения патча KB2570791 на Windows-компьютерах в Калининграде там нужно будет дополнительно в настройках часовых поясов выбрать для системы калининградское время. Можно это сделать вручную, а можно опять же заскриптовать и автоматизировать, используя для выбора Калининградской часовой зоны консольные команды:
xp,2003:
2k,xp,2003:
или
WinVista/2008:
Win7/2008-R2:
Белоруссия
Что касается изменения часового пояса в Белоруссии, то компании Microsoft известно об этом, но они сейчас не будут выпускать для времени в Белоруссии соответствующий Windows-патч. Им, видимо, лень напрягаться и выбиваться из планового графика кумулятивных апдейтов. Изменения тайм-зон для Украины, Белоруссии и Армении они планируют включить в очередное кумулятивное обновление часовых поясов Windows, которое выйдет в декабре 2011. Но пока непонятно, будут ли к тому моменту какие-либо законодательные решения об этом в Армении и Украине. А до тех пор компания Microsoft предлагает своим Windows-польльзователям из Белоруссиилососнуть тунца самостоятельно вручную использовать такой костыль:
1) Установить патч KB2570791, который меняет тайм-зоны России.
2) Для пользователей из Белоруссии в качестве своего часового пояса выбрать: (UTC +3:00) Kaliningrad
А после того, как в декабре 2011 года выйдет очередной кумулятивный WinUpdate тайм-зон, в котором они наконец сделают исправление часового пояса для Белоруссии (а возможно для Украины и Армении тоже), они предлагают всем пользователям из Белоруссии установить этот апдейт, а потом опять же вручную в настройках системного времени вернуть часовой пояс на родной (уже испроавленный) для своей страны.
Это вовсе не моя выдумка, вот официальная статья от Microsoft, в которой об этом написано:
support.microsoft.com/kb/2625508/en
support.microsoft.com/kb/2625508/ru
Установку Калининградского времени (после патча KB2570791) для Белоруссии можно сделать вручную, а можно опять же заскриптовать и автоматизировать, используя для выбора Калининградской часовой зоны консольные команды:
xp,2003:
2k,xp,2003:
или
WinVista/2008:
Win7/2008-R2:
Нужно просто установить патч KB2570791 на серверы контроллеров домена, как и на любые другие Windows-машины. Чтобы на контроллерах домена не было различий, желательно установить это обновление на все контроллеры AD-леса в один день.
С обновлением контроллеров есть один известный мне баг. Если в вашей организации по каким-то параноидальным требованиям безопасности для пользователей установлено ограничение по времени входа в систему (Logon Hours) и соответственно у ваших пользователей есть заполненный атрибут logonHours, то сразу после установки апдейта KB2570791 на контроллеры домена у всех пользователей диапазоны разрешённого входа в систему сместятся на час. Эту проблему вы почувтсвуете не после 30 октября, а непосредственно сразу после патча контроллеров.
Например, если разрешённое время входа у ваших пользователей было установлено диапазоном с 9 до 18 часов, то после патча контроллеров домена пользователям будет разрешено логиниться уже с 10 до 19 часов. Т.е. пользователи, которые с таким ограничением придут на следующее утро на работу уже не смогут войти в систему пока администратор не уберет это ограничение или пока не наступит 10 часов утра.
Причём этот интервал разрешённого логона будет сдвигаться только на тех контроллерах, где был установлен патч KB2570791. И если у вас на одних контроллерах этот патч был установлен, а на других ещё нет, то может так получиться, что одни пользователи смогли залогиниться (т.к. при логоне попали на непропатченный контроллер), а другие не смогли (т.к. при логоне попали на уже пропатченный контроллер), хотя изначально разрешения на время логона у них стояли одинаковые. Это обстоятельство может несколько затруднить вам диагностику проблемы.
Поэтому прежде, чем устанавливать патч KB2570791 на контроллеры домена, нужно оценить, как много пользователей в вашем домене имеют ограничение времени логона в систему. Для этого можно выгрузить в файл список пользователей с их logonHours и изучить его. Пример PowerShell-скрипта для выгрузки пользователей с атрибутом logonHours: pastebin.com/0Ucu7MKi
Если таких пользователей нет, то всё ОК, все контроллеры можно безболезненно патчить. Если такие пользователи в AD есть, то проблему с ними нужно как-то решать. Очевидных варианта два:
1) Отказаться от этих ограничений на время входа и у всех пользователей заполнить атрибут logonHours, чтобы там не было ограничений на время входа (можно скриптом);
2) Написать скрипт, который у всех пользователей будет сдвигать все диапазоны logonHours на один час назад, и запустить этот скрипт сразу после патча всех контроллеров домена.
С хранением информации о часовых поясах в почтовой системе Exchange вообще творится какой-то бардак.
Наиболее ожидаемая проблема с почтовой системой Exchange при данном изменении часовых зон — это рассинхронизация календарных событий в различных календарях. Допустим, деловая встреча совета директоров назначена на 10 часов, но один из участников её увидел в своём календаре в 9 часов (и пришёл на час раньше), другой увидел её в своём календаре в 10 часов (и пришёл вовремя), а третий увидел её в своём календаре в 11 часов (и опоздал на час).
Например, разовые события, добавляемые в календарь, и регулярно повторяющиеся события (например, ежегодные) хранятся в почтовой базе Exchange в различных форматах: в одном случае часовая зона хранится вместе с указанным временем, а в другом случае не хранится. И при изменении часовых зон это будет иметь значение.
Ещё при доступе к одному и тому же календарю через MS Office Outlook и через OWA (Outlook Web Access) можно увидеть разные данные, т.к. у OWA какой-то свой взгляд на информацию о часовых поясах.
Плюс на корректность отображения календарных событий в разных календарях могут повлиять и другие факторы:
— какие версии Outlook стоят на компьютерах отправителя и получателя;
— почтовый ящик хранится на сервере в почтовой базе или локально в PST-файле;
— пропатчены или нет Windows-системы на обоих компьютерах отправителя и получателя;
— в одной ли часовой зоне находятся отправитель и получатель;
— до установки патча или после создано календарное событие;
— пропатчены или нет Windows-системы на Exchange mailbox-серверах, на которых размещены ящики отправителя и получателя;
и т.д.
Причём в большинстве случаев проблем с рассинхронизацией календарных событий может и не быть, но при некоторой комбинации обозначенных выше факторов некоторые события в разных календарях могут и разъехаться по времени.
Например, если сейчас пользователь с Windows-машины без установленного апдейта KB2570791 назначит в своём календаре встречу, допустим, на 1 ноября 2011 (или на другой день после 30 октября 2011) с 10:00 до 11:00, а потом отправит приглашение на эту встречу пользователю, у которого на Windows-машине уже стоит патч KB2570791, то отправитель и получатель в своих календарях будут видеть это событие в разное время. У отправителя с 10:00 до 11:00, а у получателя с 11:00 до 12:00, поэтому он рискует опоздать на эту встречу.
И наоборот, если создавать встречу на дату после 30 октября на пропатченной машине и отправлять приглашение пользователю на непропатченной машине, то сдвиг времени на час будет уже в обратную сторону. Самое неприятное здесь то, что отправитель и получатель календарных событий могут быть вообще из разных организаций. А значит установить патчи на обе их машины у вас просто может не быть никакой технической возможности (вам может быть подконтролен компьютер только одного из этих пользователей).
По заявлениям Microsoft, вопрос хранения информации о часовых поясах более менее причесали в Exchange 2010, а вот при использовании Exchange 2003 и Exchange 2007 вполне возможны обозначенные проблемы с рассинхронизацией календарных событий. Причём срузу после установки патча KB2570791 на рабочие станции клиентов и на Exchange-серверы проблемы могут и не появиться, а вот после того, как 30 октября 2011 непропатченные Windows-системы сдвинут на час назад время, вот тогда и возможны такие проблемы с календарями.
Поддержка Microsoft не даёт однозначного ответа о том, как заранее гарантировано обезопасить свою почтовую систему Exchange от подобных проблем, но их рекомендации следующие:
1. Установить патч KB2570791 на все клиентские Windows-машины;
2. Установить патч KB2570791 на все Exchange-серверы организации и на все контроллеры домена;
3. Если у вас есть серверы Exchange 2007 (SP3), то установить на них Update Rollup 5;
4. Далее наблюдать и выявлять проблемы с календарными событиями у пользователей.
5. Если пользователи будут жаловаться на сдвиг календарных событий в своих календарях, тогда:
а) либо на серверной стороне запускать Exchange Calendar Update Tool, чтобы пофиксить календари на конкретных серверах для конкретных проблемных пользователей;
б) либо на клиентской стороне запускать Outlook Time Zone Data Update Tool, чтобы пофиксить календари на стороне Outlook.
На серверы с MS SharePoint, во-первых, следует установить обновление Windows KB2570791, а во-вторых, установить обновление для самого SharePoint:
— обновление для MS SharePoint 2007 (SharePoint Serveces 3.0);
— обновление для MS SharePoint 2010.
Также смотри информацию про обновления часовых зон для продуктов Microsoft здесь:
support.microsoft.com/gp/cp_dst/ru
support.microsoft.com/gp/cp_dst/en
Формально в России и Белоруссии уже действует новое исчисление времени в часовых зонах (см. принятые законы). Поэтому все обновления ОС/ПО, связанные с этим, уже можно и даже нужно делать. Причём провести все работы по обновлению часовых зон нужно постараться до 30 октября 2011. Потому как системы с необновлённой информацией о новых часовых зонах 30 октября (последнее воскресенье октября) попытаются вернуться с летнего времени на стандартное (т.к. не знают, что переходы уже отменены), и это может вызвать проблемы (как минимум проблемы с некорректным отображением местного времени).
До времени Ч осталась всего-то пара рабочих недель. Поэтому не откладывайте эти работы в долгий ящик. Ещё раз внимательно просмотрите своё IT-хозяйство (серверы, приложения, сервисы и прочее), спланируйте и проведите работы, чтобы обновить информацию о часовых зонах везде, где можно.
Остаётся только надеяться, что эти проблемы не затронут системы вашей компании уровня BC (Business Critical) и MC (Mission Critical). Например, если ваши бизнес завязан на системах биллинга или каких-то точных финансовых рассчётах, имеющих привязку к локальному времени (как в настоящем, так и в прошлом), то возникшие проблемы со временем могут вызвать для вас вполне конкретные бизнес-потери.
Затрагивание некритичных систем уровня OP (Office Productivity), типа сдвига на час некоторых календарных событий в Outlook, с точки зрения бизнеса обычно несущественно.
Паниковать, конечно, не стоит, но будьте готовы к тому, что проблемы, связанные с изменением часовых зон, в каких-то IT-системах очень вероятны. Если не сразу после применения вами патчей/фиксов, то с 30 октября 2011 уж наверняка.
Также см. другой топик на тему изменения часовых зон в России:
Переезд временной зоны MSD в MSK — новый Y2K локального масштаба
В списке этих государств: Россия, Белоруссия, Украина, частично признанные государства: Абхазия и Южная Осетия, а также непризнанное государство Приднестровье. Т.е. во всех часовых поясах этих стран теперь круглый год будет фиксированный сдвиг относительно UTC, без дополнительных сезонных сдвигов.
(Примечание: Украина сначала приняла решение о переходе на время UTC+3 без летнего времени, но потом отменила принятое ранее решение и пока вернулась к прежнему порядку исчисления времени с сезонными переводами часов. Подробности ниже.)
В этой статье я опишу суть принятых изменений часовых поясов и опишу техническую сторону вопроса касательно IT-систем (корпоративной инфраструктуры, серверов, рабочих станций, сервисов, приложений и т.п.). Постараюсь ответить на ряд основных вопросов, возникающих в связи с этими изменениями:
— Какие IT-системы может затронуть изменение часовых поясов?
— Какие проблемы это может вызвать?
— Как подготовиться к этому, чтобы по возможности избежать проблем?
Полагаю, многим системным/прикладным администраторам, а также некоторым разработчикам приложений/сервисов, полезно будет ознакомиться с этим материалом. А потом предлагаю всем заинтересованным обсудить и дополнить эту информацию в комментариях.
Содержание
Так «летнее» или «зимнее» время отменили?
Законодательные основы для изменения исчисления времени
Какое время будет в новых часовых поясах?
Список часовых зон России
Состав территорий РФ, образующих часовые зоны РФ
Часовые пояса Украины и Белоруссии
А что с летним временем в других странах?
Целесообразность использования летнего времени
Какие могут быть проблемы из-за изменения часовых зон?
Что делать?
А что, если у нас точное времени синхронизируется с NTP или GPS?
Обновление информации о часовых поясах (TZI, Time Zone Information) в различных ОС
Unix-системы и unix-подобные ОС
Сетевое оборудование Cisco
Мобильные ОС
MS Windows
Обновление устаревших Windows-систем
Особенности перенастройки часовых зон в Windows для разных регионов
Чукотка, Камчатка
Магадан
Сахалинская область и Якутия
Самара, Ижевск (Удмуртия)
Калининград
Белоруссия
Обновление часовых зон на контроллерах домена MS Active Diectory
Обновление часовых зон на MS Exchange-серверах
Обновление часовых зон на MS Sharepoint-серверах
Когда нужно обновить информацию о часовых зонах в ОС и ПО?
Так «летнее» или «зимнее» время отменили?
Некоторые журналисты в новостных заметках трактовали эти изменения часовых зон в России и Белоруссии как «отмену зимнего времени». С обывательской точки зрения всё именно так и выглядит, т.к. переход на летнее время весной в этих странах был, а обратного перехода не будет. Поэтому кажется, что время теперь всегда «летнее», а «зимнего» времени больше не будет.
Но формально никакого «зимнего времени» просто не существует. Существует стандартное время, плюс в некоторых странах принят сезонный переход на летнее время (DST, Daylight saving time), когда в летний период (обычно с конца марта по конец октября) к стандартному местному времени добавляется ещё один час.
Так вот теперь во всех часовых поясах России и Белоруссии происходят два события:
1) К стандартному времени на постоянной основе прибавляется ещё один час.
2) Отменяются сезонные переводы часов (т.е. отменяется переход на летнее время и обратно).
Таким образом, в ночь с 29 на 30 октября 2011, когда почти все европейские страны будут переводить часы на один час назад, чтобы вернуть своё локальное время с летнего на стандартное, в России и Белоруссии перевод часов уже осуществляться не будет, т.к. новое принятое время как раз совпадает с ранее действовавшим летним временем на этих территориях. Ну и в дальнейшем в этих странах часы на летнее время и обратно уже переводиться не будут (до тех пор, пока данные решения не будут законодательно отменены).
Законодательные основы для изменения исчисления времени
В России данные изменения введены* Постановлением Правительства РФ от 31 августа 2011 г. №725 «О составе территорий, образующих каждую часовую зону, и порядке исчисления времени в часовых зонах, а также о признании утратившими силу отдельных постановлений Правительства Российской Федерации» (опубликовано и вступило в силу 6 сентября 2011).
В Белоруссии данные изменения введены постановлением Совета министров Республики Беларусь от 15 сентября 2011 г. №1229 «Об исчислении времени на территории Республики Беларусь» (PDF).
На Украине:
20 сентября 2011 г. — Верховная Рада Украины приняла Постановление №3755-VI «Об изменении порядка исчисления времени на территории Украины» [DOC] (подписано Председателем Верховной Рады Украины 29 сентября 2011). Это постановление устанавливало на территории всей Украины время UTC+3 и отмену сезонных переводов часов, т.е. сохранение времени UTC+3 весь год.
18 октября 2011 г. — Верховная Рада Украины приняла новое Постановление №3914-VI «О признании утратившим силу Постановления Верховной Рады Украины 'Об изменении порядка исчисления времени на территории Украины'» [DOC] (подписано Председателем Верховной Рады Украины 19 октября 2011), которое признаёт предыдущее принятое 20.09.2011 и уже вступившее в силу Постановление Верховной Рады №3755-VI утратившим силу. Соответственно после вступления в силу этого Постановления ВР №3914-VI на Украине вернулся прежний порядок исчисления локального времени: стандартное время (зимой) UTC+2 и летнее время UTC+3.
После 30 октября 2011 г., когда Украина вернётся с летнего времени (UTC+3) на своё стандартное время (UTC+2), Кабинет Министров Украины должен направить на рассмотрение в Верховную Раду Украины законопроект, который отменит для Украины сезонные переводы часов на летнее время. Если это постановление будет принято, то Украина в конце марта 2012 уже не будет переходить на летнее время, и на всей территории Украины круглый год будет фиксированное время UTC+2 (без DST).
В Армении, судя по сообщениям в прессе, проект закона об отмене сезонных переходов на летнее время и обратно готовится, но ещё законодательно не принят парламентом (Национальным Собранием) Армении. Уже точно известно, что 30 октября 2011 года Армения преводит часы на час назад с летнего времени (UTC+5) на стандартное время (UTC+4). Но ожидается, что до марта 2012 г. закон, отменяющий сезонные переводы часов в Армении, будет окончательно утверждён и вступит в силу. Если это произойдёт, то Армения в конце марта 2012 уже не будет переходить на летнее время, и там круглый год будет фиксированное время UTC+4 (без DST).
Ссылок на официальные законодательные акты Абхазии и Южной Осетии, устанавливающие изменение часовых зон в 2011 году, у меня нет. Насколько мне известно, таких документов вообще не существует. Просто в этих странах во время провозглашения независимости установлено соответствие местного времени Московскому (из политических соображений). Соответственно из-за изменения в 2011 году Московского времени и отказа от перехода на летнее время в России, в Абхазии и Южной Осетии также меняется время по аналогии с Москвой. Таким образом, теперь в Абхазии и Южной Осетии местное время будет совпадать с местным временем во всей Грузии (UTC+4) не только летом, а вообще круглогодично.
В Приднестровской Молдавской Республике данные изменения введены Указом Президента ПМР от 10 октября 2011 г. №770 «Об отмене перехода на сезонное время на территории Приднестровской Молдавской Республики» (вступает в силу с 18 октября 2011 г.). Причём вся остальная Молдавия не изменяет порядок исчисления времени на своей территории, поэтому 30 октября 2011 Молдавия перейдёт обратно на своё стандартное (зимнее) время.
*Примечание: в некоторых статьях в интернете на тему изменения часовых зон в России в 2011 году ошибочно указывается, что новый порядок исчисления времени в часовых зонах России, а также отмену сезонных переводов часов на территории РФ, устанавливает Федеральный закон РФ «Об исчислении времени», подписанный Президентом РФ (Д.А.Медведевым) в июне 2011 года. Однако в действительности это не так.
Действительно, существует Федеральный закон РФ «Об исчислении времени» (107-ФЗ от 3 июня 2011 г.):
— принят Государственной Думой: 20 мая 2011 г.;
— одобрен Советом Федерации: 25 мая 2011 г.;
— подписан Президентом РФ: 3 июня 2011 г.;
— опубликован: 6 июня 2011 г.;
— вступил в силу 7 августа 2011 г.
Но только он не устанавливает границы часовых зон России, не определяет время в каждой из часовых зон и не устанавливает отмену сезонного перехода на летнее время.
В этом Федеральном законе описываются просто общие определения и принципы исчисления времени (сколько суток в году, как часто високосный год, что такое календарный день/неделя/месяц/год, когда начало и конец дня/года, что такое часовая зона и местное время, как распространяется информация о точном времени и т.д.).
В этом законе также указано, что конкретные решения о делении регионов РФ на часовые зоны, об установлении границ часовых зон и об исчислении времени в этих часовых зонах принимает Правительство РФ. И для этих целей как раз и было подготовлено постановление Правительства РФ «О составе территорий, образующих каждую часовую зону, и порядке исчисления времени в часовых зонах, а также о признании утратившими силу отдельных постановлений Правительства Российской Федерации», которое эти вопросы и регламентирует. И именно в постановлении правительства указана вся конкретики касательно часовых зон РФ:
а) Установлены границы часовых зон;
б) Устанавливается сдвиг местного (локального) времени в каждой из зон;
в) Отменяется сезонный перевод часов (DST) на всей территории РФ.
Но некоторые люди почему-то ошибочно решили, что новые часовые пояса и отмена перехода на летнее время в РФ были введены ещё в ФЗ «Об исчислении времени». И некоторые редакторы Википедии, не разобравшись в ситуации, ещё в июне 2011 бросились активно исправлять статьи в Википедии, где упоминались часовые зоны России, указывая там уже новое время и отсутствие перехода на летнее время. Но в действительности никаких законных оснований для таких правок на тот момент ещё не было. Юридические основания для таких изменений появились только 6 сентября 2011, когда вступило в силу постановление Правительства РФ №725 от 31 августа 2011 г.
Какое время будет в новых часовых поясах?
Список часовых зон России
Табл.1 Список часовых зон* России (сентябрь 2011 г.)
№ | Местное время | UTC offset | DST | Междунар. название | Междунар. аббрев. |
1 | Московское время -1 | UTC+03:00 | - | Kaliningrad Time | USZ1, FET (MSK-1) |
2 | Московское время | UTC+04:00 | - | Moscow Time | MSK |
3 | Московское время +2 | UTC+06:00 | - | Yekaterinburg Time | YEKT (MSK+2) |
4 | Московское время +3 | UTC+07:00 | - | Omsk Time | OMST (MSK+3) |
5 | Московское время +4 | UTC+08:00 | - | Krasnoyarsk Time | KRAT (MSK+4) |
6 | Московское время +5 | UTC+09:00 | - | Irkutsk Time | IRKT (MSK+5) |
7 | Московское время +6 | UTC+10:00 | - | Yakutsk Time | YAKT (MSK+6) |
8 | Московское время +7 | UTC+11:00 | - | Vladivostok Time | VLAT (MSK+7) |
9 | Московское время +8 | UTC+12:00 | - | Magadan Time | MAGT (MSK+8) |
Состав территорий РФ, образующих часовые зоны РФ:
1-я часовая зона — MSK-1 (UTC+03:00):
Калининградская область.
2-я часовая зона — MSK (UTC+04:00):
Москва и вся европейская часть России (полный список регионов см. в Постановлении Правительства №725).
3-я часовая зона — MSK+2 (UTC+06:00):
Республика Башкортостан, Пермский край, Курганская область, Оренбургская область, Свердловская область, Тюменская область, Челябинская область, Ханты-Мансийский автономный округ — Югра и Ямало-Ненецкий автономный округ.
4-я часовая зона — MSK+3 (UTC+07:00):
Республика Алтай, Алтайский край, Кемеровская область, Новосибирская область, Омская область и Томская область.
5-я часовая зона — MSK+4 (UTC+08:00):
Республика Тыва, Республика Хакасия и Красноярский край.
6-я часовая зона — MSK+5 (UTC+09:00):
Республика Бурятия и Иркутская область.
7-я часовая зона — MSK+6 (UTC+10:00):
Большая часть Республики Саха (Якутия), включая Якутск (полный список районов Якутии см. в Постановлении Правительства №725), Забайкальский край и Амурская область.
8-я часовая зона — MSK+7 (UTC+11:00):
Приморский край, Хабаровский край, Еврейская автономная область, часть Республики Саха (Якутия) (Верхоянский, Оймяконский и Усть-Янский улусы (районы)), часть Сахалинской области (все районы, кроме Северо-Курильского).
9-я часовая зона — MSK+8 (UTC+12:00):
Камчатский край, Магаданская область, Чукотский автономный округ, часть Республики Саха (Якутия) (Абыйский, Аллаиховский, Верхнеколымский, Момский, Нижнеколымский и Среднеколымский улусы (районы)), часть Сахалинской области (Северо-Курильский район).
Часовые пояса Украины, Белоруссии, Абхазии, Северной Осетии и ПМР
Часовой пояс на территории всей Белоруссии один: Минское время (UTC+03:00) — Further-eastern European Time (FET).
Часовой пояс на территории всей Украины один:
Часовой пояс на территории Абхазии и Южной Осетии: Московское (или Тбилисское) время (UTC+04:00).
Часовой пояс на территории Приднестровской Молдавской Республики: (UTC+03:00) — Further-eastern European Time (FET).
Как уже было сказано выше, все перечисленные часовые зоны (кроме Украины) без перехода на летнее время (без DST), т.е. указанный сдвиг относительно UTC будет в этих часовых зонах постоянным круглый год (зимой и летом одним цветом). Для Украины пока действует правила с сезонными переходами времени, но скорее всего Украина в ближайшие месяцы перейдёт на время UTC+2 без перехода на летнее время, а значит в конце октября 2011 они в последний раз переведут часы, а весной 2012 и далее этого уже делать не будут.
В России, Белоруссии, Северной Осетии и Абхазии эти изменения в часовые пояса уже вступили в силу и действуют уже сейчас.
А что с летним временем в других странах?
Кроме территорий России и Белоруссии, где только в этом году установили новые часовые зоны без перехода на летнее время, также уже несколько лет отсутствует переход на летнее время в следующих постсоветских государствах: Грузия, Казахстан, Узбекистан, Туркмения, Таджикистан, Киргизия. Из постсоветских республик переход на летнее время пока остался только в семи государствах: Литва, Латвия, Эстония, Молдавия, Азербайджан, Украина, Армения. Причём ожидается, что Украина и Армения осенью 2011 года в последний раз переводят часы, а далее примут закон об отмене сезонных переводов часов на своей территории и закрепят постоянное действие текущего стандартного времени в течение всего года.
Абхазия и Южная Осетия (частично признанные государства) также вслед за Россией объявили об отмене в 2011 году перехода на летнее время, теперь там будет часовой пояс UTC+4 круглый год (без перехода на летнее время), т.е. как во всей Грузии и в Москве.
Кроме того, из ближайших соседей России перехода на летнее время нет также в Монголии, Китае и Японии.
В целом же в мире ситуация с использованием летнего времени показана на данной иллюстрации:
Как видите, в большинстве стран Мира перехода на летнее время сейчас нет. Но почти на всей территории Северной Америки и Европы переход на летнее время по-прежнему используется. А это значит, что у нас (Россия и Белоруссия) разница во времени с этими странами теперь будет непостоянной (летом разница на час меньше, чем зимой). Первое время это будет непривычно и может вызвать некоторые неудобства, но потом постепенно привыкнем (а может и Америка с Европой потом откажутся от летнего времени, как знать).
Целесообразность использования летнего времени
Споры о целесообразности перехода на летнее время ведутся давно. Изначально сдвиг времени на час в летний период вводился с целью более эффективного использования светового дня и экономии электроэнергии, затрачиваемой на освещение улиц и домов в вечерние часы. И это действительно давало ощутимый экономический выигрыш лет 50 назад, когда освещение занимало весомую долю в расходах всей электроэнергии. Но в современном мире доля электроэнергии, затрачиваемой на освещение, уже невелика по сравнению с другими энергозатратами (на промышленное производство, на обогрев, на вентиляцию, на кондиционирование). В итоге и экономия от перехода на летнее время получается копеечной в общей массе энергозатрат. (По данным РАО «ЕЭС России» за 2007 год, перевод стрелок в стране позволяет сэкономить 4,4 миллиарда киловатт-часов электроэнергии, что составляет около 0,5% от общего количества потребляемого в России электричества.)
Кроме того, в тропических широтах продолжительность дня и ночи в течение года меняется слабо, а в приполярных широтах наоборот существуют полярный день летом и полярная ночь зимой. Из-за этих особенностей экономически эффективно вводить переход на летнее время только на территориях в полосе широт примерно от 30° до 55°. Увы, большая часть России находится севернее этих широт.
Ну и минусов у перевода стрелок два раза в год тоже хватает:
— сбивка расписаний движения транспорта в дни перевода часов;
— простой и экономические потери грузоперевозчиков в дни перевода часов;
— проблемы со здоровьем у людей, вызванные сдвигом режима бодрствования и сна;
— проблемы у с/х животных, вызванные, изменением времени дойки/кормёжки.
Лично я вижу в переходах на летнее время и обратно больше минусов, чем плюсов. Поэтому считаю отмену переходов на летнее время вполне оправданной.
Но, как я уже подчеркнул во вступительной части, в этой статье я бы хотел затронуть вовсе не экономические и политические мотивы отмены сезонных переводов времени. Я не хочу сейчас углубляться в обсуждение экономической эффективности и оправданности такого решения. Сейчас я в первую очередь хочу осветить техническую сторону вопроса. Т.е. давайте просто примем эти изменение часовых поясов как неизбежную данность и рассмотрим ситуацию с точки зрения её влияния на IT-инфраструктуру. Довольно лирики, переходим к технической части.
Какие могут быть проблемы из-за изменения часовых зон?
На первый взгляд проблема очевидна...
Если где-то в ваших IT-системах (приложениях/сервисах) используется локальное время (например, для отображения времени каких-то событий каждому клиенту индивидуально в его местном времени), то в системе должна быть некая база с информацией о расчёте локального времени в каждой из мировых часовых зон. И если эту базу своевременно не обновить, то с 30 октября 2011 для России и Белоруссии эта база будет давать неверный расчёт локального времени.
Допустим, вы администрируете какой-то веб-форум. Все пользователи указывают в профиле свой часовой пояс (или он автоматически вычисляется по указанному в профиле населённому пункту). Время создания сообщений в базе этого веб-форума хранятся на серверной стороне в формате UTC. При отображении сообщений каждому из пользователей к UTC-времени сообщения делается поправка на местное время просматривающего пользователя. Причём размер этой поправки вычисляется на серверной стороне по некой базе часовых поясов, которую ведут разработчики веб-движка форума.
И если администратор веб-форума эту базу вовремя не обновит, то с 30 октября 2011 расчёт локального времени для российских пользователей на этом форуме будет работать уже неправильно. Например, для указанного у пользователя московского времени правильно будет делать сдвиг UTC+4, а форум будет считать по-старому и уже неправильно: UTC+3.
Эта очевидная проблема должна решиться при обновлении соответствующей информации о часовых поясах для каждой из IT-систем, которая хоть как-то в своей работе использует локальное время. В данном примере обновить базу часовых поясов, используемую веб-форумом.
Но в действительности проблема несколько глубже...
Если бы в регионах России просто менялась часовая зона с одной на другую, то особых бы проблем не было. Это всё выглядело как переезд компьютера в другую страну и выбор в настройках его часов соответствующего часового пояса этой другой страны (только это было бы не в масштабах одного компьютера, а в масштабах всех компьютеров региона, но общий принцип тот же). Это бы не вызвало никаких проблем, т.к. практически всё ПО приспособлено для работы с разными часовыми поясами (если, конечно, его писал не какой-то уж совсем быдлокодер, который всё завязал исключительно на локальное время без учёта разных часовых поясов).
Но в данном случае для большинства регионов России (кроме Калининграда) часовой пояс не меняется, он остаётся прежним (с тем же именем), а меняются правила расчёта локального времени внутри этого пояса относительно UTC. Т.е., например, раньше Московское время (MSK) соответствовало UTC+03:00, а теперь же тот же самый часовой пояс Московской время (MSK) уже соответствует UTC+04:00. Причём при расчёте времени новых событий (например, в декабре 2011) по Московскому времени правильно будет использовать новое смещение московского времени относительно UTC (+4), а при расчёте времени старых событий (например, в декабре 2010) по Московскому времени правильно будет использовать старое смещение московского времени относительно UTC (+3), которое на тот момент действовало для московского времени. Если не применять такой дифференцированный подход к расчётам локального времени в разные исторические периоды, то такой расчёт будет неточным.
Допустим, некая IT-система, работающая с локальным временем, использует внутри себя базу часовых поясов, которая хранит актуальную информацию о всех мировых часовых зонах в виде простого плоского списка. В этом списке каждому часовому поясу однозначно соответствует некое смещение относительно UTC, действующее на текущий момент. Т.е. например «Moscow Time (MSK) — UTC+03:00» и т.д. После обновления этой базы часовых поясов записи для России в этом списке поменялись, в частности стало «Moscow Time (MSK) — UTC+04:00».
Те IT-системы, которые не обновят эту базу часовых поясов, для старых событий (например, в декабре 2010) будут вычислять локальное время по этой базе правильно, а вот уже для новых событий (например, в декабре 2011) будут вычислять локальное время по этой базе уже неправильно.
А те IT-системы, которые всё же обновят эту базу часовых поясов, для новых событий (например, в декабре 2011) будут вычислять локальное время по этой базе правильно, а для старых событий (например, в декабре 2010) уже наоборот будут вычислять локальное время по этой базе неправильно.
Т.е. даже после обновления базы часовых поясов в данной ситуации можно получить проблемы при работе с датами (а именно с датами в прошлом). А всё из-за того, что принципиальная ошибка заложена в сам принцип хранения часовых зон в виде плоского списка, актуального только на текущий момент времени.
Наиболее гибкое решение в этой ситуации — это ведение базы часовых поясов таким образом, чтобы она не просто хранила текущие правила расчёта локального времени в каждом регионе мира, а ещё и хранила историю изменений этих правил расчёта локального времени. Т.е. база должна «помнить» для каждого региона, в какой абсолютный момент времени какие правила расчёта локального времени действовали на этой территории, и в какой именно абсолютный момент времени эти правила заменились на другие. Зная корректные правила расчёта локального времени для всех регионов не только на текущий момент, но и на любой период в прошлом, можно точно проводить расчёты с использованием локального времени в любой исторический период.
Именно так устроена база tzdata (читать о tzdata подробнее), которая используется во многих *nix-системах (включая Linux, BSD, Mac OS X). И именно в этом её ключевое приемущество над другими форматами хранения информации о часовых поясах.
Разработчики Microsoft уже тоже ощутили ущербность хранения информации о часовых поясах в виде простого списка, актуального только на текущий момент времени. Например, если вы в системном реестре Windows [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones] раскроете разделы, соответствующие различным часовым поясам, то в некоторых из них вы увидите подраздел с именем «Dynamic DST». В нём как раз хранятся динамически изменяемые правила перехода на летнее время и обратно в зависимости от года (если в каком-то часовом поясе эти правила в последние годы менялись). Эту меняющуюся информацию о часовых поясах для разных лет они стали сохранять в реестре относительно недавно.
Но у меня всё равно нет уверенности в том, что всё ПО, которое использует базу часовых поясов из реестра Windows, корректно обрабатывает и эти изменения для разных лет.
Более того, в различных конференциях разработчиков уже появились жалобы на то, что после установки патча KB2570791 функции вычисления локального времени для дат в прошлом стали давать неверный результат. Вот для примера: раз и два.
В хабра-блоге Microsoft есть рекомендации для разработчиков:
habrahabr.ru/company/microsoft/blog/130629
Что делать?
Системным и прикладным администраторам, а также разработчикам и иным IT-специалистам следует заранее подготовить свои IT-системы, чтобы по возможности избежать проблем, связанных с изменением часовых зон.
Грамотно написанные IT-системы (приложения/сервисы/СУБД) обычно используют следующий подход к работе со временем:
1) Время везде (все записи в БД, события, логи, даты создания/изменения объектов и прочее) хранится только в абсолютных значениях Unix Time (количество секунд с начала Unix-эпохи, с 00:00:00 01.01.1970) или же в UTC.
2) Время обрабатывается (сравнивается, складывается, вычитается, сдвигается) только Unix Time (или в UTC).
3) Информация о часовом поясе, в котором следует представлять локальное время, хранится отдельно. Например, для представления пользователям информации в формате их местного времени часовой пояс берётся из профиля пользователя.
4) Отдельно ведётся и постоянно актуализируется база, хранящая информацию о правилах расчёта локального времени в разных регионах мира в разные периоды времени (например, база tzdata).
5) Имея точное время Unix Time (или в UTC), название локального часового пояса и базу с правилами расчёта локального времени для данного часового пояса, можно всегда безошибочно проводить расчёты для локального времени в любом регионе за любой период времени.
Для произведения любых действий с локальным временем оно сначала переводится Unix Time (или в UTC), согласно правилам исчисления локального времени в данном часовом поясе в данный период времени, и только потом обрабатывается. Если результат обработки следует представить в формате локального времени, то результат пересчитывается в локальное время указанной часовой зоны, согласно правилам исчисления локального времени в данном часовом поясе в данный период времени.
Точное время всех событий должен записывать не клиент, а именно сервер (в Unix Time или в UTC). Причём сервер должен иметь точное время с NTP-сервера (или иных источников синхронизации времени), а также должен иметь актуальную базу часовых поясов, чтобы проводить перерасчёты с локальным временем.
В мире unix-систем, использующих tzdata, обычно логика работы с локальным временем именно так и организована. Поэтому там будет достаточно обновить tzdata и ничего при этом не разъедется.
Но, к сожалению, далеко не все приложения и системы могут похвастаться такой грамотно выстроенной логикой работы со временем. Где-то могут быть свои костыли и велосипеды. А это значит, что далеко не везде изменение часовых зон пройдёт гладко.
Итого план действий в общих чертах такой:
- Изучить, какие есть обновления информации о часовых зонах для используемых у вас ОС, СУБД и прочего ПО. Ознакомиться с официальными рекомендациями по обновлению от производителей/поставщиков этого ПО.
- Если у ваших ОС и ПО есть оплаченная поддержка, то вам стоит обратиться в службу поддержки поставщика за официальными комментариями и рекомендациями по обновлениям, связанным с обновлением часовых зон (зря что ли вы им деньги платите за поддержку).
- Если вы разработчик и используете в своих приложениях и сервисах какие-то сторонние библиотеки/модули/базы часовых зон, то вам следует найти, скачать и установить обновления для этих сторонних библиотек/модулей*/баз.
- Если вы разработчик и самостоятельно реализовали в своих приложениях и сервисах базу часовых поясов (вместо того, чтобы использовать глобальную базу tzdata), то вам следует переписать свой «велосипед», чтобы внести туда соответствующие изменения.
- Для IT-специалистов очень желательно просматривать конференции и форумы разработчиков и администраторов используемых у вас программных решений. Полезно обмениваться опытом с коллегами, чтобы заранее знать о тех граблях, которые могут случиться в связи с обновлением часовых зон.
- После этого скачать и применить необходимые обновления ОС и ПО.
- Готовиться к возможным проблемам и думать, как их можно обойти.
* Например, по сообщению seriyPS, в Python для работы с временными зонами используется библиотека pytz. Последняя версия 2011k. Скрипт для просмотра текущей установленной версии pytz:
import pytz
print pytz.__version__
Для обновления библиотеки pytz:
sudo pip install -U pytz
или
sudo easy_install -U pytz
А что, если у нас точное времени синхронизируется с NTP или GPS?
Дело в том, что источники точного времени (NTP-сервер, GPS-приёмник, атомные часы) предоставляют точное абсолютное время (Unix Time). Оно в данном случае вообще никак не меняется и продолжает идти всё также равномерно и непрерывно. Вы его как раньше получали, так и продолжите получать без каких-либо разрывов и скачков по шкале времени. Источники точного времени для всех сообщают единое абсолютное время, они понятия не имеют о том кто, где и какие именно правила использует для получения из предоставленного ими абсолютного времени своего локального. Это вообще не забота источников точного времени, этим занимаются те системы/приложения, которые уже обрабатывают это время.
А вот уже если вашей ОС или ПО нужно работать с каким-либо локальным временем, тогда это абсолютное время (полученное от источника точного времени или самостоятельно отсчитываемое таймером компьютера) на стороне ОС или приложений пересчитывается в нужное локальное время (или обратно из локального в абсолютное). И для осуществления безошибочных вычислений и корректного пересчёта локального времени в ОС и ПО должна использоваться актуальная база мировых часовых поясов.
Т.е. независимо от того, синхронизируется ли ваш сервер с источником точного времени или нет, для правильной работы с часовыми поясами и локальным временем необходимо иметь обновлённую глобальную базу мировых часовых поясов. Т.е. наличие синхронизации с NTP никак не избавляет вас от забот по обновлению информации о часовых поясах для ваших IT-систем.
Обновление информации о часовых поясах (TZI, Time Zone Information) в различных ОС
Unix-системы и unix-подобные ОС
Разные коммерческие Unix-системы и свободные unix-like системы (GNU/Linux-дистрибутивы, BSD-системы и др.) используют различный формат хранения информации о мировых часовых зонах. Некоторые вендоры в рамках своего дистрибутива всё ещё самостоятельно ведут и поддерживают в актуальном состоянии эту информацию в своём самобытном формате (например, tztab в HP-UX).
Но всё же большинство unix-подобных систем в качестве единого глобального источника информации обо всех мировых тайм-зонах используют базу tzdata. Информация, собранная в tzdata, распространяется свободно для всех желающих без каких-либо лицензионных ограничений (public domain). Любой может свободно взять (как в исходниках, так и в бинарном виде) и использовать её в своих приложениях/библиотеках/сервисах. И многие разработчики/вендоры дистрибутивов ОС (в частности Linux/BSD/MacOS) и различного ПО именно так и делают.
В мире opensource база tzdata де-факто является стандартным источником информации обо всех мировых часовых поясах и истории их изменений. Базу tzdata используют все GNU/Linux-дистрибутивы, BSD-системы (FreeBSD, NetBSD, OpenBSD, DragonFly BSD), Solaris, UnixWare, AIX (6.1 и выше), Cygwin а также Mac OS X и некоторые другие unix-like дистрибутивы. Кроме того, данные из tzdata используется в ряде СУБД: MySQL, Oracle DB, PostgreSQL и др., а также в различных языках, фреймворках, библиотеках, модулях: PHP5, Perl (модули DateTime::TimeZone и DateTime::LeapSecond), Python (модуль pytz), GNU C Library (glibc), .NET Framework (модуль zoneinfo), Java Runtime Environment и др.
Официальная страница проекта tzdata: http://cs.ucla.edu/~eggert/tz/
Исходники tzdata и утилит для работы с часовыми поясами можно скачать здесь: ftp://elsie.nci.nih.gov/pub/ (FTP-сервер временно закрыт на время судебного разбирательства).
Зеркало со всеми файлами проекта tzdata: http://tzmirror.appealingapps.de, ftp://tzmirror.appealingapps.de
Ещё одно зеркало: ftp://munnari.oz.au/pub
Чтобы не перегружать эту статью, более подробную информацию о tzdata я вынес в отдельную статью.
На момент написания этой статьи последняя версия tzdata — это 2011l (вышла 10 октября 2011).
Изменения для новых часовых зон России появились в tzdata с версии 2011h, изменения для часовых поясов Украины и Белоруссии появились в tzdata с версии 2011k.
Поскольку парламент Украины уже успел откатить своё прежнее постановление об отмене сезонных переводов часов, получается, что tzdata-2011k и tzdata-2011l содержат ошибочную информацию о часовом поясе Украины (Europe/Kiev). Поэтому для Украины корректно будет использовать версию или более старую (2011j и ниже) или более новую (2011m и выше). Выход версии tzdata 2011m объявлен на 24 октября 2011, в эту версию должны быть внесены изменения для Украины (Europe/Kiev) и для Приднестровья (Europe/Tiraspol).
Таким образом, в *nix-системах для обновления информации о часовых поясах России и Белоруссии, изменившихся в 2011 году, необходимо установить соответствующее обновление, поставляемое вендором. Для большинства дистрибутивов, которые используют tzdata, для этого достаточно будет просто установить более новую версию пакета tzdata из стандартных репозиториев, портов и иных встроенных источников дистрибуции и обновления ПО, используемых в данном дистрибутиве ОС.
Разработчики многих дистрибутивов уже выпустили обновлённые пакеты tzdata для своих дистрибутивов. Если вы используете какой-либо Linux-дистрибутив, который вы регулярно обновляете из репозиториев, то скорее всего последняя версия пакета tzdata уже установлена у вас в системе.
Даты выхода нескольких недавних релизов tzdata на примере Ubuntu:
12 сентября 2011 — исходники tzdata обновились до версии 2011j;
14 сентября 2011 — пакет tzdata обновился до версии 2011j в апстриме Ubuntu (Debian Unstable);
20 сентября 2011 — пакет tzdata 2011j поступил в основной репозиторий Ubuntu;
26 сентября 2011 — исходники tzdata обновились до версии 2011k;
26 сентября 2011 — пакет tzdata обновился до версии 2011k в апстриме Ubuntu (Debian Unstable);
04 октября 2011 — пакет tzdata 2011k поступил в основной репозиторий Ubuntu;
10 октября 2011 — исходники tzdata обновились до версии 2011l (на момент написания статьи пакетов под Ubuntu ещё не было).
Как опциональный вариант, здесь можно найти пакеты tzdata для различных Linux-дистрибутивов:
pkgs.org/download/tzdata
В Linux-дистрибутивах с пакетными менеджерами можете просто посмотреть версию текущего установленного пакета tzdata.
В Debian/Ubuntu это можно сделать командой:
dpkg -s tzdata | grep Version
или
apt-cache policy tzdata
В Archlinux:
pacman -Si tzdata | grep Version
В CentOS/RHEL:
rpm -qa | grep tzdata
Если в выводе этой команды присутствует 2011h (или выше), значит в установленной версии tzdata уже учтены изменения 2011 года для часовых зон России.
Если в выводе этой команды присутствует 2011k (или выше), значит в установленной версии tzdata уже учтены изменения 2011 года для часовых зон не только России, но и Белоруссии.
Проверить, обновлена ли база tzdata в системе, можно экспериментальным способом:
- Берёте несколько тестовых дат в формате UTC (в прошлом и будущем, по разные стороны от ранее действовавших дат переключения DST).
- Через системную команду date вычисляете для этих тестовых дат локальное время в Москве, Киеве и Минске (при этом используется информация о тайм-зонах из базы tzdata, установленной в системе).
- Сравниваете вычисленное системой локальное время с тем, что должно быть на самом деле.
Для примера набросал скриптик, который это делает: pastebin.com/VEYt9BeN
(проверял под Linux, не знаю, работает ли под другими *nix-системами)
Он проверяет 5 тестовых дат:
1. 2010-10-01 15:00 UTC
2. 2010-11-01 15:00 UTC
3. 2011-10-01 15:00 UTC
4. 2011-11-01 15:00 UTC
5. 2012-07-01 15:00 UTC
Для локального времени Москвы должно получиться:
1. 2010-10-01 19:00 MSD (UTC+04)
2. 2010-11-01 18:00 MSK (UTC+03)
3. 2011-10-01 19:00 MSK (UTC+04)
4. 2011-11-01 19:00 MSK (UTC+04)
5. 2012-07-01 19:00 MSK (UTC+04)
Для локального времени Калининграда, Киева и Минска должно получиться:
1. 2010-10-01 18:00 EEST (UTC+03)
2. 2010-11-01 17:00 EET (UTC+02)
3. 2011-10-01 18:00 FET (UTC+03)
4. 2011-11-01 18:00 FET (UTC+03)
5. 2012-07-01 18:00 FET (UTC+03)
Если в вашей системе результат вычисления локального времени для этих городов получился другим, значит у вас в tzdata информация по этим регионам не обновлена.
aig сообщил: В FreeBSD можно обновить tzdata из портов:
#cd /usr/ports/misc/zoneinfo
#sudo make install clean
#sudo tzsetup
И установить зону заноово.
В Mac OS X текущую установленную версию tzdata можно посмотреть в файле +VERSION:
cat /usr/share/zoneinfo/+VERSION
В обновлении системы Mac OS X Lion 10.7.2 пакет tzdata обновился до версии 2011h.
Это значит, что информация о часовых зонах России там уже обновлена, а вот информация о часовой зоне Белоруссии ещё нет (для этого нужна минимум версия tzdata 2011k)
Если же вендор используемой вами Unix-системы не потрудился выпустить соответствующее обновление бинарных пакетов для TZI, то вам возможно придётся делать соответствующие изменения вручную. Например, самостоятельно компилировать tzdata с помощью zic (Zone Info Compiler) из последней версии исходников или копировать готовые скомпилированные zoneinfo-файлы с уже обновлённой системы.
Некоторые дополнительные сведения об обновлении tzdata в *nix-системах можно прочесть, например, здесь:
www.linux.org.ru/wiki/en/Неперевод_часов_2011
www.opennet.ru/tips/2630_linux_timezone_time.shtml
www.itpad.ru/?p=2257
Сетевое оборудование Cisco
Проверяем текущую конфигурацию тайм-зон на оборудовании Cisco:
7606#sh run |i clock timezone
clock timezone MSK 3
В выводе команд видим, какая тайм-зона указана для локального времени (в данном случае MSK) и какой сдвиг относительно UTC для неё действует (в данном случае UTC+3).
Теперь настраиваем правильную часовую зону для своего региона и отменяем сезонные переводы часов.
Cisco IOS (7206, 7600, GSR, ITP7200, ITP7200, ITP7600, AS5xxx, RPM-XF), IOS XR (ASR9k), IOS XE (ASR1k)
Выполнить команды:
no clock summer-time
clock timezone MSK 4
Первая команда отключает сезонные переводы часов (в частности для московского часового пояса удаляет из конфига строку «clock summer-time MSK recurring last Sun Mar 2:00 last Sun Oct 3:00»).
Вторая команда устанавливает текущую тайм-зону (в данном случае MSK) и текущий сдвиг времени относительно UTC (в данном случае UTC+4).
Для других регионов вместо MSK следует указать свой часовой пояс (например, NSK — для Новосибирска, VLAD — для Владивостока). Укажите здесь ту же зону, которая была при выводе текущей конфигурации таймзоны (см. выше).
Cisco CatOS (Catalyst 6500)
Выполнить команды:
set summertime disable
set timezone MSK 4
Первая команда отключает сезонные переводы часов.
Вторая команда устанавливает текущую тайм-зону (в данном случае MSK) и текущий сдвиг времени относительно UTC (в данном случае UTC+4).
Для других регионов вместо MSK следует указать свой часовой пояс (например, NSK — для Новосибирска, VLAD — для Владивостока). Укажите здесь ту же зону, которая была при выводе текущей конфигурации таймзоны (см. выше).
Подробнее про настройку времени в Cisco IOS см. здесь:
galushka.com/nastroyka-vremeni-na-cisco-otmenyaem-perehod-na-zimnee-letnee-vremya
Мобильные ОС
Android
В Android, как и во многих других linux-based системах, для хранения информации о мировых часовых поясах используется база tzdata. Файлы пакета tzdata на файловой системе Android OS расположены по пути:
/system/usr/share/zoneinfo/
. Версию tzdata можно посмотреть в файле zoneinfo.version
.Одновление tzdata в Android обычно происходит вместе с обновлением всей прошивки. На текущий момент ситуация с обновлением tzdata в Android-устройствах печальная. Даже в последней версии Android 2.3.6 (аппараты Nexus One, Nexus S) необходимых обновлений tzdata нет.
(Для сбора более полной статистики, пожалуйста, укажите в комментариях: а) модель вашего Android-устройства, б) версию Android, в) версию tzdata).
Про самостоятельное обновление tzdata (zoneinfo) на Android-устройствах (рутованных!) можно прочесть здесь:
androidforums.com/lg-optimus-one-p500/425466-time-zone-files-zoneinfo-tzdata.html
crazy-coder.livejournal.com/26142.html
habrahabr.ru/blogs/android/130808
forum.xda-developers.com/showpost.php?p=18370053&postcount=2
Приложение для обновления tzdata до версии 2011k есть в Android Market:
https://market.android.com/details?id=com.force.timezonefixer
Maemo/MeeGo
Здесь, как и в полноценных GNU/Linux-дистрибутивах используется tzdata.
wholeman сообщил:
Maemo5 (Fremantle), Nokia N900 — tzdata не обновлена.
Maemo6 (MeeGo 1.2 Harmattan), Nokia N9/N950 — tzdata обновлена
Для устройств с busybox'ом нужно использовать команду date -d 12221931.30 +%s и сравнивать результат с 1324567890
Apple iOS (iPhone/iPad)
Apple iOS тоже в качестве базы часовых поясов использует tzdata. Текущую установленную версию tzdata, как и в MacOS X, тут можно просмотреть в файле
/usr/share/zoneinfo/+VERSION
.Владельцы iPhone/iPad могут в комментариях отписаться о том, в какой версии iOS какая версия tzdata. Учитывая, что iOS 5 вышла совсем недавно, в октябре 2011, у меня есть надежда, что tzdata там достаточно актуальной версии.
Про самостоятельное обновление tzdata (zoneinfo) на iOS (нужен JailBreak) можно прочесть здесь:
habrahabr.ru/blogs/iphone/130432
BlackBerry OS
Компания RIM (Research In Motion) выпустила для BlackBerry обновление часовых поясов (KB28317 — September 2011 DST update).
Патч этот обновляет только 7 из 9 часовых зон России. А поддержки часовых зон Омское время (Asia/Omsk UTC+7) и Калининградское время (Europe/Kaliningrad UTC+3) в ПО BlackBerry в принципе нет, поэтому и обновления для этих зон у них тоже нет. Для часового пояса Белоруссии (Europe/Minsk UTC+3) там тоже нет обновлений. В этом смысле компания RIM довольно наплевательски относится к своим клиентам, живущим в разных часовых зонах по всему миру.
При наличии корпоративного BES (BlackBerry Enterprise Server) администраторам этого сервера необходимо установить обновление на этот сервер. Для этого:
1. Должно быть установлено обновление часовых поясов на ОС сервера, где стоит BES.
2. Должно быть установлено обновление часовых поясов на корпоративных почтовых серверах, с которыми интегрирован BES.
3. Нужно применить патч от RIM на сам BlackBerry Enterprise Server (обновление BES заключается по сути в применении SQL-скрипта, который вносит правки в SQL-базу данных BES).
Все корпоративные пользователи смартфонов BlackBerry, использующие подключение через BES, получат соответствующее обновление таймзон на свой BlackBerry-девайс уже с BES автоматически.
Частные пользователи смартфонов BlackBerry могут самостоятельно скачать обновление часовых поясов (KB28317). Для установки обновления нужно открывать эту ссылку с самого смартфона BlackBerry через встроенный браузер.
Symbian, WinMobile, WP7
Я не располагаю информацией о том, где и как хранят информацию о часовых поясах такие распространённые мобильные ОС, как Symbian, WinMobile 6.x и Windows Phone 7. Также я не знаю, как у них обстоят дела с обновлением этой информации. Буду рад услышать это от вас. Если кто-то в курсе, то прошу дополнить в комментариях.
awhiler сообщил, что на Windows Phone 7.5 информация о часовых поясах уже обновлена.
zlord сообщил, что Symbian 6.2 (Nokia 6120c) уже имеет обновлённую информацию о российских часовых зонах.
Про обновления устройств Nokia на базе Symbian можно узнать здесь:
www.nokia.ru/support/product-support/phone-software-update
MS Windows
В Windows информация о мировых часовых поясах хранится в системном реестре, в ветке
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones]
. Для часовых зон России и Белоруссии там есть следующие подразделы:Для России (с учётом обновлений 2011 года):
Kaliningrad Standard Time — (UTC+03:00) Калининград
Russian Standard Time — (UTC+04:00) Волгоград, Москва, Санкт-Петербург
Ekaterinburg Standard Time — (UTC+06:00) Екатеринбург
N. Central Asia Standard Time — (UTC+07:00) Новосибирск
North Asia Standard Time — (UTC+08:00) Красноярск
North Asia East Standard Time — (UTC+09:00) Иркутск
Yakutsk Standard Time — (UTC+10:00) Якутск
Vladivostok Standard Time — (UTC+11:00) Владивосток
Magadan Standard Time — (UTC+12:00) Магадан
Для Белоруссии (без учёта обновлений 2011 года):
E. Europe Standard Time — (UTC+02:00) Минск
Эту базу часовых поясов Microsoft поддерживает самостоятельно, т.е. они сами следят за полнотой и актуальностью этой базы. Изменения в эту базу обычно вносятся в виде патчей (обновлений для Windows), распространяемых через Windows Update.
Кумулятивный патч тайм-зон (KB2570791), включающий в себя обновления 2011 года для часовых поясов России, был выпущен компанией Microsoft 11 августа 2011 года:
support.microsoft.com/kb/2570791/en
support.microsoft.com/kb/2570791/ru
Патч предоставлен для версий Windows:
— Windows XP SP3 [x86, x64];
— Windows Server 2003 SP2 [x86, x64, Itanium];
— Windows Vista SP2 [x86, x64];
— Windows Server 2008 SP2 [x86, x64, Itanium];
— Windows 7 [x86, x64];
— Windows Server 2008 R2 [x64, Itanium];
— Windows Embedded Standard 7 [x86, x64].
Для Windows 2000 Professional/Server патч не был выпущен (и не будет), т.к. Win2k снята с поддержки Microsoft.
С 23-го августа 2011 года этот патч (KB2570791) поступил в Windows Update.
Если ваши Windows-системы обновляются автономно через интернет-сервис Windows Update, то они уже должны были получить это обновление. Если ваши Windows-системы обновляются централизовано через WSUS-сервер в корпоративной сети, до администраторам WSUS следует заапрувить это обновление на WSUS, тогда оно тоже придёт на все серверы и рабочие станции вашей организации.
Если же автоматическое обновление Windows в вашей организации не используется (ну мало ли), то вы можете самостоятельно скачать этот патч с сайта Microsoft (см. ссылку на статью выше) и установить его по всем Windows-машинам (вручную поштучно, скриптом, через групповые политики или через SMS/SCCM).
Данный патч просто делает соответствующие изменения в ключе системного реестра [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones], более никаких изменений патч в систему не вносит. После применения патча (KB2570791) перезагрузка системы не требуется.
Чтобы визуально убедиться, что данный патч установлен, можно заглянуть в системные настройки часовых поясов. Сдвиг часового пояса относительно UTC должен стать на час больше, чем раньше (например, для Москвы: был UTC+3, а стал UTC+4), а также должен пропасть чекбокс, включающий переход на летнее время.
Вот скриншот из Win2008-R2 после установки патча KB2570791 (на примере Москвы):
Вот скриншот из Win2003 (анимация: до и после установки патча KB2570791 на примере Москвы):
Обновление устаревших Windows-систем
По своему опыту работы в крупных организациях я знаю, что чем крупнее и бюрократичнее организация, тем медленнее там идут все переходные процессы, и тем медленнее обновляется парк операционных систем. Поэтому в крупных организациях на части старых десктопов Windows 2000 Professional всё ещё продолжает успешно работать. Плюс ещё Win2k Server может кое-где жить и на старых серверах, на которых администраторы не торопятся апгрейдить ОС из вполне практичных соображений: «Оно работает? Не трогай его!».
Если в вашей организации представлены в том числе и Win2k-машины, то вам следует задуматься и об обновлении часовых поясов на них (по крайней мере на десктопах).
Как уже было сказано выше, патч KB2570791 для Windows 2000 не вышел.
Но патч KB2570791 только редактирует информацию о часовых поясах в системном реестре Windows. А формат хранения этой информации в реестре Win2k ничем не отличается от формата хранения этой информации в реестре WinXP или Win2k3. Поэтому чисто технически ничто не мешало Microsoft выпустить этот патч в том числе и для Win2k, причём без лишних трудозатрат. Однако Microsoft уже отказалась от поддержки Win2k, поэтому уже из принципа не выпускает для неё обновления, даже если им это ничего не стоит. Это означает, что машины с Win2k вам придётся обновлять своими силами.
Для этого достаточно:
— применить патч KB2570791 на WinXP или Win2k3;
— экспортировать из реестра пропатченной системы ветку [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones];
— взять оттуда только изменения, касающиеся часовых поясов России (хотя можно обновить информацию и вообще о всех мировых таймзонах, не отбирая только российские таймзоны);
— сохранить эти изменения в виде *.reg-файла;
— импортировать подготовленный *.reg-файл в реестр на Win2k-машинах (вручную поштучно, скриптом, через групповые политики или через SMS/SCCM).
Можно подготовить несколько подобных *.reg-файлов для разных локалей Windows (Русская, Английская), а можно особо не париться и везде применять *.reg-файл, сделанный на основе англоязычной Windows. Ничего страшного, если даже на русскоязычной системе в настройках часовых поясов отображаемое имя некоторых поясов будет выглядеть на английском языке.
Готовые reg-файлы (под русскую и английскую локаль) с правками для российский часовых зон можно скачать здесь:
* Для англоязычных Windows: pastebin.com/FRXwDM0u
* Для русскоязычных Windows: pastebin.com/mKe3GMVU
После импорта в реестр информации о новых российских часовых зонах следует заново указать системе текущий часовой пояс, чтобы обновлённая информация о нём заново перечиталась из реестра. В зависимости от часовой зоны в данном регионе делается это под Win2k/XP/2003 одной из команд:
Для регионов с Калининградским временем (MSK-1):
control.exe timedate.cpl,,/z Kaliningrad Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time
Для регионов с Московским временем (MSK):
control.exe timedate.cpl,,/z Russian Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time
Для регионов с Екатеринбургским временем (MSK+2):
control.exe timedate.cpl,,/z Ekaterinburg Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Ekaterinburg Standard Time
Для регионов с Омским временем (MSK+3):
control.exe timedate.cpl,,/z N. Central Asia Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z N. Central Asia Standard Time
Для регионов с Красноярским временем (MSK+4):
control.exe timedate.cpl,,/z North Asia Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z North Asia Standard Time
Для регионов с Иркутским временем (MSK+5):
control.exe timedate.cpl,,/z North Asia East Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z North Asia East Standard Time
Для регионов с Якутским временем (MSK+6):
control.exe timedate.cpl,,/z Yakutsk Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Yakutsk Standard Time
Для регионов с Владивостокским временем (MSK+7):
control.exe timedate.cpl,,/z Vladivostok Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Vladivostok Standard Time
Для регионов с Магаданским временем (MSK+8):
control.exe timedate.cpl,,/z Magadan Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time
Соответственно пакетный командный файл для обновления часовых зон на Win2k-компьютере в европейской части России может выглядеть так:
regedit /s TZ-update-Russia2011.reg
control.exe timedate.cpl,,/z Russian Standard Time
или так:
regedit /s TZ-update-Russia2011.reg
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time
где TZ-update-Russia2011.reg — это REG-файл с настройками часовых зон России (см. выше)
Причём при распространении этого скрипта через доменные групповые политики следует использовать именно второй вариант (черен RunDLL32.exe shell32.dll).
Имейте в виду, что Win2k обновляет информацию о текущем часовом поясе не сразу же, а в начале каждой минуты. Поэтому изменения от этой команды подействуют не мгновенно, а с некоторой задержкой (не более 1 минуты).
Что касается обновления WinXP (менее SP3) и Win2k3 (менее SP2), то на них выпущенный Microsoft патч, вероятно, тоже не встанет. Поэтому, если вы их не хотите по какой-то причине обновлять до последнего сервис-пака, то ставить на них обновления часовых зон России тоже придётся через импорт изменений в реестр (по аналогии с Win2k).
Особенности перенастройки часовых зон в Windows для разных регионов
Чукотка, Камчатка
Разработчики Microsoft долгое время считали, что на Камчатке у нас нет летнего времени (хотя в действительности там, как и на территории всей России/СССР, переход на летнее время применялся с 1981 по 2009 год, а в конце марта 2010 года сам этот Камчатский часовой пояс прекратил своё существование). Из этих ошибочных соображений об отсутствии там DST Камчатку они поместили в один часовой пояс с Фиджи (где перехода на летнее время действительно не было):
Fiji Standard Time — (UTC+12:00) Петропавловск-Камчатский, Фиджи [no DST]
Соответственно у пользователей Windows из регионов, где у нас использовалось Камчатское время, (Чукотка, Камчатка) в настройках часовых зон галочка перехода на летнее время не просто была снята, а там вообще сам этот чекбокс для Камчатского пояса отсутствовал. И обычными штатными настройками часовых поясов влючить летнее время там было нельзя.
Исправление (KB970653) этого бага вышло только в августе 2009 года.
В этом исправлении Камчатку удалили из пояса «Fiji Standard Time» и сделали для неё отдельный пояс «Kamchatka Standard Time», т.е. после этого патча в Windows появились два отдельных пояса:
Fiji Standard Time — (UTC+12:00) Фиджи [no DST]
Kamchatka Standard Time — (UTC+12:00) Петропавловск-Камчатский [with DST]
Из-за того, что в Windows очень долгое время не было нормального часового пояса для Чукотки и Камчатки (с поддержкой летнего времени), пользователям и администраторам в этих регионах приходилось выкручиваться самостоятельно. До появления патча KB970653 наиболее удобным решением было редактирование в системном реестре информации о часовом поясе «Fiji Standard Time», чтобы добавить в этот пояс галку перехода на летнее время и включить её.
В конце марта 2010 года в России упразднили Камчатский часовой пояс, все регионы из него перешли в Магаданский часовой пояс. Но и там эта проблема не была решена (см. ниже).
Магадан
Также разработчики Microsoft долгое время считали, что и в Магадане у нас тоже нет летнего времени (хотя в действительности там, как и на территории всей России/СССР, переход на летнее время применялся с 1981 по 2011 год). Из этих ошибочных соображений об отсутствии там DST Магадан они поместили в один часовой пояс с Соломоновыми островами, и Новой Каледонией (где перехода на летнее время действительно не было):
Central Pacific Standard Time — (UTC+11:00) Магадан, Соломоновы о-ва, Новая Каледония [no DST]
Соответственно у пользователей Windows из регионов, где у нас использовалось магаданское время, (сначала это только Магаданская область и восточные районы Якутии, а с конца марта 2010 к ним присоединились ещё и Чукотка с Камчаткой) в настройках часовых зон галочка перехода на летнее время не просто была снята, а там вообще сам этот чекбокс для Магаданского пояса отсутствовал. И обычными штатными настройками часовых поясов влючить летнее время там было нельзя.
Исправление (KB2443685) этого бага вышло только в декабре 2010 года.
В этом исправлении Магадан удалили из пояса «Central Pacific Standard Time» и сделали для него отдельный пояс «Magadan Standard Time», т.е. после этого патча в Windows появились два отдельных пояса:
Central Pacific Standard Time — (UTC+11:00) Соломоновы о-ва, Новая Каледония [no DST]
Magadan Standard Time — (UTC+11:00) Магадан [with DST]
Из-за того, что в Windows очень долгое время не было нормального часового пояса для Магадана (с поддержкой летнего времени), пользователям и администраторам в регионах с Магаданским временем приходилось выкручиваться самостоятельно. До появления патча KB2443685 наиболее удобным решением было редактирование в системном реестре информации о часовом поясе «Central Pacific Standard Time», чтобы добавить в этот пояс галку перехода на летнее время и включить её.
Если новые инсталляции Windows ставились уже после выхода патча KB2443685, то там администраторы после применения этого патча обычно уже выбирали правильный и исправленный разработчиками часовой пояс: Magadan Standard Time — (UTC+11:00) Магадан [with DST].
Но вот на большинстве Windows-систем, которые были установлены до декабря 2010, хоть после применения патча KB2443685 в списке часовых поясов и появился скорректированный магаданский часовой пояс: Magadan Standard Time — (UTC+11:00) Магадан [with DST], но вот в качестве текущего до сих пор выбран исправленный самостоятельно «Central Pacific Standard Time» с добавленным туда DST.
Таким образом, теперь при очередном исправлении российских часовых зон (KB2570791) на всех Windows-компьютерах, находящихся в регионах с Магаданским временем (Чукотка, Камчатка, Магаданская область, Северные Курилы, восточные районы Якутии) нужно будет убедиться, что в качестве текущего часового пояса выбрано именно магаданское время. А иначе этим патчем часовая зона для Магадана будет исправлена, только это не даст никакого эффекта, т.к. в истеме в качестве текущей выбрана совсем другая часовая зона.
Сделать это можно как до применения патча KB2570791 (при условии, что патч KB2443685 уже был ранее установлен), так и после. Сделать это можно как вручную, так и автоматизировать это с помощью скриптов или через SMS/SCCM. Для автоматизации можно использовать следующие консольные команды:
В Win2k Магаданский часовой пояс можно выбрать консольной командой:
control.exe timedate.cpl,,/z Magadan Standard Time
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time
В WinXP/2003 Магаданский часовой пояс можно выбрать консольной командой:
tzchange /c "Magadan Standard Time"
Или точно так же, как в Win2k:
control.exe timedate.cpl,,/z Magadan Standard Time
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Magadan Standard Time
В Win7/2008-R2 Магаданский часовой пояс можно выбрать консольной командой:
tzutil /s "Magadan Standard Time"
В WinVista/2008 я не нашёл встроенных консольных утилит для изменения текущего часового пояса, но здесь работает утилита tzutil.exe, позаимствованная из Win7 или Win2008-R2.
Сахалинская область и Якутия
Обратите внимание, что эти два региона (субъекта РФ) расположены не полностью в рамках одной часовой зоны. Часть районов расположена в одной часовой зоне, а часть в другой.
Так в Сахалинской области две часовых зоны: в Северо-Курильском районе — Магаданское время (UTC+12, MSK+8); в остальных районах Сахалинской области — Владивостокское время (UTC+11, MSK+7).
А в Якутии вообще три часовых зоны: Якутское время (UTC+10, MSK+6), Владивостокское время (UTC+11, MSK+7), Магаданское время (UTC+12, MSK+8). Точное распределение районов Якутии по этим часовым зонам см. в Постановлении Правительства №725.
Граница между часовыми зонами внутри Сахалинской области таким образом была установлена уже ранее. А вот внутри Якутии граница между часовыми зонами была изменена этим Постановлением Правительства №725.
Если вдруг у вас в этих регионах есть IT-инфраструктура, то будьте внимательны при выборе часовой зоны.
Самара, Ижевск (Удмуртия)
Для этих регионов России в Windows долгое время вообще не было отдельного часового пояса. Поэтому Windows-пользователям/администраторам в этих регионах приходилось искать обходные пути и выбирать в настройках времени часовой пояс соседних государств (обычно Армению/Ереван или Азербайджан/Баку), в которых использовалось аналогичное исчисление времени. В конце марта 2010 часовой пояс с Самарским временем (MSK+1) вообще упразднили, присоединив Самарскую область и Удмуртию к московскому времени. И сейчас по-хорошему во всех Windows-системах в этих регионах должно быть выбрано московское время.
Но остатки старых извращений с выбором иностранных часовых зон могли ещё где-то сохраниться в настройках некоторых Windows-машин. Поэтому на всякий случай проверьте и при необходимости замените везде время на московское. Можно вручную, а можно опять же заскриптовать и автоматизировать, используя для выбора Московской часовой зоны консольные команды:
xp,2003:
tzchange /c "Russian Standard Time"
2k,xp,2003:
control.exe timedate.cpl,,/z Russian Standard Time
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Russian Standard Time
WinVista/2008:
tzutil /s "Russian Standard Time"
(tzutil.exe скопировать из Win7/2008-R2)Win7/2008-R2:
tzutil /s "Russian Standard Time"
Калининград
Отдельного часового пояса для Калининградской области в Windows раньше не было, поэтому в настройках часовых зон в Калининграде обычно выбирали какой-то европейский часовой пояс, соответствующий местному времени, например:
FLE Standard Time — (UTC+02:00) Вильнюс, Киев, Рига, София, Таллин, Хельсинки
E. Europe Standard Time — (UTC+02:00) Минск
GTB Standard Time — (UTC+02:00) Афины, Бухарест
Теперь же в обновлении KB2570791 в Windows для Калининграда добавили свой отдельный часовой пояс (без DST):
Kaliningrad Standard Time — (UTC+03:00) Калининград
Но после применения данного патча этот новый часовой пояс для Калининграда просто добавится в список часовых поясов, а выбран в качестве текущего он автоматически не будет. Поэтому после (обязательно после!) применения патча KB2570791 на Windows-компьютерах в Калининграде там нужно будет дополнительно в настройках часовых поясов выбрать для системы калининградское время. Можно это сделать вручную, а можно опять же заскриптовать и автоматизировать, используя для выбора Калининградской часовой зоны консольные команды:
xp,2003:
tzchange /c "Kaliningrad Standard Time"
2k,xp,2003:
control.exe timedate.cpl,,/z Kaliningrad Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time
WinVista/2008:
tzutil /s "Kaliningrad Standard Time"
(tzutil.exe скопировать из Win7/2008-R2)Win7/2008-R2:
tzutil /s "Kaliningrad Standard Time"
Белоруссия
Что касается изменения часового пояса в Белоруссии, то компании Microsoft известно об этом, но они сейчас не будут выпускать для времени в Белоруссии соответствующий Windows-патч. Им, видимо, лень напрягаться и выбиваться из планового графика кумулятивных апдейтов. Изменения тайм-зон для Украины, Белоруссии и Армении они планируют включить в очередное кумулятивное обновление часовых поясов Windows, которое выйдет в декабре 2011. Но пока непонятно, будут ли к тому моменту какие-либо законодательные решения об этом в Армении и Украине. А до тех пор компания Microsoft предлагает своим Windows-польльзователям из Белоруссии
1) Установить патч KB2570791, который меняет тайм-зоны России.
2) Для пользователей из Белоруссии в качестве своего часового пояса выбрать: (UTC +3:00) Kaliningrad
А после того, как в декабре 2011 года выйдет очередной кумулятивный WinUpdate тайм-зон, в котором они наконец сделают исправление часового пояса для Белоруссии (а возможно для Украины и Армении тоже), они предлагают всем пользователям из Белоруссии установить этот апдейт, а потом опять же вручную в настройках системного времени вернуть часовой пояс на родной (уже испроавленный) для своей страны.
Это вовсе не моя выдумка, вот официальная статья от Microsoft, в которой об этом написано:
support.microsoft.com/kb/2625508/en
support.microsoft.com/kb/2625508/ru
Установку Калининградского времени (после патча KB2570791) для Белоруссии можно сделать вручную, а можно опять же заскриптовать и автоматизировать, используя для выбора Калининградской часовой зоны консольные команды:
xp,2003:
tzchange /c "Kaliningrad Standard Time"
2k,xp,2003:
control.exe timedate.cpl,,/z Kaliningrad Standard Time
или
RunDLL32.exe shell32.dll,Control_RunDLL timedate.cpl,,/z Kaliningrad Standard Time
WinVista/2008:
tzutil /s "Kaliningrad Standard Time"
(tzutil.exe скопировать из Win7/2008-R2)Win7/2008-R2:
tzutil /s "Kaliningrad Standard Time"
Обновление часовых зон на контроллерах домена MS Active Diectory
Нужно просто установить патч KB2570791 на серверы контроллеров домена, как и на любые другие Windows-машины. Чтобы на контроллерах домена не было различий, желательно установить это обновление на все контроллеры AD-леса в один день.
С обновлением контроллеров есть один известный мне баг. Если в вашей организации по каким-то параноидальным требованиям безопасности для пользователей установлено ограничение по времени входа в систему (Logon Hours) и соответственно у ваших пользователей есть заполненный атрибут logonHours, то сразу после установки апдейта KB2570791 на контроллеры домена у всех пользователей диапазоны разрешённого входа в систему сместятся на час. Эту проблему вы почувтсвуете не после 30 октября, а непосредственно сразу после патча контроллеров.
Например, если разрешённое время входа у ваших пользователей было установлено диапазоном с 9 до 18 часов, то после патча контроллеров домена пользователям будет разрешено логиниться уже с 10 до 19 часов. Т.е. пользователи, которые с таким ограничением придут на следующее утро на работу уже не смогут войти в систему пока администратор не уберет это ограничение или пока не наступит 10 часов утра.
Причём этот интервал разрешённого логона будет сдвигаться только на тех контроллерах, где был установлен патч KB2570791. И если у вас на одних контроллерах этот патч был установлен, а на других ещё нет, то может так получиться, что одни пользователи смогли залогиниться (т.к. при логоне попали на непропатченный контроллер), а другие не смогли (т.к. при логоне попали на уже пропатченный контроллер), хотя изначально разрешения на время логона у них стояли одинаковые. Это обстоятельство может несколько затруднить вам диагностику проблемы.
Поэтому прежде, чем устанавливать патч KB2570791 на контроллеры домена, нужно оценить, как много пользователей в вашем домене имеют ограничение времени логона в систему. Для этого можно выгрузить в файл список пользователей с их logonHours и изучить его. Пример PowerShell-скрипта для выгрузки пользователей с атрибутом logonHours: pastebin.com/0Ucu7MKi
Если таких пользователей нет, то всё ОК, все контроллеры можно безболезненно патчить. Если такие пользователи в AD есть, то проблему с ними нужно как-то решать. Очевидных варианта два:
1) Отказаться от этих ограничений на время входа и у всех пользователей заполнить атрибут logonHours, чтобы там не было ограничений на время входа (можно скриптом);
2) Написать скрипт, который у всех пользователей будет сдвигать все диапазоны logonHours на один час назад, и запустить этот скрипт сразу после патча всех контроллеров домена.
Обновление часовых зон на MS Exchange-серверах
С хранением информации о часовых поясах в почтовой системе Exchange вообще творится какой-то бардак.
Наиболее ожидаемая проблема с почтовой системой Exchange при данном изменении часовых зон — это рассинхронизация календарных событий в различных календарях. Допустим, деловая встреча совета директоров назначена на 10 часов, но один из участников её увидел в своём календаре в 9 часов (и пришёл на час раньше), другой увидел её в своём календаре в 10 часов (и пришёл вовремя), а третий увидел её в своём календаре в 11 часов (и опоздал на час).
Например, разовые события, добавляемые в календарь, и регулярно повторяющиеся события (например, ежегодные) хранятся в почтовой базе Exchange в различных форматах: в одном случае часовая зона хранится вместе с указанным временем, а в другом случае не хранится. И при изменении часовых зон это будет иметь значение.
Ещё при доступе к одному и тому же календарю через MS Office Outlook и через OWA (Outlook Web Access) можно увидеть разные данные, т.к. у OWA какой-то свой взгляд на информацию о часовых поясах.
Плюс на корректность отображения календарных событий в разных календарях могут повлиять и другие факторы:
— какие версии Outlook стоят на компьютерах отправителя и получателя;
— почтовый ящик хранится на сервере в почтовой базе или локально в PST-файле;
— пропатчены или нет Windows-системы на обоих компьютерах отправителя и получателя;
— в одной ли часовой зоне находятся отправитель и получатель;
— до установки патча или после создано календарное событие;
— пропатчены или нет Windows-системы на Exchange mailbox-серверах, на которых размещены ящики отправителя и получателя;
и т.д.
Причём в большинстве случаев проблем с рассинхронизацией календарных событий может и не быть, но при некоторой комбинации обозначенных выше факторов некоторые события в разных календарях могут и разъехаться по времени.
Например, если сейчас пользователь с Windows-машины без установленного апдейта KB2570791 назначит в своём календаре встречу, допустим, на 1 ноября 2011 (или на другой день после 30 октября 2011) с 10:00 до 11:00, а потом отправит приглашение на эту встречу пользователю, у которого на Windows-машине уже стоит патч KB2570791, то отправитель и получатель в своих календарях будут видеть это событие в разное время. У отправителя с 10:00 до 11:00, а у получателя с 11:00 до 12:00, поэтому он рискует опоздать на эту встречу.
И наоборот, если создавать встречу на дату после 30 октября на пропатченной машине и отправлять приглашение пользователю на непропатченной машине, то сдвиг времени на час будет уже в обратную сторону. Самое неприятное здесь то, что отправитель и получатель календарных событий могут быть вообще из разных организаций. А значит установить патчи на обе их машины у вас просто может не быть никакой технической возможности (вам может быть подконтролен компьютер только одного из этих пользователей).
По заявлениям Microsoft, вопрос хранения информации о часовых поясах более менее причесали в Exchange 2010, а вот при использовании Exchange 2003 и Exchange 2007 вполне возможны обозначенные проблемы с рассинхронизацией календарных событий. Причём срузу после установки патча KB2570791 на рабочие станции клиентов и на Exchange-серверы проблемы могут и не появиться, а вот после того, как 30 октября 2011 непропатченные Windows-системы сдвинут на час назад время, вот тогда и возможны такие проблемы с календарями.
Поддержка Microsoft не даёт однозначного ответа о том, как заранее гарантировано обезопасить свою почтовую систему Exchange от подобных проблем, но их рекомендации следующие:
1. Установить патч KB2570791 на все клиентские Windows-машины;
2. Установить патч KB2570791 на все Exchange-серверы организации и на все контроллеры домена;
3. Если у вас есть серверы Exchange 2007 (SP3), то установить на них Update Rollup 5;
4. Далее наблюдать и выявлять проблемы с календарными событиями у пользователей.
5. Если пользователи будут жаловаться на сдвиг календарных событий в своих календарях, тогда:
а) либо на серверной стороне запускать Exchange Calendar Update Tool, чтобы пофиксить календари на конкретных серверах для конкретных проблемных пользователей;
б) либо на клиентской стороне запускать Outlook Time Zone Data Update Tool, чтобы пофиксить календари на стороне Outlook.
Обновление часовых зон на MS Sharepoint-серверах
На серверы с MS SharePoint, во-первых, следует установить обновление Windows KB2570791, а во-вторых, установить обновление для самого SharePoint:
— обновление для MS SharePoint 2007 (SharePoint Serveces 3.0);
— обновление для MS SharePoint 2010.
Также смотри информацию про обновления часовых зон для продуктов Microsoft здесь:
support.microsoft.com/gp/cp_dst/ru
support.microsoft.com/gp/cp_dst/en
Когда нужно обновить информацию о часовых зонах в ОС и ПО?
Формально в России и Белоруссии уже действует новое исчисление времени в часовых зонах (см. принятые законы). Поэтому все обновления ОС/ПО, связанные с этим, уже можно и даже нужно делать. Причём провести все работы по обновлению часовых зон нужно постараться до 30 октября 2011. Потому как системы с необновлённой информацией о новых часовых зонах 30 октября (последнее воскресенье октября) попытаются вернуться с летнего времени на стандартное (т.к. не знают, что переходы уже отменены), и это может вызвать проблемы (как минимум проблемы с некорректным отображением местного времени).
До времени Ч осталась всего-то пара рабочих недель. Поэтому не откладывайте эти работы в долгий ящик. Ещё раз внимательно просмотрите своё IT-хозяйство (серверы, приложения, сервисы и прочее), спланируйте и проведите работы, чтобы обновить информацию о часовых зонах везде, где можно.
Остаётся только надеяться, что эти проблемы не затронут системы вашей компании уровня BC (Business Critical) и MC (Mission Critical). Например, если ваши бизнес завязан на системах биллинга или каких-то точных финансовых рассчётах, имеющих привязку к локальному времени (как в настоящем, так и в прошлом), то возникшие проблемы со временем могут вызвать для вас вполне конкретные бизнес-потери.
Затрагивание некритичных систем уровня OP (Office Productivity), типа сдвига на час некоторых календарных событий в Outlook, с точки зрения бизнеса обычно несущественно.
Паниковать, конечно, не стоит, но будьте готовы к тому, что проблемы, связанные с изменением часовых зон, в каких-то IT-системах очень вероятны. Если не сразу после применения вами патчей/фиксов, то с 30 октября 2011 уж наверняка.
Также см. другой топик на тему изменения часовых зон в России:
Переезд временной зоны MSD в MSK — новый Y2K локального масштаба
|
Автор статьи: Роман Тик <ya.roman.tik {аt} yandex.ru> Текст статьи распространяется на условиях лицензии «Creative Commons Attribution 3.0 Unported» (CC BY 3.0). Вы можете свободно копировать, редактировать и использовать в любых целях этот текст при обязательном указании авторства. |