maximka787
12.08.2015 - 00:51
Парни помогите. Срочное дело. У меня при переносе проекта на новый хостинг стала неправильно работать функция select now(). Она показывает время на 3 часа раньше фактического. Я долго гуглил и пока не понял, где лучше прописать настройку времени. Php дает верную дату. Хостинг массовый, права к конфигам ограничены.
Как быть в моей ситуации?
У меня много вызовов now(). И хотелось бы, чтобы дата была верная.
Поля в БД datetime. Время нужно чтоб сохранялось только по Москве.
_____________
..Работает - не трогай!
AllesKlar
12.08.2015 - 01:04
Настройки сервера базы данных.
копай в сторону SET TIME ZONE при каждом подключении к базе.
_____________
[продано копирайтерам]
killer8080
12.08.2015 - 09:14
| Цитата (maximka787 @ 11.08.2015 - 23:51) |
У меня много вызовов now(). И хотелось бы, чтобы дата была верная.
Поля в БД datetime. Время нужно чтоб сохранялось только по Москве. |
а как быть с юзерами из других часовых поясов?
PS поэтому нужно по возможности всегда использовать timestamp, а не datetime.
maximka787
12.08.2015 - 10:06
Юзеры будут только из москвы и мо. Нужно просто добавлять время создания сообщений.
Попробую делать set при каждом подключении.
_____________
..Работает - не трогай!
maximka787
12.08.2015 - 10:26
| Цитата (killer8080 @ 12.08.2015 - 05:14) |
| PS поэтому нужно по возможности всегда использовать timestamp, а не datetime. |
Тоесть мне лучше сделать поле timestamp. Сохранять туда дату как есть, без всех этих настроек предварительных. А уже при выборке изменять вывод даты с учетом зоны? Я правильно понимаю?
_____________
..Работает - не трогай!
killer8080
12.08.2015 - 10:47
Разница в том, что timestamp не зависит от настроек сервера, и ты можешь смело использовать now() при инсертах/апдейтах. timestamp это целое число количества секунд от начала эпохи юникс в UTC. Юникс таймштамп универсален, когда ты делаешь селект, субд сама на лету конвертирует его в строковое представление согласно текущих настроек.
maximka787
12.08.2015 - 10:53
Спасибо за совет. Так и сделаю. Мне главное, чтоб при инсертах и апдейтах заносиллсь верное число. А уж с выборкой как то да справлюсь. То есть мне при использовании now() пока что ничего менять не нужно? Я про настройки подключения к базе.
Модет такое быть, что изза неверных настроек самого сервера данные запишутся неверно?
_____________
..Работает - не трогай!
maximka787
12.08.2015 - 11:36
Чтобы не было ошибок, решил сбросить зону.
mysql_pconnect('localhost','root','');
mysql_select_db('test');
mysql_query('SET NAMES utf8');
mysql_query('SET time_zone = "+00:00"');По идее TS запишется корректно.
Что касается вывода, решение найдено.
SELECT CONVERT_TZ(NOW(), @@session.time_zone, '+03:00')
+ зависит от зоны юзера, которую он укажет при регистрации.
_____________
..Работает - не трогай!
killer8080
12.08.2015 - 11:40
| Цитата (maximka787 @ 12.08.2015 - 09:53) |
| Мне главное, чтоб при инсертах и апдейтах заносиллсь верное число. А уж с выборкой как то да справлюсь. То есть мне при использовании now() пока что ничего менять не нужно? |
Ну у тебя же поля datetime, в них время пишется относительно текущей time_zone, поэтому нужно прописывать эту переменную при каждом подключении к бд.
SET time_zone = '+03:00'
Вообще для универсальности считается хорошим тоном держать БД в UTC, а форматировать уже при выводе в часовом поясе клиента.
UPD сам опередил :)
killer8080
12.08.2015 - 11:44
| Цитата (maximka787 @ 12.08.2015 - 10:36) |
| + зависит от зоны юзера, которую он укажет при регистрации. |
для анонимов можно определять их часовой пояс через JS
document.cookie = 'tz='+(new Date().getTimezoneOffset());
maximka787
12.08.2015 - 11:47
Благодарю за помощь killer8080.
Вроде разобрался.
_____________
..Работает - не трогай!
Быстрый ответ:
Powered by dgreen
Здесь расположена полная версия этой страницы.