Аргумент «есть люди, которым еще хуже» очень подлый и неконструктивный.
Во-первых, что для одного человека — беда, для другого — благо, и наоборот. Кто-то может страдать от отсутствия любви в его жизни (обладая при этом, допустим, финансовым благополучием), кто-то — от того, что на реализацию его мечт нужны деньги, которых у него нет (любимый человек под боком есть, но мечты более амбициозны, чем просто «любить и быть любимым»). Ни вы, ни кто-то еще не можете утверждать, что проблема какого-то человека — не проблема вовсе. Для него — проблема.
Во-вторых, что частично вытекает из первого, как вы предлагаете сравнивать, чьи проблемы серьезнее? Есть какая-то объективная численная метрика, типа там, «у Нотча проблемы на 123.8, а вот у меня на 153.2»?
В-третьих, предположим на секунду, что такая метрика есть. В таком случае для каждого человека на Земле, за исключением одного-единственного, будут существовать люди, у которых проблемы серьезнее. Единственный человек, которого нельзя будет попрекнуть словами «а вон в Африке детям еще хуже», будет самым несчастным человеком на свете. Вы действительно считаете, что лишь самая худшая из проблем заслуживает сострадания или хотя бы тактичного молчания?
В-четвертых, попрекание страдающего человека (пусть даже конкретно в этом случае Нотч не прочтет никогда ваш комментарий) его же собственным страданием — тот еще демотиватор. Такими словами можно сделать только хуже, но никак не исправить ситуацию. Если же вас тут волнует только ваше собственное спокойствие («чтобы ноющий заткнулся», так сказать, «и не портил мне настроение»), то и в этом случае такие слова нерациональны — вы делаете страдающему человеку хуже, и он от этого будет еще сильнее портить вам настроение страданиями и нытьем.
Само собой, можно не соглашаться с Нотчем по какой-либо причине, но именно использованный вами аргумент довольно отвратителен (к кому бы он ни был применен — к чувствующему себя одиноким миллиардеру или к нищему студенту, которого бросила девушка).
Определенным людям которые вечно достают своим «Linux 1%. Linux не нужен», я теперь говорю так: «пока вы за своим Windows PC сидите и пишете чушь, Linux уже проник в ваши роутеры, телефоны, телевизоры и кофеварки».
GWT очень даже взлетел. Когда его только-только показали, все грезили тем, что я бы назвал AJAX Promise — что можно написать приложение десктопного уровня с помощью веб-технологий, и он будет работать, при этом не требуя никаких телодвижений от администраторов сети — нужно просто разослать по email сотрудникам URL приложения — никаких развертываний, никаких танцев с бубном вокруг каждой клиентской машины. Мы поэтому сейчас и пишем в большинстве своем внутренние приложения на HTML-CSS-JavaScript, что админы — люди ленивые, и продать систему, не требующую установки на каждый компьютер клиента существенно легче.
Но писать на HTML всегда казалось слишком сложно. Вот и начались все эти идеи с компиляцией в JS. GWT был одним из самых первых и самых успешных таких проектов. Когда он появился, все закричали:
— Да вы что — это ж именно то, на чем написали GMail и Google Docs! Значит и мы сможем написать наше энтерпрайз-приложение!
Сам Гугл при этом тактично молчал, пропагандировал GWT на всех конференциях, рассказывал о том, как это все здорово.
Так GWT завоевал свое место в Энтерпрайзах. А потом случился казус: Google открыл свою библиотеку на JS — Google Closure — со словами
— Вообще-то Gmail и Доксы написаны на ДжаваСкрипте.
Все такие:
— Эээ… пардон, а… на GWT тогда что написано???
— Ну, вообще-то, мы на нем Google Wave написали, но он страшно тормозит, поэтому мы его закрываем.
И звук такого разочарования: — Уап-вап-уаааап…
А на самом деле JavaScript — язык весьма толковый. Если на нем написать строк 700 нормального кода, не изобретая особенных велосипедов, а используя современные практики — Underscore JS, JSLint, ES5-Strict, jQuery DOM-Events-Ajax и MVC/MVP-подход, — то писать на нем получается быстрее, проще и удобнее. Потому что пока мой товарищ напишет на Java свой UI на GWT, ему придется насоздавать несколько десятков классов, тысячу раз протанцевать вокруг всех типов, писать длинные методы-простыни из-за того, что в Java тяжело с колбэками; я успею все то же самое набросать в виде читаемой верстки, небольшого CSS и аккуратного скрипта, который я смогу нормально, без танцев с бубном и без постоянного редеплоймента протестировать и отдебажить во всех браузерах. И оно будет работать быстрее — всегда. Я никогда не видел, чтобы GWT-компилятор выдал на выходе код оптимальнее того, что, например, используется в jQuery. Основной тормоз производительности в вэбе — DOM-манипуляции. В jQuery они отточены до блеска, в GWT — отнюдь нет.
Во многом проблемы GWT в Java, а не в самом подходе. Пример того же CoffeeScript показывает, что сам подход «компилируем в JS» вполне имеет право на существование. Даже с учетом того, что строки в результирующем JS отличаются от исходников на CS, соответствие прослеживается очень хорошо. Так что все возможно.
Крики о том, что, мол, JavaScript ни черта не модульный, — полная чушь. Модульность не определяется типами, модульность — это интерфейсы и энкапсуляция. Ни то, ни другое в JavaScript не представляет какой-то сложности — Google Closure или Yahoo UI — яркие примеры успешной модульной архитектуры на JS. В случае с последней можно иметь несколько версий библиотеки и плагинов на одной странице — они не будут наступать друг другу на пятки никоим образом. Это jQuery.noConflict() на стероидах. И это именно тот подход, который Gilad Bracha — один из Дартистов — использует в своем языке Newspeak — там он как раз и разбирался с модульностью в программировании.
Tool support? Откройте Chrome Developer Tools, IE9 Dev Tools, Opera Dragonfly, Firebug — там есть столько всего — пользуйся, не хочу! И откройте JetBrains WebStorm или любую другую их среду, где есть поддержка JavaScript. GWT нервно курит в сторонке.
> Объясните, зачем решать за пользователя сколько сейчас у него времени по
> какой то базе данных? Не правильнее полагатся на его выбор?
Вы, похоже, понятия не имеете, что такое tzdata, что там содержится, и зачем она используется.
Специально для вас и таких как вы могу пояснить подробнее.
Многие Unix-like системы для хранения информации обо всех мировых часовых поясах используют базу tzdata (она же tz database, она же zoneinfo database, она же Olson database — в честь Артура Олсона, основателя этой базы знаний).
Впервые начал собирать эту базу Артур Дэвид Олсон (Arthur David Olson), позже к этому проекту подключились и другие участники. Сейчас же основным коммитером новой информации в базу tzdata является Пол Эггерт (Paul Eggert), а Артур Олсон сейчас занимается разработкой и поддержкой утилит для работы с локальным временем и данными о часовых поясах (пакет tzcode).
В базе tzdata содержится детальная информация обо всех часовых поясах во всех регионах мира:
— координатная привязка основных населённых пунктов, характеризующих часовой пояс;
— смещение локального времени в различных регионах относительно универсального времени UTC;
— указано, в каких регионах применяется летнее время (DST), насколько оно смещается относительно стандартного, указаны точные даты и время переключения на летнее время и обратно в различных регионах в различные периоды;
— информация о високосных секундах (leap seconds).
Важной особенностью базы tzdata является то, что она не просто хранит текущее состояние всех мировых часовых поясов (т.е. текущие правила расчёта локального времени относительно UTC в каждом регионе мира), она ещё хранит все изменения этих правил расчёта времени для всех регионов за всё время с начала Unix-эпохи (1 января 1970). Допустим, какая-то страна своим политическим решением перешла в другой часовой пояс — эта информация есть в tzdata с точностью до секунды, когда это произошло; какая-то страна изменила дату перехода на летнее время — эта информация есть в tzdata с точностью до секунды, когда это произошло; какая-то страна отменила переход на летнее время — эта информация есть в tzdata с точностью до секунды, когда это произошло и т.д.
Благодаря этой особенности, можно вести точные расчёты времени для разных стран за разные промежутки времени (т.е. не только для текущего момента).
Например, локальное время:
2010-12-01 14:00 (MSK) — соответствует 2010-12-01 11:00 (UTC)
2011-12-01 14:00 (MSK) — соответствует 2011-12-01 10:00 (UTC)
Казалось бы, одинаковое название часового пояса и одинаковое локальное время (только год разный). Но в один исторический период часовая зона MSK соответствовала UTC+03:00, а в другой исторический период та же самая часовая зона MSK соответствовала уже UTC+04:00.
Также неоднозначности между часовыми поясами возникают, например, из-за того, что переход на летнее время и обратно не происходит одномоментно во всех странах, где он используется. В каждом регионе — в своё время, и даже не обязательно в один день.
И благодаря базе tzdata все эти неоднозначности легко решаются, т.к. там хранится подробная информация о том, когда и как рассчитывалось время в каждом из часовых поясов в каждый из временных периодов (с 1970 года).
Если иметь только текущее состояние всех часовых зон (без исторической памяти о правилах расчёта времени в прошлом), то подобные неоднозначности локальных часовых зон никогда не разрешить. И база tzdata как раз и решает задачу сбора и консолидации всей этой информации о часовых поясах со всего мира.
Информация об исчислении времени в различных регионах мира для базы tzdata собирается совместно участниками opensource-сообщества со всего мира, затем присланная информация проверяется, обсуждается, уточняется, консолидируется и в итоге коммитится в файлы tzdata. Исходники tzdata содержат всю информацию обо всех часовых поясах в текстовом человекочитаемом виде с комментариями и пояснениями. Далее эти текстовые файлы компилируются (утилитой zic) и в системах используются уже в скомпилированном бинарном виде. Причём скомпилированные файлы tzdata, хоть и бинарные, но они не содержат исполняемого кода и платформонезависимы. В большинстве unix-подобных ОС скомпилированные файлы с описанием часовых зон из пакета tzdata можно найти здесь: /usr/share/zoneinfo/
Информация, собранная в tzdata, распространяется свободно для всех желающих без каких-либо лицензионных ограничений (public domain). Любой может свободно взять (как в исходниках, так и в бинарном виде) и использовать её в своих приложениях/библиотеках/сервисах. Многие разработчики дистрибутивов ОС и различного ПО именно так и делают.
Базу 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 и др.
В мире opensource база tzdata де-факто является стандартным источником информации обо всех часовых поясах. Благодаря единой базе знаний tzdata, каждому разработчику ОС и ПО не нужно самостоятельно собирать и поддерживать внутри своего проекта в актуальном состоянии информацию о мировых часовых поясах. Все её получают из единого источника, и везде она идентична (если вовремя обновляют tzdata).
Версии tzdata нумеруются следующим образом. Сначала четырёхзначное число, означающее год выхода этой версии, а потом одна буква латинского алфавита по порядку: a, b, c, d… и т.д. по мере выхода новых версий tzdata в течение одного года. Например, в 2010 году выходили версии tzdata: 2010a, 2010b, 2010c… и далее до версии 2010o. В 2011 году выходили версии tzdata: 2011a, 2011b, 2011c… и далее до 2011k (на день написания этой статьи это пока последняя версия tzdata).
Изменения для новых часовых зон России появились в tzdata 2011j, а изменения для часовых поясов Украины и Белоруссии появились в tzdata 2011k.
Если вы используете какой-либо Linux-дистрибутив, который вы регулярно обновляете из репозиториев, то скорее всего последняя версия пакета tzdata уже установлена у вас в системе.
Даты выхода последних релизов tzdata на примере Ubuntu:
14 сентября 2011 — пакет tzdata обновился до версии 2011j в апстриме Ubuntu (Debian Unstable);
20 сентября 2011 — пакет tzdata 2011j поступил в основной репозиторий Ubuntu;
26 сентября 2011 — пакет tzdata обновился до версии 2011k в апстриме Ubuntu (Debian Unstable);
04 октября 2011 — пакет tzdata 2011k поступил в основной репозиторий Ubuntu.
В Linux-дистрибутивах с пакетными менеджерами можете просто посмотреть версию текущего установленного пакета tzdata. Например, в Debian/Ubuntu это можно сделать командой: dpkg -s tzdata |grep Version
Если в выводе этой команды присутствует 2011k (или выше), значит у вас пакет tzdata уже достаточно обновлён.
Во-первых, что для одного человека — беда, для другого — благо, и наоборот. Кто-то может страдать от отсутствия любви в его жизни (обладая при этом, допустим, финансовым благополучием), кто-то — от того, что на реализацию его мечт нужны деньги, которых у него нет (любимый человек под боком есть, но мечты более амбициозны, чем просто «любить и быть любимым»). Ни вы, ни кто-то еще не можете утверждать, что проблема какого-то человека — не проблема вовсе. Для него — проблема.
Во-вторых, что частично вытекает из первого, как вы предлагаете сравнивать, чьи проблемы серьезнее? Есть какая-то объективная численная метрика, типа там, «у Нотча проблемы на 123.8, а вот у меня на 153.2»?
В-третьих, предположим на секунду, что такая метрика есть. В таком случае для каждого человека на Земле, за исключением одного-единственного, будут существовать люди, у которых проблемы серьезнее. Единственный человек, которого нельзя будет попрекнуть словами «а вон в Африке детям еще хуже», будет самым несчастным человеком на свете. Вы действительно считаете, что лишь самая худшая из проблем заслуживает сострадания или хотя бы тактичного молчания?
В-четвертых, попрекание страдающего человека (пусть даже конкретно в этом случае Нотч не прочтет никогда ваш комментарий) его же собственным страданием — тот еще демотиватор. Такими словами можно сделать только хуже, но никак не исправить ситуацию. Если же вас тут волнует только ваше собственное спокойствие («чтобы ноющий заткнулся», так сказать, «и не портил мне настроение»), то и в этом случае такие слова нерациональны — вы делаете страдающему человеку хуже, и он от этого будет еще сильнее портить вам настроение страданиями и нытьем.
Само собой, можно не соглашаться с Нотчем по какой-либо причине, но именно использованный вами аргумент довольно отвратителен (к кому бы он ни был применен — к чувствующему себя одиноким миллиардеру или к нищему студенту, которого бросила девушка).
AVISource? Зачем? Кому надо пережимать AVI файл?
DirectShowSource или FFMpegSource — да.
Настройки x264 не объяснены. Кому интересна вся эта ваша куча. Тем более она не подходит для всех случаев.
Полезная статья вот:
zoltan0.livejournal.com/11021.html
zoltan0.livejournal.com/11422.html
zoltan0.livejournal.com/11545.html
zoltan0.livejournal.com/11946.html
zoltan0.livejournal.com/12286.html
google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
Вообще гугл все свои руководства по оформлению складывает в одном месте:
code.google.com/p/google-styleguide/
Но писать на HTML всегда казалось слишком сложно. Вот и начались все эти идеи с компиляцией в JS. GWT был одним из самых первых и самых успешных таких проектов. Когда он появился, все закричали:
— Да вы что — это ж именно то, на чем написали GMail и Google Docs! Значит и мы сможем написать наше энтерпрайз-приложение!
Сам Гугл при этом тактично молчал, пропагандировал GWT на всех конференциях, рассказывал о том, как это все здорово.
Так GWT завоевал свое место в Энтерпрайзах. А потом случился казус: Google открыл свою библиотеку на JS — Google Closure — со словами
— Вообще-то Gmail и Доксы написаны на ДжаваСкрипте.
Все такие:
— Эээ… пардон, а… на GWT тогда что написано???
— Ну, вообще-то, мы на нем Google Wave написали, но он страшно тормозит, поэтому мы его закрываем.
И звук такого разочарования: — Уап-вап-уаааап…
А на самом деле JavaScript — язык весьма толковый. Если на нем написать строк 700 нормального кода, не изобретая особенных велосипедов, а используя современные практики — Underscore JS, JSLint, ES5-Strict, jQuery DOM-Events-Ajax и MVC/MVP-подход, — то писать на нем получается быстрее, проще и удобнее. Потому что пока мой товарищ напишет на Java свой UI на GWT, ему придется насоздавать несколько десятков классов, тысячу раз протанцевать вокруг всех типов, писать длинные методы-простыни из-за того, что в Java тяжело с колбэками; я успею все то же самое набросать в виде читаемой верстки, небольшого CSS и аккуратного скрипта, который я смогу нормально, без танцев с бубном и без постоянного редеплоймента протестировать и отдебажить во всех браузерах. И оно будет работать быстрее — всегда. Я никогда не видел, чтобы GWT-компилятор выдал на выходе код оптимальнее того, что, например, используется в jQuery. Основной тормоз производительности в вэбе — DOM-манипуляции. В jQuery они отточены до блеска, в GWT — отнюдь нет.
Во многом проблемы GWT в Java, а не в самом подходе. Пример того же CoffeeScript показывает, что сам подход «компилируем в JS» вполне имеет право на существование. Даже с учетом того, что строки в результирующем JS отличаются от исходников на CS, соответствие прослеживается очень хорошо. Так что все возможно.
Крики о том, что, мол, JavaScript ни черта не модульный, — полная чушь. Модульность не определяется типами, модульность — это интерфейсы и энкапсуляция. Ни то, ни другое в JavaScript не представляет какой-то сложности — Google Closure или Yahoo UI — яркие примеры успешной модульной архитектуры на JS. В случае с последней можно иметь несколько версий библиотеки и плагинов на одной странице — они не будут наступать друг другу на пятки никоим образом. Это jQuery.noConflict() на стероидах. И это именно тот подход, который Gilad Bracha — один из Дартистов — использует в своем языке Newspeak — там он как раз и разбирался с модульностью в программировании.
Tool support? Откройте Chrome Developer Tools, IE9 Dev Tools, Opera Dragonfly, Firebug — там есть столько всего — пользуйся, не хочу! И откройте JetBrains WebStorm или любую другую их среду, где есть поддержка JavaScript. GWT нервно курит в сторонке.
> какой то базе данных? Не правильнее полагатся на его выбор?
Вы, похоже, понятия не имеете, что такое tzdata, что там содержится, и зачем она используется.
Специально для вас и таких как вы могу пояснить подробнее.
Многие Unix-like системы для хранения информации обо всех мировых часовых поясах используют базу tzdata (она же tz database, она же zoneinfo database, она же Olson database — в честь Артура Олсона, основателя этой базы знаний).
Впервые начал собирать эту базу Артур Дэвид Олсон (Arthur David Olson), позже к этому проекту подключились и другие участники. Сейчас же основным коммитером новой информации в базу tzdata является Пол Эггерт (Paul Eggert), а Артур Олсон сейчас занимается разработкой и поддержкой утилит для работы с локальным временем и данными о часовых поясах (пакет tzcode).
В базе tzdata содержится детальная информация обо всех часовых поясах во всех регионах мира:
— координатная привязка основных населённых пунктов, характеризующих часовой пояс;
— смещение локального времени в различных регионах относительно универсального времени UTC;
— указано, в каких регионах применяется летнее время (DST), насколько оно смещается относительно стандартного, указаны точные даты и время переключения на летнее время и обратно в различных регионах в различные периоды;
— информация о високосных секундах (leap seconds).
Важной особенностью базы tzdata является то, что она не просто хранит текущее состояние всех мировых часовых поясов (т.е. текущие правила расчёта локального времени относительно UTC в каждом регионе мира), она ещё хранит все изменения этих правил расчёта времени для всех регионов за всё время с начала Unix-эпохи (1 января 1970). Допустим, какая-то страна своим политическим решением перешла в другой часовой пояс — эта информация есть в tzdata с точностью до секунды, когда это произошло; какая-то страна изменила дату перехода на летнее время — эта информация есть в tzdata с точностью до секунды, когда это произошло; какая-то страна отменила переход на летнее время — эта информация есть в tzdata с точностью до секунды, когда это произошло и т.д.
Благодаря этой особенности, можно вести точные расчёты времени для разных стран за разные промежутки времени (т.е. не только для текущего момента).
Например, локальное время:
2010-12-01 14:00 (MSK) — соответствует 2010-12-01 11:00 (UTC)
2011-12-01 14:00 (MSK) — соответствует 2011-12-01 10:00 (UTC)
Казалось бы, одинаковое название часового пояса и одинаковое локальное время (только год разный). Но в один исторический период часовая зона MSK соответствовала UTC+03:00, а в другой исторический период та же самая часовая зона MSK соответствовала уже UTC+04:00.
Также неоднозначности между часовыми поясами возникают, например, из-за того, что переход на летнее время и обратно не происходит одномоментно во всех странах, где он используется. В каждом регионе — в своё время, и даже не обязательно в один день.
И благодаря базе tzdata все эти неоднозначности легко решаются, т.к. там хранится подробная информация о том, когда и как рассчитывалось время в каждом из часовых поясов в каждый из временных периодов (с 1970 года).
Если иметь только текущее состояние всех часовых зон (без исторической памяти о правилах расчёта времени в прошлом), то подобные неоднозначности локальных часовых зон никогда не разрешить. И база tzdata как раз и решает задачу сбора и консолидации всей этой информации о часовых поясах со всего мира.
Информация об исчислении времени в различных регионах мира для базы tzdata собирается совместно участниками opensource-сообщества со всего мира, затем присланная информация проверяется, обсуждается, уточняется, консолидируется и в итоге коммитится в файлы tzdata. Исходники tzdata содержат всю информацию обо всех часовых поясах в текстовом человекочитаемом виде с комментариями и пояснениями. Далее эти текстовые файлы компилируются (утилитой zic) и в системах используются уже в скомпилированном бинарном виде. Причём скомпилированные файлы tzdata, хоть и бинарные, но они не содержат исполняемого кода и платформонезависимы. В большинстве unix-подобных ОС скомпилированные файлы с описанием часовых зон из пакета tzdata можно найти здесь: /usr/share/zoneinfo/
Официальная страница tzdata: http://cs.ucla.edu/~eggert/tz/
Исходники tzdata и утилит для работы с часовыми поясами можно скачать здесь: ftp://elsie.nci.nih.gov/pub/
Информация, собранная в tzdata, распространяется свободно для всех желающих без каких-либо лицензионных ограничений (public domain). Любой может свободно взять (как в исходниках, так и в бинарном виде) и использовать её в своих приложениях/библиотеках/сервисах. Многие разработчики дистрибутивов ОС и различного ПО именно так и делают.
Базу 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 и др.
В мире opensource база tzdata де-факто является стандартным источником информации обо всех часовых поясах. Благодаря единой базе знаний tzdata, каждому разработчику ОС и ПО не нужно самостоятельно собирать и поддерживать внутри своего проекта в актуальном состоянии информацию о мировых часовых поясах. Все её получают из единого источника, и везде она идентична (если вовремя обновляют tzdata).
Версии tzdata нумеруются следующим образом. Сначала четырёхзначное число, означающее год выхода этой версии, а потом одна буква латинского алфавита по порядку: a, b, c, d… и т.д. по мере выхода новых версий tzdata в течение одного года. Например, в 2010 году выходили версии tzdata: 2010a, 2010b, 2010c… и далее до версии 2010o. В 2011 году выходили версии tzdata: 2011a, 2011b, 2011c… и далее до 2011k (на день написания этой статьи это пока последняя версия tzdata).
Изменения для новых часовых зон России появились в tzdata 2011j, а изменения для часовых поясов Украины и Белоруссии появились в tzdata 2011k.
Если вы используете какой-либо Linux-дистрибутив, который вы регулярно обновляете из репозиториев, то скорее всего последняя версия пакета tzdata уже установлена у вас в системе.
Даты выхода последних релизов tzdata на примере Ubuntu:
14 сентября 2011 — пакет tzdata обновился до версии 2011j в апстриме Ubuntu (Debian Unstable);
20 сентября 2011 — пакет tzdata 2011j поступил в основной репозиторий Ubuntu;
26 сентября 2011 — пакет tzdata обновился до версии 2011k в апстриме Ubuntu (Debian Unstable);
04 октября 2011 — пакет tzdata 2011k поступил в основной репозиторий Ubuntu.
В Linux-дистрибутивах с пакетными менеджерами можете просто посмотреть версию текущего установленного пакета tzdata. Например, в Debian/Ubuntu это можно сделать командой:
dpkg -s tzdata |grep VersionЕсли в выводе этой команды присутствует 2011k (или выше), значит у вас пакет tzdata уже достаточно обновлён.