За что спасибо? За то что направили по ложному пути?

Что за коллективный бред?

вообще никаких проблем, после инициализации коннекта бд

SET time_zone='+03:00'

и забудь про костыли с конвертацией часовых поясов.

SET time_zone='+03:00'

а SELECT как делать?

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

SET time_zone='+03:00';
SELECT.......

но уже нет необходимости в самом селекте часовой пояс учитывать

но чёт сдаётся - это не твой случай, если в запросе 2 разных пояса

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

потому что решение костыльное, каждый раз в каждом запросе нужно помнить о необходимости конвертации TZ.

как обычно, timestamp будет выводится в соответствии с текущим часовым поясом.

у каждого пользователя свой часовой пояс, одновременно не нужно работать с двумя.
time_zone сессионная переменная, она действует только для текущего соединения с бд.
http://dev.mysql.com/doc/refman/5.7/en/ser...ysvar_time_zone

Ну раз это не очевидно, объясню
Всегда и везде где можно использовать timestamp, нужно использовать timestamp. DATETIME нужно избегать и использовать только там, где дата выходит за диапазон timestamp. К сожаления mysql слишком консервативный в этом плане и до сих пор использует 31 бит для этого формата. В PHP такой проблемы давно нет, во первых допускаются отрицательные значения int, во вторых в 64 битном PHP. timestamp 64 бита, что с лихвой перекрывает потребности. В mysql же приходится мирится с устаревшим подходом.
Чем timestamp лучше datetime?
- время в нём в абсолютном формате, всегда в UTC и не зависит от настроек сервера, СУБД автоматически конвертирует его на лету при выводе и вводе в соответствии со значением time_zone
- использовать now() и т.п. не задумываясь над тем какой часовой пояс на сервере, при переносе базы с одного хостинга на другой можно быть уверенным, что ничего не сломается, новые записи будут с правильным временем, и не окажутся старше предыдущих, с другого сервера из-за географической разности во времени.
- не нужны костыли с конвертацией в каждом запросе.
- автоматическая инициализация (для DATETIME стала доступна только с версии 5.6)

killer8080,а так придется ставить

SET time_zone='+03:00';

перед запросом?

правильней сказать, инициировать переменную после установки соединения с бд, Не вижу тут никаких проблем, это в любом случае нужно делать, так же как и устанавливать кодировку. В любом случае это делается один раз, а не в каждом запросе. С datetime ты можешь только догадываться какая была настройка сервера в тот момент, когда заносилась запись, особенно проблем это доставит с переходами зимнее/летнее время.

эта просто переменная, ты можешь её менять хоть перед каждым запросом, но обычно надобности в этом нет.

killer8080,выставлять UTC или GMT ??

Само собой, и потом при выводе конвертить, а если в базу пишутся дата/время введённые пользователем, то же не забывать конвертировать. Вопрос только зачем такие сложности, когда есть timestamp и автоматический вывод в текущей TZ.

Не совсем понял, что значит "переподключать пользователя"? Это разные магазины, на разных серверах, с разными бд?

,

CONVERT_TZ

им же?или

 SET time_zone

?
И тогда получается если пользователь хочет получить данные за 2016 24 ноября 11 часов 23 минуты мы ставим SET time_zone кконвертируем время в unix и SELECT?

ничего конвертировать не нужно, установила в time_zone часовой пояс пользователя и работаешь так, как если бы юзер и сервер находились в одном часовом поясе. Если он ввел "2016 24 ноября 11 часов 23 минуты", значит получит выборку относительно своего, локального времени.