Содержание
Так «летнее» или «зимнее» время отменили?
Законодательные основы для изменения исчисления времени
Какое время будет в новых часовых поясах?
Список часовых зон России
Состав территорий РФ, образующих часовые зоны РФ
Часовые пояса Украины и Белоруссии
А что с летним временем в других странах?
Целесообразность использования летнего времени
Какие могут быть проблемы из-за изменения часовых зон?
Что делать?
А что, если у нас точное времени синхронизируется с NTP или GPS?
Обновление информации о часовых поясах (TZI, Time Zone Information) в различных ОС
Unix-системы и unix-подобные ОС
Сетевое оборудование Cisco
Мобильные ОС
MS Windows
Обновление устаревших Windows-систем
Особенности перенастройки часовых зон в Windows для разных регионов
Чукотка, Камчатка
Магадан
Сахалинская область и Якутия
Самара, Ижевск (Удмуртия)
Калининград
Белоруссия
Обновление часовых зон на контроллерах домена MS Active Diectory
Обновление часовых зон на MS Exchange-серверах
Обновление часовых зон на MS Sharepoint-серверах
Когда нужно обновить информацию о часовых зонах в ОС и ПО?
Так «летнее» или «зимнее» время отменили?
Законодательные основы для изменения исчисления времени
В России данные изменения введены* Постановлением Правительства РФ от 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 offsetDSTМеждунар. названиеМеждунар. аббрев.1Московское время -1UTC+03:00-Kaliningrad TimeUSZ1, FET (MSK-1)2Московское времяUTC+04:00-Moscow TimeMSK3Московское время +2UTC+06:00-Yekaterinburg TimeYEKT (MSK+2)4Московское время +3UTC+07:00-Omsk TimeOMST (MSK+3)5Московское время +4UTC+08:00-Krasnoyarsk TimeKRAT (MSK+4)6Московское время +5UTC+09:00-Irkutsk TimeIRKT (MSK+5)7Московское время +6UTC+10:00-Yakutsk TimeYAKT (MSK+6)8Московское время +7UTC+11:00-Vladivostok TimeVLAT (MSK+7)9Московское время +8UTC+12:00-Magadan TimeMAGT (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+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 и далее этого уже делать не будут.
В России, Белоруссии, Северной Осетии и Абхазии эти изменения в часовые пояса уже вступили в силу и действуют уже сейчас.
А что с летним временем в других странах?
Целесообразность использования летнего времени
Споры о целесообразности перехода на летнее время ведутся давно. Изначально сдвиг времени на час в летний период вводился с целью более эффективного использования светового дня и экономии электроэнергии, затрачиваемой на освещение улиц и домов в вечерние часы. И это действительно давало ощутимый экономический выигрыш лет 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-систем
По своему опыту работы в крупных организациях я знаю, что чем крупнее и бюрократичнее организация, тем медленнее там идут все переходные процессы, и тем медленнее обновляется парк операционных систем. Поэтому в крупных организациях на части старых десктопов 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 для разных регионов
Обновление часовых зон на контроллерах домена 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 уж наверняка.