Pull to refresh

Comments 23

>И, нет, я не ошибся разместив файлы в icu/icudt48l/ а в путях указав только папку icu.
Кстати, забавное дополнение. Чтение всей документации я не осилил, хотя там про это должно быть. А про переменную окружения и необходимость создания поддиректории узнал из выхлопа strace. =)
>>Кстати, вопрос, почему php-fpm игнорирует глобальный env?

Оно?

List of pool directives
clear_env boolean
Clear environment in FPM workers.

php.net/manual/en/install.fpm.configuration.php
Да, похоже оно. Но получается как то не секурно. Либо мы чистим evn для всех воркеров и указываем у каждого из них в настройках свои env, либо до воркеров доносим весь env целиком. Было бы здорово найти способ указать конкретную переменную окружения для всех воркеров, но без доступа воркеров к оригинальному env.
Пример типичного преступления в программировании. Вместо того чтобы опереться на стандартные библиотеки, разработчики этой php-intl встраивают свою реализацию функциональности tzdata. При этом наверняка зависимость от libc уже есть, так что от такой реализации ничего не экономится.
У libc есть фатальный недостаток.
так libicu стандартная библиотека (99.9%, что она используется в вашем браузере), в php-intl нет встроенной tzdata (есть в самом php но это другая история)
А у libicu еще и свой формат с миллисекундами (помоему), но в качесве источника при конвертации используется Olson tz data
Остается только вопрос, почему столь важную библиотеку не чешутся регулярно обновлять. Точнее даже не обновлять (в плане версии), а пересобирать с новыми TZ и т.д. Собственно я находил в том же Debian'e и более ранний баг, нежели тот, что указан в статье, когда говорили об косяке с TZ для Киева (это был 2012 год кажется), фикс по этому багу сделали в 2013 и он до сих пор только в Experemental дистрибутиве. Ппц какой то.
То есть виновата не php-intl, а другая библа?

Насколько я понимаю, база Олсона является корневым источником информации о часовых поясах. Но в системе логично было бы иметь ровно один пакет, который часто обновляется из этой базы, а все другие пакеты использовали бы его.

Кстати, почему не делают динамическое обновление? Если уже используется ntp-сервер, который довольно часто лазит в интернет, то почему бы ему (или другому, специально выделенному, демону) дополнительно не ходить изредка за tzdata?
Дело в том, что в libc не выставлены наружу функции для работы с таймзонами. Единственное, что можно сделать — это поменять таймзону для своего процесса, что, мягко говоря, не подходит для многопоточных или асинхронных программ.
Но можно было провести разрез пониже: использовать готовый интерфейс доступа к базе tzdata. Даже без учета скоропалительности правительства РФ было бы естественно предположить, что поддержка базы в актуальном состоянии — дело трудное и неблагодарное, и что лучше оставить это дело тем, кто уже впрягся этим заниматься.
Так его нету, он внутри libc запрятан. Всё, что торчит наружу — это функция tzset. Или вы предлагаете внутри libc провести разрез иначе?
Хм, действительно, tzset() работает с глобальными переменными, что не очень хорошо. Тем не менее, разрез существует, правда, корявый: самостоятельно парсить файлы, принадлежащие tzdata (из /usr/share/zoneinfo/ или где они там живут). Конечно, неудобно, но зато гарантируется, что при обновлении tzdata ничего не потеряется. Еще нужно подумать о том, как быть со старыми процессами, которые живут дольше, чем возраст последнего обновления tzdata, но эта проблема должна решаться на другом уровне.
Вообще, если обратить внимание на tzdata, можно заметить, что последняя и без правительства РФ обновляется раз по 10 в год, а то и больше. Вроде бы icu не используют tzdata из-за уже упомянутого «фатального недостатка», но на поверку — tzdata обновляется гораздо лучше; думаю — будет всё-таки неплохо, если кто-то допишет поддержку/заведёт форк icu с поддержкой tzdata.
Данный способ не работает для libicu 3.6 и php-cgi 5.2.17
А вы папку какую указывали? по логике нужно класть в папку по виду /opt/icu/icudt36l/ (для вашей версии). Но опять же, мы с lsh, узнали эту папку по сути прямым трейсом пхп во время запроса к intlDateFormatter::format. Таким образом и определили точный путь, куда необходимо класть файлы. Так же попадались в документации по ICU какие то фразы про ограничения на старые версии, где это не работает. Но вроде всё это касалось ICU 2.0 и ниже (но могу ошибаться).

Вы можете обратиться к lsh думаю он не откажет вам в помощи, как получить эту самую папку.
Опять же… у вас просто зона не пофиксилась, или intlDateFormatter перестал работать? У нас функция переставала работать, если пути правильные, а вот версия самих файлок .res не правильная (le/be).
Я указывал /opt/icu/icudt36/. Указал /opt/icu/icudt36l/ и заработало, но только в cli. Через веб всё равно показывает +4.
Вы что используете для сервера приложений? Apache+mod_php или php-fpm? Если апачь, то в htaccess необходимо указать переменную окружения ICU_DATA, если php-fpm, то рецепт есть в статье. Ибо, вероятно, как и в случае с php-fpm системные переменные окружения не применяются к воркерам php в рамках веб-сервера.

P.S. В апаче похоже нужно включать mod_env, что бы заработала возможность указания envilopment variables: stackoverflow.com/questions/17550223/set-an-environment-variable-in-htaccess-and-retrieve-it-in-php
php-cgi. помогло добавление модуля timezonedb
Это вы решили параллельную проблему с обновлением TZ самого php
Sign up to leave a comment.

Articles