|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Здраствуйте, есть запрос:
Отредактированно Proger (03.05.2009 14:04:46)
Неактивен
Посмотрите внимательно что именно хранится в таблице (и в какой временной зоне) и сравните с now(). Лучше бы подошел тип TIMESTAMP, так как он совместим с now() по временной зоне.
Неактивен
Гм. Временная зона на всех серверах GTM+3 то есть московское время.
Попробую timestamp, мне эта дата на вывод как бы и не нужна, она сугобо для того чтобы знать как долго пользователь неактивен находясь на сайте.
Спасибо!
Неактивен
timestamp не помог =// Такой же эффект и дата таже самая, как и была раньше, когда её вставлял php скрипт в БД. Какие ещё могут быть варианты?
Я вот не знаю Debian сам часовой пояс выбирает из интернета или нет (доступ в интернет имеется). И как его бы просмотреть, может он не верный. Но время точно верное.
ADD:
сделал SELECT NOW()
получил время на 4 часа больше, видимо часовой пояс как гринвич стоит. А где это можно исправить?
Отредактированно Proger (03.05.2009 17:33:14)
Неактивен
MySQL по умолчанию использует зону из системы. Но можно выставить для каждого клиента запросом
SET time_zone = '+4:00' (но это будет работать до ближайшей смены летнего времени)
http://dev.mysql.com/doc/refman/5.1/en/ … pport.html
Лучше разобраться почему в базу время попадает в разном формате: при вставке оно по гринвичу, а при сравнении - по Московскому.
Неактивен
Пока сменил просто сменив системную дату. Ибо он РЕАЛЬНУЮ почему то считает за гринвич.
Через tzconfig я проверил, стоит европа/москва, но время которое в bios он считает почему то за гринвич. Сменил на 4 часа назад - все нормально =/
Неактивен
Он наверняка в SELECT NOW() ставит Гринвич. У Вас система считает, что она в Лондоне 
Неактивен
система при установке спросила "какой пояс?" Я ей указал Москву ГТМ+3. Однако в now... ИМХО масикуэль что-то не понимает с временными зонами.
Отредактированно Proger (23.05.2009 19:41:27)
Неактивен
Прочитал изначальную проблему. Кажется, можно плюнуть на все это и хранить данные в
TIMESTAMP. Тогда Вы не будете привязаны к определенной зоне, и проблемы отпадут
сами собой.
Кстати, MySQL тут не при чем, зона важна та, которую сообщает клиент
Неактивен
все сервера в одной зоне.
Данные и так уже в таймштампе - не помогло. Я же написал что отмотал просто на 4 часа назад. Просто не понимаю почему так и не хочу мучатся с переводом часов после лета например...
Неактивен
Еще раз говорю, это клиентская настройка, а не серверная. Смотрите в настройки, которые
посылает клиент серверу.
[aquatica] root (none) > select now(); +---------------------+ | now() | +---------------------+ | 2009-05-25 19:45:23 | +---------------------+ 1 row in set (0,01 sec) [aquatica] root (none) > set time_zone='+0:0'; Query OK, 0 rows affected (0,02 sec) [aquatica] root (none) > select now(); +---------------------+ | now() | +---------------------+ | 2009-05-25 15:50:16 | +---------------------+ 1 row in set (0,00 sec)
Можете проставить на сервер именные зоны (скрипт mysql_tzinfo_to_sql) и после этого можно
будет после подключения писать SET time_zone='Europe/Moscow' и все timestamp будут отдаваться
в нужной зоне.
Неактивен
хм... ну видимо оттого что у меня время руками на 4 часа повернуто оба запроса до смены временной зоны и после одинаковое время показали.
А что в данном случае клиент то? Постоянно в запуске скриптов прописывать set time +3 ? Клиентом тут является как я понимаю сам php движок, а где там такие настройки можно найти я не понял! Я первым делом искал различные настройки часовых поясов, но ничего не нашел.
Неактивен
Если это PHP, то да, это библиотека PHP.
Неактивен
Страниц: 1
