Привет.
Прочел достаточно статей на тему, примерно понял систему, что храним в UTC, но хотел бы пару моментов уточнить.
Сервер, например, работает в Москве, а его пользователи по всей стране. Каждый пользователь в своем личном кабинете может установить себе личную временную зону (ЛВЗ далее) .
Такие вопросы:
1) В php приложении, в бутстрапе, не стоит в date_default_timezone_set() устанавливать эту ЛВЗ пользователя? Т.к. это будет аффектить все другие подсистемы, типа логов.
2) В БД, mysql, установка временной зоны по умолчанию в UTC считается нормой?
3) Использовать ли тип TIMESTAMP, который хранит в базе время в UTC (что и хотели), а временную зону в БД будем в бутстрапе устанавливать в значение равное ЛВЗ пользователя? Дата будет прилетать в базу, как клиент ввел.
Но если учесть пункт 1), то зоны в разных частях приложения будут отличаться.
4) Может использовать тип DATETIME , куда перед сохранением, и выборками, всегда конвертить дату из ЛВЗ в UTC, и обратно?
5) Какие главные минусы против чтобы временную метку хранить просто как число unixtimestamp? То что выборки , когда нужны всякие DATE специфичные функции, потребуют преобразования в тип дату в каждой строке? (это преобразование может не сложное?, ведь datetime и так хранится как число)
UTC позволит поднять второй сервер во Владивостоке или в заграничном облаке и не запутаться, например...
А временные зоны нужны только на фронте.
Соответственно, переход из UTC и обратно - между фронтом и бэком (весь бэк в UTC).
В теории.
На практике - если у вас где-то в форме заполняется тупо дата, а сайт работает в 12 часовых поясах, вам придется придумать, как в этих датах, которые в другом часовом поясе будут другими, не создать неконсистентность. Например, принять правило, что даты - по Москве. Или везде оперировать временем с точностью до часа.
Проблем с временными зонами вообще не будет, если их представление выдавить максимально ближе к модели представления данных на интерфейсе пользователя.
Нужно конвертировать в строку только непосредственно перед отрисовкой дату и время из UTC, и обратно загонять время в UTC, если забираете пользовательский ввод.
Весь бек должен работать в одной временной зоне, а от пользователя знать, что он в такой-то временной зоне, только в контексте сессионной переменной, если это необходимо.
