![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
abbraВ мире постоянно происходят изменения в законодательствах разных стран и некоторые изменения при всей своей "некомпьютерности" затрагивают не только подданных этих стран, но и все остальных. Так, в 2005 году правительство США приняло акт об экономии энергоресурсов, в рамках которого изменились даты перевода часов на зимнее и летнее время, начиная с 2007 года.
Не нужно думать, что раз это изменение происходит в США или Зимбабве, или еще какой стране, оно нас не касается. Напротив, касается напрямую, ведь многие серверы установлены в США, почта приходит отовсюду, а для бизнес-приложений утечка времени вообще крайне вредна. Так что от того, что CST из GMT-6 станет GMT-7, может пострадать значительно больше, чем может показаться. К тому же, изменения в США -- не единственные, в этом году нас коснутся изменения в Канаде и западной Австралии. В последней, кстати, это сделано, чтобы не разрывать Игры Содружества и для тестирования перевода часов на зимнее/летнее время, сроком на три года.
Однако основная проблема вовсе не в том, что изменения происходят постоянно. Проблема, как отметил недавно Ульрих Дреппер из glibc и RedHat, в том, что отсутствует единство в представлении информации о временных зонах и часовых поясах в разных компонентах информационных систем. Так, большинство "правильно" написанного программного обеспечения в POSIX-совместимых средах использует функции системной библиотеки libc, в которой база данных часовых поясов достаточно легко обновляется независимо от самой системы и имеет стабильный формат. Однако различные реализации Java не опираются на системные возможности по обработке времени, они таскают за собой свои базы данных часовых поясов. Обновление такой базы для старой версии Java может выглядеть вообще заменой старого интерпретатора на новый, с которым может не работать приложение, это еще цветочки...
Дальше -- больше. В базах данных время может храниться в разном формате, зачастую без указания часового пояса. Ладно, с типовыми веб-приложениями в этой области более-менее разобрались, профили пользователей во всевозможных форумах имеют специальную настройку "часовой пояс", которая используется для корректного отображения даты, а сама дата хранится в UTC, что уже не плохо.
Хуже всего в Windows. Например, Exchange внедряет информацию о временных зонах в создаваемые события, что требует переписывания всей информации в базе данных при изменении часовых поясов. Кстати, таких изменений не так и мало -- по утверждению Дреппера, в мире в год происходит в среднем порядка 20 локальных изменений в порядке вычисления часовых поясов.
Что касается GNU/Linux, то здесь ситуация такая:
Уф. На последок, аналогичные статьи от Microsoft: Visual Studio, обновления для Windows XP, 2003 и базовый Центр помощи при смене часовых поясов.
Не нужно думать, что раз это изменение происходит в США или Зимбабве, или еще какой стране, оно нас не касается. Напротив, касается напрямую, ведь многие серверы установлены в США, почта приходит отовсюду, а для бизнес-приложений утечка времени вообще крайне вредна. Так что от того, что CST из GMT-6 станет GMT-7, может пострадать значительно больше, чем может показаться. К тому же, изменения в США -- не единственные, в этом году нас коснутся изменения в Канаде и западной Австралии. В последней, кстати, это сделано, чтобы не разрывать Игры Содружества и для тестирования перевода часов на зимнее/летнее время, сроком на три года.
Однако основная проблема вовсе не в том, что изменения происходят постоянно. Проблема, как отметил недавно Ульрих Дреппер из glibc и RedHat, в том, что отсутствует единство в представлении информации о временных зонах и часовых поясах в разных компонентах информационных систем. Так, большинство "правильно" написанного программного обеспечения в POSIX-совместимых средах использует функции системной библиотеки libc, в которой база данных часовых поясов достаточно легко обновляется независимо от самой системы и имеет стабильный формат. Однако различные реализации Java не опираются на системные возможности по обработке времени, они таскают за собой свои базы данных часовых поясов. Обновление такой базы для старой версии Java может выглядеть вообще заменой старого интерпретатора на новый, с которым может не работать приложение, это еще цветочки...
Дальше -- больше. В базах данных время может храниться в разном формате, зачастую без указания часового пояса. Ладно, с типовыми веб-приложениями в этой области более-менее разобрались, профили пользователей во всевозможных форумах имеют специальную настройку "часовой пояс", которая используется для корректного отображения даты, а сама дата хранится в UTC, что уже не плохо.
Хуже всего в Windows. Например, Exchange внедряет информацию о временных зонах в создаваемые события, что требует переписывания всей информации в базе данных при изменении часовых поясов. Кстати, таких изменений не так и мало -- по утверждению Дреппера, в мире в год происходит в среднем порядка 20 локальных изменений в порядке вычисления часовых поясов.
Что касается GNU/Linux, то здесь ситуация такая:
- Основные дистрибутивы выпустили обновления пакета с базой часовых поясов: Novell/SUSE, RedHat, для остальных рекомендуется проверить, что в системе стоит свежая версия tzdata (2005m и новее). Обратите внимание, что исправление у Novell не является куммулятивным и требует установки нескольких пакетов для охвата как США, так и Канады.
- IBM выпустила свои рекомендации по обновлению GNU/Linux на соответствие с текущими настройками часовых поясов.
- IBM также опубликовала аналогичный документ для IBM Java Development Kit.
- Sun Microsystems представила информацию по почти 50 своим продуктам
- PostgreSQL также нуждается в обновлении до 8.0.4+ для тех, кто это еще не сделал. Лучше до 8.0.10+, чтобы включить в себя Канаду и западную Австралию.
Уф. На последок, аналогичные статьи от Microsoft: Visual Studio, обновления для Windows XP, 2003 и базовый Центр помощи при смене часовых поясов.
