1) Как лучше хранить в БД поправку на время для этого пользователя?
Смысл вопроса в том, что если человек выбирает себе в настройках МСК+7 то надо не просто отображать его время, а правильно отобразить что его магазин сейчас уже не работает, или зашедшим посетителям не давать оформить доставку на "сегодня" потому что сегодня уже закончилось и у него на сайте уже надо "завтрашнюю" дату показывать.
2) Датау заказа в БД хранить в одинаковом виде для всех?
Т.е. если заказ приходит в 21:00 по МСК и у пользователя стоит время МСК в настройках, то в БД записываем дату 25, то же самое заказ в 21:00 по МСК но у пользователя МСК+7 в настройках, то ему в БД пишем число заказа 26е?
3) Стоит ли использовать TIMESTAMP в этом случае?
Пользователь из Владика и его магаз надо закрыть на 7 часов раньше чем в МСК. Но timestamp записывает в базу NOW() да ещё и с учётом установленного часового пояса MySQL, а он один, а не разный для всех юзеров. Разве что вручную при записи в БД тогда прибавлять timestamp + 7 * 3600 что бы получить истинное время заказа для пользователя из Владика.
Всё вышенаписанное подразумевает что магазином юзера пользуются юзеры из того же региона, что и он сам т.е. на сайт для Владика москвичи не зайдут и не удивятся что там уже завтрашняя дата стоит.
Лучше хранить временную зону пользователя в формате а-ля Europe/Moscow (это позволит избежать проблем с переходом на летнее время).
Это ничем не поможет, если бы к примеру у в МСК и был бы переход.
В БД надо все равно как-то сохранять время заказа и например при архивах 5 летний давности как-то уметь это все дело разгребать и учитывать.
Второй момент, вдруг в одном городе отменять перевод или наоборот сново будут переводить в МСК. Опять делать костыли и подпорки ? Потом люди опять будут возмущаться и опять вернуть обратно :)
Опять же яркий пример МСК.
Ещё можно хранить в виде смещения от UTC, но тут возникает ранее обговорённая проблема летнего времени.
Хранить все данные в UTC и уже от выбранного региона делать поправку на тот регион, это намного проще и самый оптимальный путь. При этом не важно, был ли у вас перевод или не был. По дате мы это знаем и можем легко все сделать.
Vladimir Zhurkin: я написал ответ на часть вопроса, относящуюся к хранению временной зоны пользователя.
Время создания заказа понятно, что хранить нужно в таймштампе.
Средний
Средний
