Debian непонятки с localtime

дык, часовой пояс и поменяйте :)

Универсальный совет : всегда делайте полный рестарт когда что-то меняете.

Это не обязательно, если вы понимаете механизмы работы, но ведь так просто и позволяет быть уверенным что сервер загрузится и без вашего участия.

Видимо, apache у вас все еще помнит старую зону.

ntp работает с таймером ядра и тот всегда в UTC. ничего не изменится от синхронизации.

netwind, уже сам догадался, но вы были как всегда правы ))

На моё удивление нужно было перезапустить пхп, хотя сишный демон изменение зоны понял сразу..

как то думалось что изменяется localtime ( системный вызов), а меняется только зона и в соответствии с ней date() выводит нужный результат.. так вот эта зона значит и закешировалась в пхп ;)

такие вещи глобальные как смена временной зоны требует обязательного ребута.

ИМХО.

Ну зачем ребут? Достаточно перезапустить все сервисы

В phpini есть параметр, отвечающий за временную зону, его подкрутить пробовали?

Сделать tzconfig

Открыть 37 порт на выхлоп

edit /etc/init.d/hwclock.sh

HWCLOCKPARS=--directisa

rdate -s rdate.cpanel.net

/etc/init.d/hwclock.sh reload

echo "#! /bin/sh" > /etc/cron.daily/rdate-set

echo "rdate -s rdate.cpanel.net" >> /etc/cron.daily/rdate-set

chmod +x /etc/cron.daily/rdate-set

service cron restart

edit php.ini

date.timezone=Europe/Moscow

...

Изменить вышенаписанное по вкусу... ;)

ну зачем ребут? Достаточно перезапустить операционную систему :)

qwartyr , ребут сервера особенно там, где нельзя прерывать работу сервера )

мне хватило перезагрузки пхп демонов.. всем спасибо за советы )

PS. мой первый сервер проработал 1.5 года без перезагрузки, не знаю насколько он был уязвим в корне из-за устаревшего ядра, но всё было стабильно )

настройки tz лучше делать в момент сетапа сервера и навсегда.

Во всяком случае я так считаю.

Судя по моему опыту, достаточно сложные продукты типа oracle или db2 очень плохо переживают такого рода перемены.

Если помог простой рестарт, то это совсем хорошо.