Pull to refresh

Comments 19

Эм?
Грузим squeeze/lenny, apt-get source tzdata, копируем в etch, правим debian/control, dch -i, debuild.
В крайнем случае, берем пакет от убунты 8.04, она ещё поддерживается.
Да кто же спорит то? Но это не очень быстрый, и конечно же, не простой способ :-)
Такой метод приведёт к тому, что локальное время в прошлом будет считаться неверно.

Для Maemo5 я просто скопировал файл /usr/share/zoneinfo/W-SU с компьютера под Ubuntu на N900 как /usr/share/zoneinfo/Europe/Moscow (обычно это ссылка на ../W-SU, но на N900 — обычный файл) и перезагрузил телефон. После этого локальное время изменилось, но будильники остались старые. Я открыл и закрыл страницу с будильниками — они тоже пришли в норму.
Почему же неверно то? Выставление GMT-6 это практически тоже самое, если выставить любую другую локальную зону с подходящим временем, но БЕЗ перехода на летнее/зимнее время. На самом деле — для старых систем подошел бы еще один достаточно простой и правильный способ:
Скопировать /usr/share/zoneinfo/SomeWorldPart/YourCity из Lenny с обновленным tzdata в /etc/localtime у Etch.
Но не всегда в окружении старых серверов с Etch есть доступный сервер с Lenny+/Ubunta
Потому что, если зону выставить руками, система не будет знать, что, например, зимой прошлого года сдвиг был не 4 часа, а 3.

Можно взять файл из пакета tzdata любого свежего дестрибутива. В том числе скачать .deb из репозитория.
Извините, зачем системе эта информация? Я вижу только применение для расчета периодов времени, но честно говоря — мне лично в прошлом году не нужна точность в часах.

Насчет пакетов из Lenny -> Etch или файлов из свежего в развернутом виде я предвидел вопросы. Способы рабочие — но не быстрые. Ввиду того, что статья всеже для полных новичков, которые могут бояться затестить свежий пакет в старом дистрибутиве (да они много чего могут бояться, и часто такие действия ломают вообще все то, что работало годами) я не стал описывать данные способы. А воспользовался только тем, что есть на конкретном сервере.
Например, время событий в БД хранится в UTC, а пользователю выдаётся в локальном времени. В зависимости от событий, ошибка может довольно серьёзной.
Вот тут мне подсказывают, что пакет от lenny прекрасно встает на etch через dpkg -i
Рекомендую проверить как еще ведёт себя php…
На Debian 6.0 я апгрейднул tzdata и системное время встало нормально, но вот пхп при запуске комманды:
php -r "echo date('Y-m-d H:i:s');"
упорно выдавало разницу в час…
Все встало на свои места после:
pecl install timezonedb
и далее в php.ini (или /etc/php5/conf.d/timezonedb.ini) добавляем строчку:
extension=timezonedb.so

Еще прочитал что обновление до последнего php автоматом решает проблему.
PS. Не забываем перегрузить апач! :)
Он после обновления php вроде как сам перезапускается.
А разве в lenny-volatile не содержится самый актуальный tzdata?
SELECT NOW(); в MySQL возвращает переведенное время (
Полный ребут сервера помог и теперь и системное время и php и mysql выдают одно и то же значение. Спасибо!
не могу признать ваш способ самым лучшим, но зато точно самый IT-crowd'овский :)
Достаточно было ребутнуть сам mysql & apache (в случае mod_php).
Можно же добавить в sources.list дистр, где есть свежий tzdata, проапдейтить его оттуда и закомментить эту строчку до следующего катаклизма. Это проще и правильнее, чем ручками брать оттуда deb.
можно, но я не люблю потом иметь кашу в кеше апта
Ну так я потому и посоветовал потом закомментить это.
Sign up to leave a comment.

Articles