?

Log in

No account? Create an account
Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
Важность обновлений: обновление часовых поясов
Speaker Rabbit
abbra
В мире постоянно происходят изменения в законодательствах разных стран и некоторые изменения при всей своей "некомпьютерности" затрагивают не только подданных этих стран, но и все остальных. Так, в 2005 году правительство США приняло акт об экономии энергоресурсов, в рамках которого изменились даты перевода часов на зимнее и летнее время, начиная с 2007 года.

Не нужно думать, что раз это изменение происходит в США или Зимбабве, или еще какой стране, оно нас не касается. Напротив, касается напрямую, ведь многие серверы установлены в США, почта приходит отовсюду, а для бизнес-приложений утечка времени вообще крайне вредна. Так что от того, что 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 и базовый Центр помощи при смене часовых поясов.

  • 1
Помню, в какой-то из предыдущих версий SuSE был патч для Java, который как раз вносил такие изменения. :)

О, нашёл:
"Australia delaying the end of DST by one week for 2006 only to support the Commonwealth games. Instead of ending at 3am on March 25, 2006 it will end at 3am April 2, 2006."

http://sunsolve.sun.com/search/document.do?assetkey=1-26-102775-1

какой-то персистентный y2k...

дык, это... главное тихою сапою до 2034-го года дотянуть, а вот там начнется Главная Персистентая Жопа ;)

Давно надо перейти на единое время и алфавит.

Единое -- какое? От мигания пульсара в таком-то созвездии? С UTC все-таки упорно не выходит.

Какой из юникодов сэр предпочитает? :)

Юникод - отстой. Я за латинский алфавит во всем мире.
26 букв более, чем достаточно.

"не дождётесь" (ц)

Не хочется применять метод Луговского, но латинский -- недоалфавит, такой себе васик. :)

Старый добрый лисп, ой, церковно-славянский -- уже имел компрессию, например.

Ну и можешь поспрошать Мишу Быкова касательно систем записи музыки, он интересно высказывался. Так и там получается, что "наша современная" весьма много чего не умеет by design, что давно существует в ряде других (упоминал тибетское пение по дугам, что ли).

Короче, не надо нас дамбить даун ту зи лист коммон демуникатор ;)

  • 1