Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Доброго дня.
Есть следующая задача:
Территориально разбросанные склады. Каждый в своем часовом поясе.
Пользователь будет указывать дату и время "записи" на услугу хранения. Ну например хочу привезти товар завтра, в 12.00.
Т.е. бронировать "окна". Локация и часовой пояс при бронировании известны.
Как правильно это организовать с типами данных и хранить?
Варианты были следующие:
1. поле типа datetime. Хранить по UTC. Тогда вроде схема единая, но очень много преобразований. Особенно с учетом, если заказывает в Уфе услугу на Красноярск. Локальное время Уфы, нужно через Красноярск преобразовать в UTC, затем сохранить в БД. При отображении смотрим время UTC, преобразовываем к Красноярску. Очень кудряво
2. два поля типа date, time. Храним локальную дату (Красноярска) и локальное время (Красноярска). Плюсы в том, что данные относятся четко к локации и при отображении ничего преобразовывать не нужно. Минусы наверное есть (пока не знаю какие)
3. Поле типа datetimeTz - насколько я понял, это тот же datetime, в котором есть инфа о часовом поясе. Попробовал создать, но в pma отличий от datetime не увидел. М.б. с ним как то по особому работать нужно?
4. два поля типа dateTz timeTz, ситуация аналогично п.3.
Наведите на путь истинный. Наверняка есть "обычная практика" в этом деле.
Не в сети
Я думаю вам будет приемлем след вариант - при добавлении заказа клиент будут указывать в полях ввода - время (локальное для клиента), дата, город клиента, регион клиента, город хранения, область хранения..
и в БД у вас будет такое..
cities (город.. список всех городов России с которыми вы будете работать)
regions (регион - список всех регионов России с которыми вы будете работать)
cities_in_region (список городов, что входят в регионы.. )
city_time_zone (временная зона города)
region_time_zone (временная зона региона)
orders (записиси о заказах)
тогда вы будете получать от клиента массив данных, сравнивать данные о городах и часовых поясах, что содердатся в БД и легко преобразовывать даты и время во время, нужно для вашей локации.
Изменено Vakulenko_Yura (18.10.2019 10:22:22)
Не в сети
city_time_zone, region_time_zone - это просто сдвиг в часах (или минутах) относительно UTC?
С этим то понятно.
А все таки, применительно к текущему заказу - хранить в двух полях локальную дату, время - в этом нет никаких граблей?
Не в сети
Страницы 1