Я думаю с подобным стыкался каждый разработчик клиент серверных приложений (тема вопроса). Читал статьи все они теоретические и не полные. Но пришел к выводу что на сервере надо все даты хранить в одном часовом поясе, а при выдаче клиенту переводить в локальное для него время (берем из настроек пользователя вводит при регистрации, если же пользователь не зарегистрирован, то выводим в том времени на территорию которого ориентирован сайт: к примеру по Москве). Вопросы: 1. Как заставить запрос [sql] INSERT INTO message (id_user, id_country, id_area, id_settlement, id_subsection, id_theme, create_date, expire_date, mess_text, url) VALUES (?, ?, ?, ?, ?, ?, now(), ADDDATE(now(), INTERVAL ? DAY), ?, ?) [/sql] Сохранить now() и ADDDATE(now(), INTERVAL ? DAY) во времени по Гринвичу (универсальном) 2. Если данные сохранены по Гринвичу как выдать пользователю, данные запросом с условием что часовой пояс известен? P.S. Не обращайте внимания на знаки вопроса, PHP их дальше заменяет значениями из массива
1. На сервере не время по Гринвичу, и NOW следственно сохраняет... 2. Я не знаю как результаты выборки дат привязать, к указанному в переменной часовому поясу.
Такое чувство что мы смотрим на одну монету с разных сторон: Приведите пример запроса подобного данному [sql]INSERT INTO message (create_date) VALUES (now())[/sql], который вставит время по Гринвичу. И что за переменная $servertimediff ?
Лан я выспался, отдохнул, но проблемка осталась. Ко всем соображениям написанным в первом сообщении я пришел сам. Мне не повезло найти в инете статью достаточно полно раскрывающую "проблему временных зон". Чтобы избавится от проблем связанных со сменой хостера, я хотел хранить время именно в Гринвичском, все Insert, Update тоже должны проходить в нем. Проблему несколько усугубляет наличие у меня в каждой таблице поля mod_date с атрибутом on update CURRENT_TIMESTAMP. 1. Вот я из задавал вопрос можно ли сервер заставить какой либо установкой считать себя размещенным на Гринвиче? В одной статье нашел следующий оператор SET time_zone='+00:00' в контексте соединения это влияет на временную зону клиента, но следственно не только селекты будут возвращаться с новой часовой зоной и Insert'ы также. Возможно ли работу с датами сервера сделать прозрачной? Возложить на плечи MySQL перегонку дат между часовыми поясами? С условием что смещение пользователя относительно Гринвича будет передаваться при инициализации соединения скрипта с БД. Или может у вас найдется ссылка на статью с подобной тематикой?